10-09-2014 09:12 PM - edited 03-17-2019 12:30 AM
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.
Solved! Go to Solution.
10-10-2014 01:10 AM
remove ,
outbound-proxy dns:sip.STATE.OTHERCOMPANY.net.au
and test
send the same logs if it fails
10-10-2014 02:48 AM
(+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:
+++Next CUBE sends a trying to ITSP..Before it does that it needs to establish a TCP connection+++
008382: Feb 16 00:23:12.949: //3342/A5A3315A8319/SIP/Transport/sipTransportLogicSendMsg: Trying to send resp=0x49E83E84 to default port=5080
Sent:
+++Next CUBE needs to send an INVITE out to CUCM+++
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
+++CUBE does a SRV DNS query (looks like your DNS is configured for SRV++++++++++++
++++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
+++Next DNS sends the ip address for the chosen device..204.11.192.170 (alpha18.callcentric.com)
+++NEXT CUBE sends a UDP connection to 204.11.192.170++++++++++
+++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+++
Sent:
++++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
This call was never sent to CUCM, it was sent to ITSP for onward forwarding to CUCM!!!!!!!!!!!!!!!! |
10-10-2014 12:05 AM
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
10-10-2014 12:41 AM
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.
10-10-2014 12:46 AM
are you not seeing any invite from cube in cucm traces ?
as requested , pls bind the correct interfaces in the dial-peer
10-10-2014 12:56 AM
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
10-10-2014 12:58 AM
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:
10-10-2014 01:05 AM
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
10-10-2014 01:10 AM
remove ,
outbound-proxy dns:sip.STATE.OTHERCOMPANY.net.au
and test
send the same logs if it fails
10-10-2014 02:48 AM
(+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:
+++Next CUBE sends a trying to ITSP..Before it does that it needs to establish a TCP connection+++
008382: Feb 16 00:23:12.949: //3342/A5A3315A8319/SIP/Transport/sipTransportLogicSendMsg: Trying to send resp=0x49E83E84 to default port=5080
Sent:
+++Next CUBE needs to send an INVITE out to CUCM+++
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
+++CUBE does a SRV DNS query (looks like your DNS is configured for SRV++++++++++++
++++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
+++Next DNS sends the ip address for the chosen device..204.11.192.170 (alpha18.callcentric.com)
+++NEXT CUBE sends a UDP connection to 204.11.192.170++++++++++
+++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+++
Sent:
++++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
This call was never sent to CUCM, it was sent to ITSP for onward forwarding to CUCM!!!!!!!!!!!!!!!! |
10-10-2014 04:26 AM
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!
10-14-2014 03:10 PM
Just tested it now gents, that did the trick!!
Thanks so much for your assistance!
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: