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

Sourcing SIP-UA registration from HSRP Virtual IP address

Hello,

One of my offices SIP trunks requires registration. In single CUBE mode this isn't an issue.

I have recently been configuring HSRP for CUBE HA and my registrations are being sourced by the interface IP rather than the HSRP Virtual IP address. In the current config, each router will attempt the registration and the last router to have registered with the ITSP receives SIP calls which breaks inbound calling when the standby router receives the INVITE.

Is there a method of binding SIP-UA registrations to interfaces as it can be done with dial-peers, or another method of forcing the source IP of SIP registrations? I thought maybe I could track the HSRP Virtual IP and only have the route to the ITSP sip server come up when the Virtual IP was active but I don't see a way to do this.

 

Right now registrations are coming from both active and standby routers, via their interface IP's:

Note: Virtual IP facing ITSP is 89.1.32.190
 
Registration accepted from 89.1.32.189:
 
000113: Sep 30 20:17:56.450: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent: 
REGISTER sip:89.1.0.54:5060 SIP/2.0
Via: SIP/2.0/UDP 89.1.32.190:5060;branch=z9hG4bK1F193E
From: <sip:+49221261030@89.1.0.54>;tag=1AEAF4-22F7
To: <sip:+49221261030@89.1.0.54>
Date: Tue, 30 Sep 2014 20:17:56 GMT
Call-ID: AF15F8AF-480F11E4-80028500-CEF4C1B9
User-Agent: Cisco-SIPGateway/IOS-15.2.4.M2
Max-Forwards: 70
Timestamp: 1412108276
CSeq: 31 REGISTER
Contact: <sip:+49221261030@89.1.32.190:5060>
Expires:  180
Supported: path
Authorization: Digest username=<snip>
Content-Length: 0
 
 
000114: Sep 30 20:17:56.466: //33/000000000000/SIP/Msg/ccsipDisplayMsg:
Received: 
SIP/2.0 200 OK
Via: SIP/2.0/UDP 89.1.32.190:5060;received=89.1.32.189;branch=z9hG4bK1F193E;rport=62638
From: <sip:+49221261030@89.1.0.54>;tag=1AEAF4-22F7
To: <sip:+49221261030@89.1.0.54>;tag=1804a47d+1+af830016+103adcf8
Call-ID: AF15F8AF-480F11E4-80028500-CEF4C1B9
CSeq: 31 REGISTER
Content-Length: 0
Contact: <sip:+49221261030@89.1.32.190:5060>;expires=45
 
Registration accepted from 89.1.32.190:
 
000200: Sep 30 20:17:32.762: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent: 
REGISTER sip:89.1.0.54:5060 SIP/2.0
Via: SIP/2.0/UDP 89.1.32.190:5060;branch=z9hG4bK1F2619
From: <sip:+49221261030@89.1.0.54>;tag=1A9AA4-1BDD
To: <sip:+49221261030@89.1.0.54>
Date: Tue, 30 Sep 2014 20:17:32 GMT
Call-ID: 85CD8344-481111E4-8002D512-9571934D
User-Agent: Cisco-SIPGateway/IOS-15.2.4.M6a
Max-Forwards: 70
Timestamp: 1412108252
CSeq: 30 REGISTER
Contact: <sip:+49221261030@89.1.32.190:5060>
Expires:  180
Supported: path
Authorization: Digest username=<snip>
Content-Length: 0
 
000201: Sep 30 20:17:32.774: //30/000000000000/SIP/Msg/ccsipDisplayMsg:
Received: 
SIP/2.0 200 OK
Via: SIP/2.0/UDP 89.1.32.190:5060;received=89.1.32.188;branch=z9hG4bK1F2619;rport=64151
From: <sip:+49221261030@89.1.0.54>;tag=1A9AA4-1BDD
To: <sip:+49221261030@89.1.0.54>;tag=1804a47d+1+ca570016+fa02f33e
Call-ID: 85CD8344-481111E4-8002D512-9571934D
CSeq: 30 REGISTER
Content-Length: 0
Contact: <sip:+49221261030@89.1.32.190:5060>;expires=45
 
 
 
Active router:
 
interface GigabitEthernet0/0
 description $ETH-LAN$$ETH-SW-LAUNCH$$INTF-INFO-GE 0/0$
 ip address 10.1.1.9 255.255.255.0
 standby delay minimum 30
 standby version 2
 standby 0 ip 10.1.1.6
 standby 0 preempt
 standby 0 name SB
 standby 0 track 1 shutdown
 duplex auto
 speed auto
 
interface GigabitEthernet0/1
 ip address 89.1.32.188 255.255.255.248
 standby delay minimum 30
 standby version 2
 standby 1 ip 89.1.32.190
 standby 1 preempt
 standby 1 track 2 shutdown
 duplex auto
 speed auto
 
ip route 0.0.0.0 0.0.0.0 10.1.1.1
ip route 89.1.0.54 255.255.255.255 89.1.32.185
 
 
Standby router:
 
interface GigabitEthernet0/0
 description $ETH-LAN$$ETH-SW-LAUNCH$$INTF-INFO-GE 0/0$
 ip address 10.1.1.10 255.255.255.0
 standby delay minimum 30
 standby version 2
 standby 0 ip 10.1.1.6
 standby 0 priority 99
 standby 0 name SB
 standby 0 track 1 shutdown
 duplex auto
 speed auto
!         
interface GigabitEthernet0/1
 ip address 89.1.32.189 255.255.255.248
 standby delay minimum 30
 standby version 2
 standby 1 ip 89.1.32.190
 standby 1 priority 99
 standby 1 track 2 shutdown
 duplex auto
 speed auto
 
ip route 0.0.0.0 0.0.0.0 10.1.1.1
ip route 89.1.0.54 255.255.255.255 89.1.32.185
 
 
Thanks for any help.
 
 
 
7 REPLIES
New Member

Same Problem here!Do you have

Same Problem here!

Do you have any Solution?

New Member

Hi Matt,

Hi Matt,

did you find any reasonable solution other than disabling SIP trunk registration? I've posted the same question just few days ago ;) Running IOS 15.4.3M4.

New Member

Hi Marcel,

Hi Marcel,

i add the "bind control" command to "voice service voip".  IMHO this enable binding for all SIP packets by default.

voice service voip
 address-hiding
 mode border-element
 allow-connections sip to sip
 redundancy
 redirect ip2ip
 sip
  bind control source-interface GigabitEthernet0/2
  early-offer forced

If a dial-peer need another source-interface, add the "sip bind control" command to the dial-peer

New Member

Thanks Sasha,

Thanks Sascha,

it looked promising but unfortunately "bind control" under global config breaks communication from inside interface (facing from CUCM). On the other hand it fixed the REGISTRATION to external SBC.

Sure I have bind statements defined with all the dial-peers. I'll try to add incoming dial-peer matching URI Via field in OPTIONS.

!
voice class uri 1 sip
host ipv4:1.1.1.10

!

!
dial-peer voice 200 voip
session protocol sipv2
incoming uri via 1
voice-class sip bind control source-interface GigabitEthernet0/0
voice-class sip bind media source-interface GigabitEthernet0/0
dtmf-relay rtp-nte
no vad
!

Marcel

New Member

Hi Marcel,

Hi Marcel,

do you use incoming dial-peers?

You can also use bind-control for incoming dial-peer. Then the CUBE answer with the right IP.

New Member

Hi Sascha,

Hi Sascha,

yes that's the critical part. With the incoming voip dial-peer configuration everything works as expected. Anyway it still looks like a workaround to me, not a real config. Doesn't make sense if everything else except REGISTER uses the VIP address (same behavior with CSR 1000V on IOS XE in CUBE HA).

Marcel

New Member

 Hmm, i can´t confirm this

 Hmm, i can´t confirm this behaviour. In my config everything use VIP(2x ISR 2951).

 

Can you post your config?

331
Views
5
Helpful
7
Replies
CreatePlease login to create content