Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

cube sip hsrp media negotiation failing

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

 

 

 

 

8 REPLIES
VIP Super Bronze

can you send us "debug ccsip

can you send us "debug ccsip messages"

Please rate all useful posts "The essence of christianity is not the enthronement but the obliteration of self --William Barclay"
New Member

For sure; I've attached a

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

VIP Super Bronze

Hi,From the logs..Your ITSP

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..

 

Please rate all useful posts "The essence of christianity is not the enthronement but the obliteration of self --William Barclay"
New Member

I'll run though this once we

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.

VIP Super Bronze

Hi, let me try and explain a

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

The Contact header field is used to convey a URI that identifies the resource
requested or the request originator, depending on whether it is present in a request
or response. Once a Contact header fi eld has been received, the URI can
be cached and used for routing future requests within a dialog. For example, a
Contact header field in a 200 OK response to an INVITE can allow the acknowledgment ACK message
and all future requests during this call to bypass proxies and go directly to the called party
In some cases, the Contact URI may not resolve directly
to the user agent. For example, a UA behind a fi rewall ALG will need to use a
Contact URI that resolves to the fi rewall ALG address

 

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
 

Please rate all useful posts "The essence of christianity is not the enthronement but the obliteration of self --William Barclay"
New Member

Good info, much appreciated

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.

VIP Super Bronze

This is indeed a very strange

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.

Please rate all useful posts "The essence of christianity is not the enthronement but the obliteration of self --William Barclay"
New Member

I wanted to follow up with

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.

 

744
Views
30
Helpful
8
Replies
CreatePlease login to create content