09-17-2014 10:34 AM - edited 03-17-2019 12:11 AM
Hello,
I've been attempting to configure a 2nd cube at our main site with HSRP. Inbound calls (I've only been testing inbound at this point) disconnect after about 15-20 seconds without any DTMF response from the IVR (unity). SIP messages from the ITSP side appear to be continuously sending invites trying to do media negotiation.
I've bound the control and media source interfaces to the appropriate dial-peers (which was required to get the cube to source its traffic from the VIP). Initially I was using tagged sub-interfaces on g0/0 but split the configs out to g0/0 and g0/1 just in case there was an issue there, but to no effect.
I read a post from a Cisco rep saying that DSP resources couldn't be in use on the cube while in HA mode, so I've disabled those as well.
I've attached the failed config if anyone has some pointers.
Also, I've been testing with only one cube configured at this point.
Topology:
ITSP -> g0/1 cube g0/0 -> cucm
Pertinent configs:
ipc zone default
association 1
no shutdown
protocol sctp
local-port 5000
local-ip 10.0.250.5
remote-port 5000
remote-ip 10.0.250.6
voice service voip
no ip address trusted authenticate
mode border-element
allow-connections h323 to h323
allow-connections h323 to sip
allow-connections sip to h323
allow-connections sip to sip
redundancy
redirect ip2ip
fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none
sip
early-offer forced
midcall-signaling passthru
no call service stop
registration passthrough
!
voice class codec 1
codec preference 1 g711ulaw
!
redundancy inter-device
scheme standby SB
interface GigabitEthernet0/0
description $ETH-LAN$$ETH-SW-LAUNCH$$INTF-INFO-GE 0/0$
ip address 10.0.250.5 255.255.255.0
no ip route-cache
standby delay minimum 30 reload 60
standby version 2
standby 0 ip 10.0.250.4
standby 0 preempt
standby 0 name SB
standby 0 track 1 shutdown
duplex auto
speed auto
!
interface GigabitEthernet0/1
ip address 10.0.1.68 255.255.255.248
standby delay minimum 30 reload 60
standby version 2
standby 0 track 2 shutdown
standby 1 ip 10.0.1.67
standby 1 preempt
duplex auto
speed auto
!
ip route 0.0.0.0 0.0.0.0 10.0.250.1
ip route 173.46.30.0 255.255.255.0 10.0.1.65
sccp ccm 10.0.6.30 identifier 1 version 7.0
!
sccp ccm group 1
bind interface GigabitEthernet0/0
associate ccm 1 priority 1
dial-peer voice 10 voip
description ** Incoming call from Rogers trunk main line/main line TF **
call-block translation-profile incoming all-blacklist
call-block disconnect-cause incoming call-reject
destination-pattern 5195132407
monitor probe icmp-ping 10.0.6.30
session protocol sipv2
session target ipv4:10.0.6.30
session transport udp
incoming called-number 5195132407
voice-class codec 1
voice-class sip bind control source-interface GigabitEthernet0/0
voice-class sip bind media source-interface GigabitEthernet0/0
dtmf-relay rtp-nte
dtmf-interworking standard
no vad
dial-peer voice 50 voip
description ** Outbound call to Rogers trunk **
preference 4
destination-pattern ....T
session protocol sipv2
session target ipv4:173.46.30.202
session transport udp
voice-class codec 1
voice-class sip bind control source-interface GigabitEthernet0/1
voice-class sip bind media source-interface GigabitEthernet0/1
dtmf-relay rtp-nte
dtmf-interworking standard
no vad
gateway
media-inactivity-criteria all
timer receive-rtcp 5
timer receive-rtp 86400
!
sip-ua
no remote-party-id
retry invite 10
retry register 10
host-registrar
Thanks
09-17-2014 12:35 PM
can you send us "debug ccsip messages"
09-17-2014 08:51 PM
For sure; I've attached a couple debug files.
I can hear Unity IVR but DTMF is not recognized. Audio drops completely at 14-15 seconds and the call disconnects at 19 seconds.
I also notice one of the call legs hangs around for a while after the call is disconnected:
2951-01-kit#show sip calls br <-- during call
Total SIP call legs:2, User Agent Client:1, User Agent Server:1
SIP UAC CALL INFO
No. CallId Calling# Called# RmtSignalIP RmtMediaIP
dstCallId SIPState SIPSubState
================================================================================
1 1006 my cell 5195132407 10.0.6.30 10.0.6.32
1005 STATE_ACTIVE SUBSTATE_NONE
Number of SIP User Agent Client(UAC) calls: 1
SIP UAS CALL INFO
No. CallId Calling# Called# RmtSignalIP RmtMediaIP
dstCallId SIPState SIPSubState
================================================================================
1 1005 my cell 5195132407 173.46.30.202 173.46.30.202
1006 STATE_SENT_SUCCSUBSTATE_NONE
Number of SIP User Agent Server(UAS) calls: 1
2951-01-kit#show sip calls br <-- 20 seconds after disconnect
Total SIP call legs:1, User Agent Client:0, User Agent Server:1
SIP UAC CALL INFO
Number of SIP User Agent Client(UAC) calls: 0
SIP UAS CALL INFO
No. CallId Calling# Called# RmtSignalIP RmtMediaIP
dstCallId SIPState SIPSubState
================================================================================
1 1005 my cell 5195132407 173.46.30.202 173.46.30.202
-1 STATE_DISCONNECSUBSTATE_NONE
Number of SIP User Agent Server(UAS) calls: 1
Thanks
09-18-2014 01:36 AM
Hi,
From the logs..
Your ITSP is not responding to the 200 OK.
Sent:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 173.46.30.202:5060;branch=z9hG4bKp3k5if10002hbmcdq131.1
From: "STEVEN DAINARD"<sip:my cell@173.46.30.202:5060>;tag=as3579dd31
To: <sip:5195132407@10.0.1.67:5060>;tag=3052C-178D
Date: Thu, 18 Sep 2014 03:32:40 GMT
Call-ID: 6eb3530d07bdedcd396fc5f211da4217@173.46.30.12
CSeq: 102 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Contact: <sip:5195132407@10.0.250.4:5060>
Supported: replaces
Supported: sdp-anat
Server: Cisco-SIPGateway/IOS-15.2.4.M2
Supported: timer
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 241
v=0
o=CiscoSystemsSIP-GW-UserAgent 7769 9267 IN IP4 10.0.250.4
s=SIP Call
c=IN IP4 10.0.250.4
t=0 0
m=audio 16384 RTP/AVP 0 101
c=IN IP4 10.0.250.4
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
After resending the 200 OK 6 times, the gateway sent a BYE..
Sent:
BYE sip:5195132407@10.0.6.30:5060 SIP/2.0
Via: SIP/2.0/UDP 10.0.250.4:5060;branch=z9hG4bK2B8B
From: "STEVEN DAINARD" <sip:my cell@10.0.250.4>;tag=30514-C5B
To: <sip:5195132407@10.0.6.30>;tag=339490~d732e07f-799a-4d2b-9d6a-ae2aaf54507d-21797806
Date: Thu, 18 Sep 2014 03:32:40 GMT
Call-ID: 473955C0-3E1B11E4-8008BD5F-E05D01F3@10.0.250.4
User-Agent: Cisco-SIPGateway/IOS-15.2.4.M2
Max-Forwards: 70
Timestamp: 1411011175
CSeq: 102 BYE
Reason: Q.850;cause=102 (recovery on timer expiry)
P-RTP-Stat: PS=0,OS=0,PR=750,OR=120000,PL=0,JI=0,LA=0,DU=15
Content-Length: 0
We need to investigate why your ITSP is not responding to the 200 OK. It is possible that you may not be sending this to the correct signalling IP..Before you contact them please configure the ff on your CUBE..
service sequence-numbers
service timestamps debug datetime localtime msec
logging buffered 10000000 debug
no logging console
no logging monitor
default logging rate-limit
default logging queue-limit
Then..
<Enable debugs>
debug ccsip all
Test again
<Enable session capture to txt file in terminal program.> (such as Putty)
then do the ff:
terminal length 0
show logging
Please attach here..
09-18-2014 11:37 AM
I'll run though this once we're out of production.
I need some clarity on the interpretation of the 200 OK. The example you posted seems to be the opposite scenario, where the cube isn't responding to the ITSP's 200 OK:
ITSP: 173.46.30.202
cube external interface IP: 10.0.1.67
cube internal interface IP: 10.0.250.4
CUCM IP: 10.0.6.30
Sent:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 173.46.30.202:5060;branch=z9hG4bKp3k5if10002hbmcdq131.1 <-- ITSP IP
From: "STEVEN DAINARD"<sip:my cell@173.46.30.202:5060>;tag=as3579dd31 <-- ITSP IP
To: <sip:5195132407@10.0.1.67:5060>;tag=3052C-178D <-- cube external int IP
Date: Thu, 18 Sep 2014 03:32:40 GMT
Call-ID: 6eb3530d07bdedcd396fc5f211da4217@173.46.30.12
CSeq: 102 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Contact: <sip:5195132407@10.0.250.4:5060> <-- cube internal int IP + note1 below
Supported: replaces
Supported: sdp-anat
Server: Cisco-SIPGateway/IOS-15.2.4.M2
Supported: timer
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 241
v=0
o=CiscoSystemsSIP-GW-UserAgent 7769 9267 IN IP4 10.0.250.4 <-- cube internal int IP
s=SIP Call
c=IN IP4 10.0.250.4 <-- cube internal int IP
t=0 0
m=audio 16384 RTP/AVP 0 101
c=IN IP4 10.0.250.4 <-- cube internal int IP
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
note1: I thought the contact field was the uri of the invite initiator, but if I'm correct and the ITSP is sending the OK to the external interface of the cube, shouldn't this be the cube external ip ?
Here is a 200 OK from a non-HSRP inbound call that works properly, the order makes much more sense to me:
Sent:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 173.46.30.202:5060;branch=z9hG4bKvliful307801ek8c5481.1 <-- ITSP IP
From: "STEVEN DAINARD"<sip:my cell@173.46.30.202:5060>;tag=as76e58b53 <-- ITSP IP
To: <sip:5195132407@10.0.1.67:5060>;tag=3085E4C-126A
Date: Thu, 18 Sep 2014 18:03:04 GMT
Call-ID: 5bd10cdd539483225207d03702970bb6@173.46.30.13
CSeq: 102 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Contact: <sip:5195132407@10.0.1.67:5060> <-- cube external int IP
Supported: replaces
Supported: sdp-anat
Server: Cisco-SIPGateway/IOS-15.2.4.M2
Supported: timer
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 238
v=0
o=CiscoSystemsSIP-GW-UserAgent 6145 5404 IN IP4 10.0.1.67 <-- cube external int IP
s=SIP Call
c=IN IP4 10.0.1.67 <-- cube external int IP
t=0 0
m=audio 16892 RTP/AVP 0 101
c=IN IP4 10.0.1.67 <-- cube external int IP
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
So it seems that while configured for HSRP the ITSP gets a message to use the Internal cube int IP as its contact, but I don't see anything in that messages trace to indicate where that happened.
09-18-2014 05:41 PM
Hi, let me try and explain a few things that will hopefully clarify things up..
1. a 200 OK is a response to a request. Hence it can only be sent by the called party. This is an inbound call to CUBE, in sip language this is a request sent by the ITSP. For the call to complet CUBE needs to send the following
1a.Upon recieve if the initial INVITE, sends a trying ( this is used to stop re-transmission, so tha the other part knows that I have received your request)
1b. Sends a session progress (183 with SDP) or a ringing 180
1c. Then sends a 200 OK with SDP.
1d. FInally ITSP (or the originator of the request) needs to send an ACK to the 200 OK.
Secondly, the via header can be a little confusing..but here is the summary.
The required (it is mandatory) Via header field is used to record the SIP route taken by a request and is used to route a response back to the originator. A UA generating a request records its own address in a Via header field.
As you can see in the via header above your ITSP has put its ip address and that is where all signalling responses to this request must go. It is important to note that all further responses to this request will contain this via header field. Part of this is because a UA will copy mandatory sip header fields from the originator when it recieves a request. So your 100 trying, 180 ringing, 200 OK sent by CUBE will have this via header field
Now to the contact field, and you are right..this is where the issue is..We need to first of all understand the contact header..so here are a few lines
From this we can deduct that your ITSP needs to send the ACK back to the URI in the contact header field..The problem here is that the host portion of your contact header field "10.0.250.4" is not reachable from the ITSP, hence the reason why we do not get the ACK back from the ITSP.
Contact: <sip:5195132407@10.0.250.4:5060
For the call that worked, the host portion of the contact header field contains a routable IP address, hence why this worked.
To understand more on sip traces please refer to this document I wrote a while back..
https://supportforums.cisco.com/document/113271/understanding-sip-traces
Back to the issue..the question is why is CUBE sending its internal ip as its contact host..This may be a bug! You can use the following sip profile to modify this:
NB: you wuill also need to modify your connection-info value because this is where your media is sent to. I also saw that your 200 OK had multiple connection-info values. This can cause one way audio issues..The last sip profile removes the duplicate..
voice class sip-profiles 1
response 200 sip-header Contact modify "<sip:(.*)@10.0.250.4:5060>" "<sip:\1@10.0.1.67:5060>"
response 200 sdp-header Connection-Info modify "10.0.250.4" "10.0.1.67"
response 200 sdp-header Connection-Info remove
Then apply this on the dial-peer going to your ITSP
dial-peer voice 50 voip
voice-class sip profiles 1
Remember to apply this on both CUBES
09-24-2014 01:01 AM
Good info, much appreciated.
But unfortunately I still can't get this working properly.
I applied the sip-profile to dial-peer 10 (inbound call) and was able to modify the contact details in the sip header, and some of the sdp header info as well, but that 2nd connection info field you mentioned is very persistent.
voice class sip-profiles 1
response 200 sip-header Contact modify "<sip:(.*)@10.0.250.4:5060>" "<sip:\1@10.0.1.67:5060>"
response 200 sdp-header Session-Owner modify "10.0.250.4" "10.0.1.67"
response 200 sdp-header Connection-Info modify "10.0.250.4" "10.0.1.67"
response 200 sdp-header Connection-Info remove
.. results in removing the modified field, and leaving the 2nd connection info field in place.
//1037/D90C50DD807B/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 173.46.30.202:5060;branch=z9hG4bKt82298300gth1lsil2s1.1
From: "STEVEN DAINARD"<sip:my cell@173.46.30.202:5060>;tag=as7e7a9a10
To: <sip:5195132407@10.0.1.67:5060>;tag=31EFD4-1A92
Date: Wed, 24 Sep 2014 07:25:51 GMT
Call-ID: 697f50aa6ead0ecb79909e154781a54e@173.46.30.12
CSeq: 102 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Contact: <sip:5195132407@10.0.1.67:5060>
Supported: replaces
Supported: sdp-anat
Server: Cisco-SIPGateway/IOS-15.2.4.M6a
Supported: timer
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 219
v=0
o=CiscoSystemsSIP-GW-UserAgent 9101 4846 IN IP4 10.0.1.67
s=SIP Call
t=0 0
m=audio 16456 RTP/AVP 0 101
c=IN IP4 10.0.250.4
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
If I omit the 'remove' line, I end up with 2 connection info fields, one modified, the other still containing 10.0.250.4.
If I add 3 remove statements (more than should be necessary) the sdp header still contains a connection info field. If add 2 remove statements, and then an 'add' statement, I end up with 2 connection info fields again, one incorrect.
I'm now running the newest version of IOS on the router in case this was a bug that had been fixed.
It seems really odd this wouldn't work out of the box. I'm also having a really hard time determining how the ITSP is even getting the 10.0.250.4 IP address to use in its messaging to begin with, I can't see any other messages from the externally facing IP to the ITSP's IP containing that address.
I'm starting to wonder if its because of the sip bind commands on the dial-peer, but of course thats a required part of the config for HSRP.
09-24-2014 01:21 AM
This is indeed a very strange behaviour. The sip bind statements are fine because you have selected the correct interface for both otubound and inbound traffic. You actually dont need this for HSRP config, however its a good idea. I will suggest that you try something different. Remove the sip bind statements and let the router select its signalling source. Ideally cisco IOS should select a source closes to the destination the packet is intended for. ie the internal ip for cucm and external ip for ITSP. Give that ago and see what happens..Its worth trying..
I am curios to know if you get the ACK back from your ITSP now since you are sending the correct contact header.
09-25-2014 09:00 PM
I wanted to follow up with the eventual solution if anyone runs into this in a search.
The problem (which isn't a problem without HSRP) is that my inbound and outbound dial-peers were combined, each containing a destination-pattern (cucm call leg) and a incoming-called number (ITSP call leg).
Once HSRP is added to the mix, its required to bind the interfaces in the dial-peers going to cucm, so that the cube signals using the VIP, and not the interface IP address.
The original dial-peer for one of my DID's was (no HSRP):
dial-peer voice 10 voip
description ** Incoming call from Rogers trunk main line/main line TF **
call-block translation-profile incoming all-blacklist
call-block disconnect-cause incoming call-reject
destination-pattern 5195132407
monitor probe icmp-ping 10.0.6.30
session protocol sipv2
session target ipv4:10.0.6.30
session transport udp
incoming called-number 5195132407
voice-class codec 1
dtmf-relay rtp-nte
dtmf-interworking standard
no vad
The new set of dial-peers covering both call legs is:
dial-peer voice 10 voip
description ** Incoming call from Rogers trunk main line/TF - CUCM LEG **
call-block translation-profile incoming all-blacklist
call-block disconnect-cause incoming call-reject
destination-pattern 5195132407
monitor probe icmp-ping 10.0.6.30
session protocol sipv2
session target ipv4:10.0.6.30
session transport udp
voice-class codec 1
voice-class sip asserted-id pai
voice-class sip bind control source-interface GigabitEthernet0/0
voice-class sip bind media source-interface GigabitEthernet0/0
dtmf-relay rtp-nte
dtmf-interworking standard
no vad
dial-peer voice 11 voip
description ** Incoming call from Rogers trunk main line/TF - ITSP LEG **
call-block translation-profile incoming all-blacklist
call-block disconnect-cause incoming call-reject
monitor probe icmp-ping 10.0.6.30
session protocol sipv2
session target ipv4:10.0.6.30
session transport udp
incoming called-number 5195132407
voice-class codec 1
voice-class sip asserted-id pai
dtmf-relay rtp-nte
dtmf-interworking standard
no vad
AO, thanks for sticking with me and helping to work through it.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide