SIP invite received with incorrect URI

jtoque · ‎07-06-2011

Hello, we have implemented a SIP gateway (non Cisco) to setup a call with our CUCM in case of a primary gateway failure. The gateway (ComISDN SIP stack) detect the first gateway failure and correctly initiate a SIP INVITE to our CUCM but we see that the SIP URI used in this case is not correct:

2.002 >>     172.22.10.2:5060  (UDP) [SIP ] (-493) 1 INVITE (From = "sip:172.22.10.7", To = "sip:493@172.22.10.7") [SDP] Audio = PCMA|PCMU|GSM|G723 (172.22.10.6:25156-), DTMF = NTE|NOTIFY (172.22.10.6:25156-)
2.005 <<     172.22.10.2:5060  (UDP) [SIP ] (-493) 1 100-INVITE "Trying"
2.011 <<     172.22.10.2:5060  (UDP) [SIP ] (-493) 1 404-INVITE "Not Found" (Reason Q.850 = 1 "Unallocated (unassigned) number")
2.011 >>     172.22.10.2:5060  (UDP) [SIP ] (-493) 1 ACK

In this trace, we can see that the INVITE is send to "sip:493@172.22.10.7". As per our CUCM ip adress is 172.22.10.2, the CUCM is rejecting the call with a 404 not found. So our question is: Is there a meaning for our CUCM to accept the INVITE although the SIP URI is not correct ?

Thanks a lot for your appreciate help.

Julien.

Brian Meade · ‎07-06-2011

It sounds like your gateway is configured incorrectly and it is looping calls back to itself. How are you capturing the SIP messages? I bet CUCM isn't even getting this traffic.

jtoque · ‎07-06-2011

100-INVITE "Trying" and 404-INVITE "Not Found" are both sent by the cucm to the gateway (meaning that cucm received the previous INVITE). The SIP messages are the messages sent/received by the gateway. The gateway is not able to change the SIP message in the "backup" call setup to the cucm so i would like to know if there is a meaning for the cucm to accept this "wrong" INVITE.

clileikis · ‎07-06-2011

Hi there,

Depending on your CUCM config, make sure your inbound CSS on your SIP trunk has access to the phone you're trying to call.

HTH,

Chris

Please rate helpful posts

jtoque · ‎07-06-2011

Thanks Chris, CSS on the SIP Trunk allow access to internal extension like "493". I don't think CSS is the problem in here (no problem when calling the same extension from another device with the same CSS).