cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3447
Views
5
Helpful
10
Replies

CUBE - Inbound SIP Dial Peer to CUCM Not Functioning

Tim Walker
Level 1
Level 1

Dear forum users.

I have the following set-up

CUCM - 10.5.1.10000-7

CUBE - 2911 Version 15.3(3)M3

Telco (iinet) - SIP - CUBE - H.323 - CUCM

I inherited this configuration that uses inbound SIP from the Telco to the CUBE, but then uses H.323 from the CUBE to the CUCM. This was configured and is currently working. I am looking to change the CUBE - CUCM integration from H.323 to SIP. For testing, I have configured two additional dial-peers on the CUBE using SIP with a destination pattern of 9072 that matches my phone's DN. I have also configured a SIP trunk on the CUCM to allow inbound calls from CUBE using SIP. The IP address of the destination of the SIP trunk is the dialer interface of the CUBE that the signalling and media traffic is bound to because this is the interface calls arrive from the Telco. The original H.323 dial-peer is below, and also my SIP one for inbound CUBE calls to the CUCM. 

H.323:-

dial-peer voice 10000 voip
 description ** Route to CUCM Publisher **
 destination-pattern 9...
 session target ipv4:192.168.99.15
 voice-class codec 1  
 voice-class h323 1
 dtmf-relay h245-alphanumeric
 ip qos dscp cs3 signaling
 no vad

SIP:-

dial-peer voice 999 voip
 description ** Tim Testing **
 destination-pattern 9072
 session protocol sipv2
 session target ipv4:192.168.99.15
 voice-class codec 1  
 no voice-class sip early-offer forced
 dtmf-relay h245-alphanumeric
 ip qos dscp cs3 signaling
 no vad 

When I shut the 999 dial-peer, calls are received to my phone using the H.323 dial-peer. When I no shut the 999 dial-peer, inbound calls fail to connect. I can see from the debug voip dial-peer all that my 999 dial-peer is being matched but the debug ccsip messages tells me there is no outgoing dial-peer available.

 

Please see attached debugs for details. I can't figure out why the CUBE thinks there is no outgoing dial-peer when the debug of the dial-peers shows the match to 999. I very confident the CUCM is not at fault here as I can't see the CUBE setting up a SIP calls with the CUCM in the SDL traces. 

 

Any thoughts or ideas? I have attached debug ccsip messages for a working H.323 call with dial-peer 999 shut down and a non-working SIP call with 999 no shut. I have also attached debug voip dial-peer all for a failed call and also a copy of all the dial-peers on the CUBE.

 

2 Accepted Solutions

Accepted Solutions

remove , 

outbound-proxy dns:sip.STATE.OTHERCOMPANY.net.au

and test

send the same logs if it fails

View solution in original post

(+5) to Javelkur.

I am just going to add a little more on the use of outbound sip-proxy. This has caught many people out in the past. I wrote a blog on this a while back. Please have a read here and get a better understanding of this command. This call was never sent to cucm. It looks like it was, but it was sent to the outbound host in your sip proxy command. If you want to use outbound sip proxy configure it at dial-peer level using voice class command. Ensure its only the dial-peer facing your ITSP that this is applied to.

 

Thread URL: https://supportforums.cisco.com/message/4167875#4167875

 

We had an interesting issue on the forums a while back and it had to do with outbound-proxy. The user reported that calls were not working for a new sip solution he just set up. So we dug in as we usually do...

It is very important to understand what each command you enable on your gateway does. SIP proxy was configured in this case and it did all of the damage..

 

When you configure outbound-proxy eg " outbound-proxy dns:callcentric.com", all outbound SIP request is sent to that domain (call centric.com). I mean "ALLLLL" Even sip messages that should go to CUCM are sent back to that domain...Lets have a look at what happened in this case

 

++receive INVITE from ITSP+++

 

SIP outbound-proxy analysis
 

 

++receive INVITE from ITSP+++

 

Received:
INVITE sip:17772253754@192.168.1.203:5060 SIP/2.0
v: SIP/2.0/UDP 204.11.192.159:5080;branch=z9hG4bK-11f85db5478eab1a1d6560665917bdc9
f: <sip:18165297500@66.193.176.35>;tag=3601520592-546043
t: <sip:18452055544@ss.callcentric.com>
i: 3308051-3601520592-546012@msw2.telengy.net

 

+++Next CUBE sends a trying to ITSP..Before it does that it needs to establish a TCP connection+++
NB: CUBE has sent the call back to ITSP on port 5080, because thats the port used for the incoming connection+++

 

008382: Feb 16 00:23:12.949:  //3342/A5A3315A8319/SIP/Transport/sipTransportLogicSendMsg: Trying to  send resp=0x49E83E84 to default port=5080
008383: Feb 16  00:23:12.949:  //-1/xxxxxxxxxxxx/SIP/Transport/sipConnectionManagerGetConnection:  connection required for raddr:204.11.192.159, rport:5080 with  laddr:192.168.1.203

 

Sent:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 204.11.192.159:5080;branch=z9hG4bK-11f85db5478eab1a1d6560665917bdc9
From: <sip:18165297500@66.193.176.35>;tag=3601520592-546043
To: <sip:18452055544@ss.callcentric.com>

 

+++Next CUBE needs to send an INVITE out to CUCM+++


NB: The  target host and the outbound host are different...The target host is who  the call is for, the outbound host is who the call should be sent to+++

 

08432: Feb 16 00:23:12.965:  //-1/xxxxxxxxxxxx/SIP/Info/sipSPIGetOutboundHostAndDestHostPrivate:  CCSIP: target_host : 192.168.1.200 target_port : 5060

 

008433: Feb 16 00:23:12.965:  //-1/xxxxxxxxxxxx/SIP/Info/sipSPIGetOutboundHostAndDestHostPrivate:  CCSIP: outbound_host : callcentric.com outbound_port : 5060

 

++++Because the outbound_host is a dns entry, cube needs to resolve the DNS for the domain+++

 

008547: Feb 16 00:23:12.981: //-1/xxxxxxxxxxxx/SIP/Event/sipSPIEventInfo: Queued event from SIP SPI : SIPSPI_EV_DNS_RESOLVE
008548:  Feb 16 00:23:12.981: //3343/A5A3315A8319/SIP/State/sipSPIChangeState:  0x49630448 : State change from (STATE_IDLE, SUBSTATE_NONE)  to  (STATE_IDLE, SUBSTATE_SENT_DNS)

 

+++CUBE does a SRV DNS query (looks like your DNS is configured for SRV++++++++++++
008554:  Feb 16 00:23:12.985: //-1/xxxxxxxxxxxx/SIP/Info/sip_dns_type_srv_query:  TYPE SRV query for _sip._udp.callcentric.com and type:1

 

++++Next DNS server returns all the SRV records for _sip._udp.callcentric.com++++++++

 

008555: Feb 16 00:23:13.057: //-1/xxxxxxxxxxxx/SIP/Info/sip_dns_type_srv_query: Server Name alpha18.callcentric.com
008556: Feb 16 00:23:13.057: //-1/xxxxxxxxxxxx/SIP/Info/sip_dns_type_srv_query: Priority 20 Weight 0 Port 5080
008557: Feb 16 00:23:13.057: //-1/xxxxxxxxxxxx/SIP/Info/sip_dns_type_srv_query: Server Name alpha19.callcentric.com
008558: Feb 16 00:23:13.057: //-1/xxxxxxxxxxxx/SIP/Info/sip_dns_type_srv_query: Priority 20 Weight 0 Port 5080
008559: Feb 16 00:23:13.061: //-1/xxxxxxxxxxxx/SIP/Info/sip_dns_type_srv_query: Server Name alpha11.callcentric.com
008560: Feb 16 00:23:13.061: //-1/xxxxxxxxxxxx/SIP/Info/sip_dns_type_srv_query: Priority 20 Weight 0 Port 5080
008561: Feb 16 00:23:13.061: //-1/xxxxxxxxxxxx/SIP/Info/sip_dns_type_srv_query: Server Name alpha12.callcentric.com
008562: Feb 16 00:23:13.061: //-1/xxxxxxxxxxxx/SIP/Info/sip_dns_type_srv_query: Priority 20 Weight 0 Port 5080
008563: Feb 16 00:23:13.061: //-1/xxxxxxxxxxxx/SIP/Info/sip_dns_type_srv_query: Server Name alpha15.callcentric.com
008564: Feb 16 00:23:13.061: //-1/xxxxxxxxxxxx/SIP/Info/sip_dns_type_srv_query: Priority 20 Weight 0 Port 5080
008565: Feb 16 00:23:13.061: //-1/xxxxxxxxxxxx/SIP/Info/sip_dns_type_srv_query: Server Name alpha16.callcentric.com
008566: Feb 16 00:23:13.061: //-1/xxxxxxxxxxxx/SIP/Info/sip_dns_type_srv_query: Priority 20 Weight 0 Port 5080
008567: Feb 16 00:23:13.061: //-1/xxxxxxxxxxxx/SIP/Info/sip_dns_type_srv_query: Server Name alpha17.callcentric.com
008568: Feb 16 00:23:13.061: //-1/xxxxxxxxxxxx/SIP/Info/sip_dns_type_srv_query: Priority 20 Weight 0 Port 5080
008569: Feb 16 00:23:13.061: //-1/xxxxxxxxxxxx/SIP/Info/sip_dns_type_srv_query: Selected Server is alpha18.callcentric.com
008570:  Feb 16 00:23:13.061: //-1/xxxxxxxxxxxx/SIP/Info/sip_dns_type_a_query:  TYPE A query successful for alpha18.callcentric.com
008571: Feb 16 00:23:13.061: //-1/xxxxxxxxxxxx/SIP/Info/sip_dns_type_a_query: ttl for A records = 263 seconds

 

+++Next DNS sends the ip address for the chosen device..204.11.192.170 (alpha18.callcentric.com)
008572: Feb 16 00:23:13.061: //-1/xxxxxxxxxxxx/SIP/Info/sip_dns_type_srv_query: IP Address of alpha18.callcentric.com is:
008573: Feb 16 00:23:13.061: //-1/xxxxxxxxxxxx/SIP/Info/sip_dns_type_srv_query: 204.11.192.170

 

+++NEXT CUBE sends a UDP connection to 204.11.192.170++++++++++


008620: Feb 16 00:23:13.077: //3343/A5A3315A8319/SIP/Transport/sipSPISendInvite: Sending Invite to the transport layer
008622:  Feb 16 00:23:13.077:  //3343/A5A3315A8319/SIP/Transport/sipSPITransportSendMessage:  msg=0x4A9AEC54, addr=204.11.192.170, port=5080, sentBy_port=0,  local_addr=192.168.1.203
008626: Feb 16 00:23:13.077:  //-1/xxxxxxxxxxxx/SIP/Transport/sipCreateConnHolder: Created new  holder=0x4A9B0760, addr=204.11.192.170; nailed=FALSE
008627: Feb 16  00:23:13.077:  //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportPostRequestConnection:  Posting UDP conn create request for addr=204.11.192.170, port=5080,  context=0x4840BD14

 

+++CUBE succesfully created a connection with 204.11.192.170+++++++++++

 

008638: Feb 16 00:23:13.081:  //-1/xxxxxxxxxxxx/SIP/Transport/sipConnectionManagerProcessConnCreated:  connection instance created for addr:204.11.192.170, port:5080  local_addr=192.168.1.203 local_port=49552

 

+++Next CUBE procceeds to send an outbound INVITE+++


008646: Feb 16  00:23:13.081: //3343/A5A3315A8319/SIP/State/sipSPIChangeState:  0x49630448 : State change from (STATE_IDLE, SUBSTATE_NONE)  to  (STATE_SENT_INVITE, SUBSTATE_NONE)


++++++but the INVITE appears to go to cucm when infact it wasnt sent there..it was sent to ITSP!!!!!!!!!!

 

Sent:
INVITE sip:17772253754@192.168.1.200:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.203:5060;branch=z9hG4bKD58157A
From: <sip:18165297500@callcentric.com>;tag=B46262C-230A
To: <sip:17772253754@192.168.1.200>

 

++++NEXT we get a response back from your ITSP requesting authentication++++++++

 

008670: Feb 16 00:23:13.181: //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor: Checking Invite Dialog
008671: Feb 16 00:23:13.181: //3343/A5A3315A8319/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 407 Proxy Authentication Required
v: SIP/2.0/UDP 192.168.1.203:5060;branch=z9hG4bKD58157A;rport=49552;received=24.123.98.94
f: <sip:18165297500@callcentric.com>;tag=B46262C-230A
t: <sip:17772253754@192.168.1.200>
i: A5AF6643-960911E3-831FFFD7-951695DD@callcentric.com
CSeq: 101 INVITE
Proxy-Authenticate:  Digest realm="callcentric.com", domain="sip:callcentric.com",  nonce="b69582701157bab55830417b7b62def9", opaque="", stale=TRUE,  algorithm=MD5
l: 0

 

This call was never sent to CUCM, it was sent to ITSP for onward forwarding to CUCM!!!!!!!!!!!!!!!!

 

Please rate all useful posts

View solution in original post

10 Replies 10

Jayanth Velkuri
Cisco Employee
Cisco Employee

CUBE is receiving 404 

can you bind the correct interface towards CUCM 

and collect below

deb ccsip mess

deb voip ccapi inout

and attach the complete sh run 

 

 

Sent: 
INVITE sip:9072@192.168.99.15:5060 SIP/2.0
Via: SIP/2.0/UDP 203.206.159.120:5060;branch=z9hG4bKA238178
From: <sip:+61467590909@visicomitsolutio01.iibusiness.net.au>;tag=6D196334-1105
To: <sip:9072@192.168.99.15>
Date: Fri, 10 Oct 2014 02:03:28 GMT
Call-ID: 76332BA0-4F5811E4-8C82E9E6-82B7B865@visicomitsolutio01.iibusiness.net.au

 

109236: Oct 10 12:03:28.757: //21624/7631F3508C7C/SIP/Msg/ccsipDisplayMsg:
Received: 
SIP/2.0 404 Not found
Via: SIP/2.0/UDP 203.206.159.120:5060;branch=z9hG4bKA238178
From: <sip:+61467590909@visicomitsolutio01.iibusiness.net.au>;tag=6D196334-1105
To: <sip:9072@192.168.99.15>;tag=SD8ivm599-1496439207-1412906608733
Call-ID: 76332BA0-4F5811E4-8C82E9E6-82B7B865@visicomitsolutio01.iibusiness.net.au
CSeq: 101 INVITE
Timestamp: 1412906608
Content-Length: 0

Hi.


Thanks for the reply, debugs attached. I will get the complete show run (with edits for non-relevant confidential content) shortly.

 

I have the sip traffic bound to the ADSL dialer interface because that is where the SIP calls originate. I have the loopback and dialer interface in the SIP trunk in CUCM. 

are you not seeing any invite from cube in cucm traces ?

as requested , pls bind the correct interfaces in the dial-peer 

Dial-peer has bind interfaces now, and no the invite from the CUBE is never seen in CUCM.

I am confused why the debug ccsip says no outgoing dial-peer but the debug voip dial peer all clearly shows a match against my dial-peer below?

 

 

dial-peer voice 999 voip
 description ** Tim Testing **
 destination-pattern 9072
 session protocol sipv2
 session target ipv4:192.168.99.15
 voice-class codec 1  
 no voice-class sip early-offer forced
 voice-class sip bind control source-interface Dialer0
 voice-class sip bind media source-interface Dialer0
 dtmf-relay h245-alphanumeric
 ip qos dscp cs3 signaling
 no vad

it does match , 999

may be attach the sdl trace as well for us to check 

 

11550: Oct 10 17:19:36.012: //21783/9F9B7BBF8CFA/CCAPI/ccCallSetupRequest:
   Destination=, Calling IE Present=TRUE, Mode=0,
   Outgoing Dial-peer=999, Params=0x3AD55D50, Progress Indication=NULL(0)
111551: Oct 10 17:19:36.012: //21783/9F9B7BBF8CFA/CCAPI/ccCheckClipClir:

Correct, it does match, so why do I see the below? SDL trace attached, call was made at 17:50. Also, full show run with confidential information removed.

 

109238: Oct 10 12:03:28.761: //21623/7631F3508C7C/SIP/Msg/ccsipDisplayMsg:
Sent: 
SIP/2.0 404 Not Found
Via: SIP/2.0/UDP 203.55.228.197:5060;branch=z9hG4bKt8acip30co1h0f0on3k1.1
From: <sip:0467590909@10.11.1.2;user=phone>;tag=SDiign901-1745675408-1412906608630-
To: "Not Known"<sip:0734679072@visicomitsolutio01.iibusiness.net.au>;tag=6D196388-23ED
Date: Fri, 10 Oct 2014 02:03:28 GMT
Call-ID: SDiign901-27159df55bde781c66d841e1ec0b5d2a-ao22mu0
CSeq: 1004925948 INVITE
          
Allow-Events: telephone-event
Warning: 399 203.206.159.120 "No matching outgoing dial-peer"
Server: Cisco-SIPGateway/IOS-15.3.3.M3
Reason: Q.850;cause=1
Content-Length: 0

remove , 

outbound-proxy dns:sip.STATE.OTHERCOMPANY.net.au

and test

send the same logs if it fails

(+5) to Javelkur.

I am just going to add a little more on the use of outbound sip-proxy. This has caught many people out in the past. I wrote a blog on this a while back. Please have a read here and get a better understanding of this command. This call was never sent to cucm. It looks like it was, but it was sent to the outbound host in your sip proxy command. If you want to use outbound sip proxy configure it at dial-peer level using voice class command. Ensure its only the dial-peer facing your ITSP that this is applied to.

 

Thread URL: https://supportforums.cisco.com/message/4167875#4167875

 

We had an interesting issue on the forums a while back and it had to do with outbound-proxy. The user reported that calls were not working for a new sip solution he just set up. So we dug in as we usually do...

It is very important to understand what each command you enable on your gateway does. SIP proxy was configured in this case and it did all of the damage..

 

When you configure outbound-proxy eg " outbound-proxy dns:callcentric.com", all outbound SIP request is sent to that domain (call centric.com). I mean "ALLLLL" Even sip messages that should go to CUCM are sent back to that domain...Lets have a look at what happened in this case

 

++receive INVITE from ITSP+++

 

SIP outbound-proxy analysis
 

 

++receive INVITE from ITSP+++

 

Received:
INVITE sip:17772253754@192.168.1.203:5060 SIP/2.0
v: SIP/2.0/UDP 204.11.192.159:5080;branch=z9hG4bK-11f85db5478eab1a1d6560665917bdc9
f: <sip:18165297500@66.193.176.35>;tag=3601520592-546043
t: <sip:18452055544@ss.callcentric.com>
i: 3308051-3601520592-546012@msw2.telengy.net

 

+++Next CUBE sends a trying to ITSP..Before it does that it needs to establish a TCP connection+++
NB: CUBE has sent the call back to ITSP on port 5080, because thats the port used for the incoming connection+++

 

008382: Feb 16 00:23:12.949:  //3342/A5A3315A8319/SIP/Transport/sipTransportLogicSendMsg: Trying to  send resp=0x49E83E84 to default port=5080
008383: Feb 16  00:23:12.949:  //-1/xxxxxxxxxxxx/SIP/Transport/sipConnectionManagerGetConnection:  connection required for raddr:204.11.192.159, rport:5080 with  laddr:192.168.1.203

 

Sent:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 204.11.192.159:5080;branch=z9hG4bK-11f85db5478eab1a1d6560665917bdc9
From: <sip:18165297500@66.193.176.35>;tag=3601520592-546043
To: <sip:18452055544@ss.callcentric.com>

 

+++Next CUBE needs to send an INVITE out to CUCM+++


NB: The  target host and the outbound host are different...The target host is who  the call is for, the outbound host is who the call should be sent to+++

 

08432: Feb 16 00:23:12.965:  //-1/xxxxxxxxxxxx/SIP/Info/sipSPIGetOutboundHostAndDestHostPrivate:  CCSIP: target_host : 192.168.1.200 target_port : 5060

 

008433: Feb 16 00:23:12.965:  //-1/xxxxxxxxxxxx/SIP/Info/sipSPIGetOutboundHostAndDestHostPrivate:  CCSIP: outbound_host : callcentric.com outbound_port : 5060

 

++++Because the outbound_host is a dns entry, cube needs to resolve the DNS for the domain+++

 

008547: Feb 16 00:23:12.981: //-1/xxxxxxxxxxxx/SIP/Event/sipSPIEventInfo: Queued event from SIP SPI : SIPSPI_EV_DNS_RESOLVE
008548:  Feb 16 00:23:12.981: //3343/A5A3315A8319/SIP/State/sipSPIChangeState:  0x49630448 : State change from (STATE_IDLE, SUBSTATE_NONE)  to  (STATE_IDLE, SUBSTATE_SENT_DNS)

 

+++CUBE does a SRV DNS query (looks like your DNS is configured for SRV++++++++++++
008554:  Feb 16 00:23:12.985: //-1/xxxxxxxxxxxx/SIP/Info/sip_dns_type_srv_query:  TYPE SRV query for _sip._udp.callcentric.com and type:1

 

++++Next DNS server returns all the SRV records for _sip._udp.callcentric.com++++++++

 

008555: Feb 16 00:23:13.057: //-1/xxxxxxxxxxxx/SIP/Info/sip_dns_type_srv_query: Server Name alpha18.callcentric.com
008556: Feb 16 00:23:13.057: //-1/xxxxxxxxxxxx/SIP/Info/sip_dns_type_srv_query: Priority 20 Weight 0 Port 5080
008557: Feb 16 00:23:13.057: //-1/xxxxxxxxxxxx/SIP/Info/sip_dns_type_srv_query: Server Name alpha19.callcentric.com
008558: Feb 16 00:23:13.057: //-1/xxxxxxxxxxxx/SIP/Info/sip_dns_type_srv_query: Priority 20 Weight 0 Port 5080
008559: Feb 16 00:23:13.061: //-1/xxxxxxxxxxxx/SIP/Info/sip_dns_type_srv_query: Server Name alpha11.callcentric.com
008560: Feb 16 00:23:13.061: //-1/xxxxxxxxxxxx/SIP/Info/sip_dns_type_srv_query: Priority 20 Weight 0 Port 5080
008561: Feb 16 00:23:13.061: //-1/xxxxxxxxxxxx/SIP/Info/sip_dns_type_srv_query: Server Name alpha12.callcentric.com
008562: Feb 16 00:23:13.061: //-1/xxxxxxxxxxxx/SIP/Info/sip_dns_type_srv_query: Priority 20 Weight 0 Port 5080
008563: Feb 16 00:23:13.061: //-1/xxxxxxxxxxxx/SIP/Info/sip_dns_type_srv_query: Server Name alpha15.callcentric.com
008564: Feb 16 00:23:13.061: //-1/xxxxxxxxxxxx/SIP/Info/sip_dns_type_srv_query: Priority 20 Weight 0 Port 5080
008565: Feb 16 00:23:13.061: //-1/xxxxxxxxxxxx/SIP/Info/sip_dns_type_srv_query: Server Name alpha16.callcentric.com
008566: Feb 16 00:23:13.061: //-1/xxxxxxxxxxxx/SIP/Info/sip_dns_type_srv_query: Priority 20 Weight 0 Port 5080
008567: Feb 16 00:23:13.061: //-1/xxxxxxxxxxxx/SIP/Info/sip_dns_type_srv_query: Server Name alpha17.callcentric.com
008568: Feb 16 00:23:13.061: //-1/xxxxxxxxxxxx/SIP/Info/sip_dns_type_srv_query: Priority 20 Weight 0 Port 5080
008569: Feb 16 00:23:13.061: //-1/xxxxxxxxxxxx/SIP/Info/sip_dns_type_srv_query: Selected Server is alpha18.callcentric.com
008570:  Feb 16 00:23:13.061: //-1/xxxxxxxxxxxx/SIP/Info/sip_dns_type_a_query:  TYPE A query successful for alpha18.callcentric.com
008571: Feb 16 00:23:13.061: //-1/xxxxxxxxxxxx/SIP/Info/sip_dns_type_a_query: ttl for A records = 263 seconds

 

+++Next DNS sends the ip address for the chosen device..204.11.192.170 (alpha18.callcentric.com)
008572: Feb 16 00:23:13.061: //-1/xxxxxxxxxxxx/SIP/Info/sip_dns_type_srv_query: IP Address of alpha18.callcentric.com is:
008573: Feb 16 00:23:13.061: //-1/xxxxxxxxxxxx/SIP/Info/sip_dns_type_srv_query: 204.11.192.170

 

+++NEXT CUBE sends a UDP connection to 204.11.192.170++++++++++


008620: Feb 16 00:23:13.077: //3343/A5A3315A8319/SIP/Transport/sipSPISendInvite: Sending Invite to the transport layer
008622:  Feb 16 00:23:13.077:  //3343/A5A3315A8319/SIP/Transport/sipSPITransportSendMessage:  msg=0x4A9AEC54, addr=204.11.192.170, port=5080, sentBy_port=0,  local_addr=192.168.1.203
008626: Feb 16 00:23:13.077:  //-1/xxxxxxxxxxxx/SIP/Transport/sipCreateConnHolder: Created new  holder=0x4A9B0760, addr=204.11.192.170; nailed=FALSE
008627: Feb 16  00:23:13.077:  //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportPostRequestConnection:  Posting UDP conn create request for addr=204.11.192.170, port=5080,  context=0x4840BD14

 

+++CUBE succesfully created a connection with 204.11.192.170+++++++++++

 

008638: Feb 16 00:23:13.081:  //-1/xxxxxxxxxxxx/SIP/Transport/sipConnectionManagerProcessConnCreated:  connection instance created for addr:204.11.192.170, port:5080  local_addr=192.168.1.203 local_port=49552

 

+++Next CUBE procceeds to send an outbound INVITE+++


008646: Feb 16  00:23:13.081: //3343/A5A3315A8319/SIP/State/sipSPIChangeState:  0x49630448 : State change from (STATE_IDLE, SUBSTATE_NONE)  to  (STATE_SENT_INVITE, SUBSTATE_NONE)


++++++but the INVITE appears to go to cucm when infact it wasnt sent there..it was sent to ITSP!!!!!!!!!!

 

Sent:
INVITE sip:17772253754@192.168.1.200:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.203:5060;branch=z9hG4bKD58157A
From: <sip:18165297500@callcentric.com>;tag=B46262C-230A
To: <sip:17772253754@192.168.1.200>

 

++++NEXT we get a response back from your ITSP requesting authentication++++++++

 

008670: Feb 16 00:23:13.181: //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor: Checking Invite Dialog
008671: Feb 16 00:23:13.181: //3343/A5A3315A8319/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 407 Proxy Authentication Required
v: SIP/2.0/UDP 192.168.1.203:5060;branch=z9hG4bKD58157A;rport=49552;received=24.123.98.94
f: <sip:18165297500@callcentric.com>;tag=B46262C-230A
t: <sip:17772253754@192.168.1.200>
i: A5AF6643-960911E3-831FFFD7-951695DD@callcentric.com
CSeq: 101 INVITE
Proxy-Authenticate:  Digest realm="callcentric.com", domain="sip:callcentric.com",  nonce="b69582701157bab55830417b7b62def9", opaque="", stale=TRUE,  algorithm=MD5
l: 0

 

This call was never sent to CUCM, it was sent to ITSP for onward forwarding to CUCM!!!!!!!!!!!!!!!!

 

Please rate all useful posts

Thanks guys, appreciate your input/analysis. I will try sometime over the weekend and let you know but you seem pretty confident on my problem!

Just tested it now gents, that did the trick!!

 

Thanks so much for your assistance!

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: