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. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

Dial-Peer SIP Binding Broken if Serial or Loopback is the Selected Source

For troubleshooting of a real world scenario, I created a HA CUBE lab. The real problem site has an ISR G2 with 3x Gigabit interfaces, but I had to use a 2801 to attempt to replicate potential dial-peer level SIP binding issues. In doing so, it appears that I have ran into another bug - binding is flatout broken on first gen ISRs running 15.1(4)M4. Here is the scenario just in case someone else runs into it:

Because only two Fa ports are included on the 2801 and no available Ethernet HWICs, we used a couple WIC-1T serial ports and a null serial to get a back to back up/up interface and a loopback for binding test. We first tested ISRs running 15.1(4)M4 ability to bind to an interface not in the ingress or egress path of the call. Here is the port scheme: Fa0/0 connects to WAN towards the SBC/ITSP, Fa0/1 connects to the LAN towards the phones and CUCM 7.1 lab server and S0/1/0 connects to a deadend router just used to bring the link up.

So, first we verified what dial-peer voice be selected if we dialed a specific number, 95125550000 for this example:

FLBgrmIDIQVGR01#show dialplan number 95125550000

Macro Exp.: 95125550000

VoiceOverIpPeer30002

        peer type = voice, system default peer = FALSE, information type = voice,

        description = `\\\\ Secondary SBC\\\\',

                    tag = 30002, destination-pattern = `9[2-9]..[2-9]......',

Next, we looked at the dial-peer to verify the binding was in place:

            dial-peer voice 30002 voip

description \\\\ Secondary SBC \\\\

translation-profile outgoing ToAudioCodes

preference 1

destination-pattern 9[2-9]..[2-9]......

session protocol sipv2

session target ipv4:{IP removed}

voice-class sip early-offer forced

voice-class sip bind control source-interface Serial0/1/0

voice-class sip bind media source-interface Serial0/1/0

dtmf-relay rtp-nte

no vad

Next, we make sure the interface was up/up to ensure it was feasible for binding:

Serial0/1/0                1.1.1.2 YES NVRAM  up                    up

       Loopback0                  1.1.1.1         YES manual up                    up

Then we placed calls and had one way or no way audio issues. This is what we found:

1. Outbound invites were not binding media or control to either the egress or dial-peer specified interface:

Sent:

INVITE sip:+15125550000@{IP removed}:5060 SIP/2.0

Via: SIP/2.0/UDP 10.101.97.241:5060;branch=z9hG4bKC1428

From: "8645465371" <sip:8645465371@10.101.97.241>;tag=23BA0920-16EC

To: <sip:+15125550000@{IP removed}>

Date: Wed, 29 Aug 2012 20:54:53 GMT

Call-ID: {removed}@10.101.97.241

Supported: 100rel,timer,resource-priority,replaces,sdp-anat

Min-SE:  1800

Cisco-Guid: 2646576098-4048687585-2149709943-0655887454

User-Agent: Cisco-SIPGateway/IOS-12.x

Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER

CSeq: 101 INVITE

Timestamp: 1346273693

Contact: <sip:8645465371@10.101.97.241:5060>

Expires: 1200

Allow-Events: telephone-event

Max-Forwards: 69

Session-Expires:  1800

Content-Type: application/sdp

Content-Disposition: session;handling=required

Content-Length: 273

v=0

o=CiscoSystemsSIP-GW-UserAgent 9700 2242 IN IP4 10.101.97.241

s=SIP Call

c=IN IP4 10.101.97.241                                 SDP message sent to the SBC showing the bind to Fa0/1 IP, vs S0/1/0

t=0 0

m=audio 16522 RTP/AVP 18 101

c=IN IP4 10.101.97.241

a=rtpmap:18 G729/8000

a=fmtp:18 annexb=no

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-15

a=ptime:20

2. Even a simple show dial-peer presented the binding issue saying that binding was enabled but showing the LAN ingress interface:

FLBgrmIDIQVGR01#show dial-peer voice 30002

VoiceOverIpPeer30002

        peer type = voice, system default peer = FALSE, information type = voice,

        description = `\\\\ Secondary SBC \\\\',

        tag = 30002, destination-pattern = `9[2-9]..[2-9]......',

        …. (removed over 50 lines ease of reading)

        voice class sip bind control = enabled, 10.101.97.241,             Show dial-peer output showing the bind to Fa0/1 IP

        voice class sip bind media = enabled, 10.101.97.241,

We then repeated these steps using a loopback interface instead of the serial for binding and showed the same results, bound to the LAN facing HSRP IP. We do not see the same behavior with the exact same configs on an IGR G2 2921 using the same inteface and voice configurations. There is no global binding enabled under voice service voip --> SIP. This is just food for thought is someone has ideas on how I should proceed and a note to let others who hit this fun anomoly that you aren't the only one. Since it is an ISR first Gen, I can't try the 15.2 train. I could rol back to 15.1.2T where this feature first became available. I haven't found a matching bug ID yet. Hopefully a solution will surface.

7 REPLIES
New Member

Dial-Peer SIP Binding Broken if Serial is the Selected Source

I removed the binding from the dial-peer which netted exected results, functional calling based on the egress interface IP being used for media source and destination. Address hiding again functioned as expected and the show dial-peer shows this:

        voice class sip bind control = system,

        voice class sip bind media = system,

Placing binding back on the dial-peer always cause the selection of the same IP regardless on interface choosen.

Dial-Peer SIP Binding Broken if Serial is the Selected Source

I run into a similar issue with this bug CSCth63196 that is no correction yet:

SIP source binding CLI removed after serial subinterface flaps
Symptom:
The sip source interface binding commands disappear after being configured and functional.

Workaround:

Reapply the CLI manually.

1st Found-In

12.4(20)T5

15.0(1)M2

Regards

Leonardo Santana

New Member

Dial-Peer SIP Binding Broken if Serial is the Selected Source

Did the workaround work for you? I have rebooted and reapplied numerous times all to no avail.

Dial-Peer SIP Binding Broken if Serial is the Selected Source

The workaround is reapply the commands:

Workaround:

Reapply the CLI manually.

Regards

Leonardo Santana

New Member

Dial-Peer SIP Binding Broken if Serial is the Selected Source

"Reapply the CLI Manually" was tested again and still does not work. That is not a valid workaround for all IOS trains. We have also now validated the issue exist when running a Cisco 3945 without manual binding. The LAN ingress HSRP interface which recieves the initial CUCM SIP Invite is used for outbound invites to the PSTN. Adding mode border-element, redirect ip2ip and address-hiding all have no effect.

New Member

Dial-Peer SIP Binding Broken if Serial is the Selected Source

TAC informed me that I have hit an identified bug. The cause is HSRP, which sucks because if you follow their HA Interop guide.... HSRP.....

New Member

Dial-Peer SIP Binding Broken if Serial is the Selected Source

Ok, here the work around as it stands for now. The HSRP group 0 interface (or lowest VMAC) will be selected from binding regardless if it exist when using all the HA configs. Dial-peer level binding is useless when following dual-attached CUBE HA model. So, make your ITSP/World facing HSRP pair group 0 in a HA rollout. Then globally bind media and signalling to that under Voice Service VoIP --> SIP for good messure. Route both your LAN and WAN (CUCM and ITSP) calls to this IP. Address hiding will still function. It is definately a sloopy work around, but works without fail for now. It is a virtual CUBE on a Stick.

2390
Views
0
Helpful
7
Replies