X-Lite and NRS

[guycable2]

Hi

I have setup an X-Lite Softphone for SIP testing to our NRS and have come across a problem I can't seem to resolve. I followed the FAQ and was able to register to my NRS. I am able to call the Softphone from any phone in our CS1000 network but I can't call out from the X-Lite.

Using Wireshark I see the request to call an extension go out and then a response from my NRS that says Status: 302 Moved Temporarily. I do not see any errors on the console of the NRS server. A SIP Trace also doesn't yeild any information.

I've verfied that my service domain has an A and a PTR record and is resolving to the right place.

CS1000M MG Rel. 5.5
NRS=HP COTS server Rel 5.5

 

[Reusser]

have you setup routing entry to the destination for the call number and type?

Symptom:
LOG0003 tSPMsg: | ERROR | <msg_parser.c: 190> Final CRLF is missing
LOG0003 tSPMsg: | ERROR | <msg_parser.c: 469> End of header Not found
LOG0003 tSPMsg: | ERROR | <msg_parser.c: 712> error in msg_headers_parse()
LOG0003 tSPMsg: | ERROR | <sipevent.c: 76> could not parse message
LOG0004 tSPMsg: spMsgHandler: 400 Bad Request, msg <
LOG0004 tSPMsg: spOsipEventHandle: CANCEL msg, callid 1011a420-4b33060a-13c4-434cd591-4799ef69-744c from 10.6.51.75:1449, discarded
LOG0003 tSPTCPd: spTcpServer: freeing lingering frame due to premature socket 67 closure from 10.6.51.75:1432
LOG0003 SIPNPM: sipNpm3XXContactHeaderParse: contact actualLen=189483212 > SIPNPM_MAX_SIPURI_LEN
LOG0003 SIPNPM: sipNpmContactHeaderExtract: Contact header parse failed.!
LOG0003 tSPTCPd: spTcpServer: freeing lingering frame due to premature socket 68 closure from 10.6.51.75:1448
BERR0705 EXC 0: Exception 14 in Task "tSPTCPd" (0xbc4a628)
SRPT0782 RST 0: WARM START IN PROGRESS - Reason 0
Calls do not complete


Cause:
NRS is receiving INVITE from endpoint and then providing 302 MOVED TEMPORARILY with the TLAN address of the Gateway instead of the NODE Address of the Gateway. This causes a loop condition and the above messages were observed in some cases.




Problem Resolution

Fix:
Verify NRS configuration for endpoints:
Verify that if a STATIC Endpoint Address has been defined that it is the NODE IP address of the Endpoint.

If the above condition still exists change the SIP transport from TCP to UDP.

 

[guycable2]

This definitely seems to describe my problem. However I don't see those errors on my Sig Servers when I telnet to it during testing.

I should have added that I can 4 digit dial between my 4 sites using SIP trunking so all routing is setup correctly.

I have the node IP address entered for each Endpoint (CS1000) so I don't believe that is it.

I wonder if changing the SIP transport to UDP would work. I suppose that change would require a reboot.

 

[gwebster]

SIP to 3rd party endpoints on CS 1000 - especially anything before 6.0 - is definitely a case of hit-or-miss. The SIP used for SIP trunking between CS 1000 systems is very different from the SIP used to connect to another system which is very different from the SIP used to connect to a phone.

 

[guycable2]

I guess I kind of understood that going in but based on the fact that there was a FAQ and it worked for him I thought I would give it a shot. We are going to 6.0 sometime in the next few months so I can wait until then or keep trying.

 

[Reusser]

Since you can do 4 digit dialing, I would suspect problem is just getting the routing entries right so the NRS knows how and where to send the call.

What are you dialing from the x-lite and what do you have set up to match in NRS routing entry?

Also by looking at DCH messages can help with making correct routing entries.

 

[guycable2]

I am simply dialing the 4 digit extension number. The sip invitation looks like this.

INVITE sip:4682@sip.domain.com

After that request is when I see the STATUS 302 Temporarily moved.

It looks like it is sending the request to the end point that 4682 is at but the STATUS comes from the NRS IP address.

 

[Reusser]

your domain name on the incoming call has to match the domain name in NRS and SigServer.

 

[guycable2]

It does. I changed the name to domain.com for the post.

I already verified that the domain has A and PTR records and resolves correctly.