sip-option sourcing only from real interface?

[Sinisa Hreljac]

Hi,

I have a problem with IP address from which CUBE sends sip-option reasponse to remotely CUBE. On dial-peer which handles SIP calls towards remote SIP CUBE is configured:

voice-class sip bind control source-interface Loopback1

voice-class sip bind media source-interface Loopback1

And for ordinary SIP calls, that works OK. But, when my CUBE receive SIP option message from remote CUBE (which is configured with "voice-class sip options-keepalive" option on dialpeer towards my CUBE), it responds to that message sourcing from IP address of real interface, not loopback1.

In that case, my reasponse never returns to remote CUBE because of routing and firewall between this two CUBES. Only traffic that is allowed is from and to my loopback1 interface IP...not real interface IP.

Is there possible to make that loopback1 is source for sip-option reasponse messages?

And that should not be global configuration, because I need to be possible to respond on other sip option messages from other CUBEs, that are connected on other real and loopback interfaces.

Thanks,

S.

[Ayodeji Okanlawon]

Have you tried configuring a dial-peer towards the remote CUBE and enabling options ping on that dial-peer. You can then source your sip traffic from the loopback1 interface on that dial-peer. Perhaps this may force your local CUBE to respond to options PING from the same interface.

Options ping is sip signalling, so if there is no specific interface configured to respond to it, CUBE will source from the interfaces closest to the destination of the SIP packet to respond to the options ping.

[Sinisa Hreljac]

Yes I tried that. Interesting thing is that in that case, my CUBE options ping request towards remote CUBE is sourced from right loopback interface, but my CUBE response to remotely initiated options ping request is still sourced from wrong interface (real interface IP). Strange behaviour...but then, and some of remote CUBEs that are using loopback interface instead of real interface are faceing same problem.

[Ayodeji Okanlawon]

I guessed that this might be the case. The problem is that when a response is sourced for the OPTIONS ping, there is no dial-peer or something of sort to tie the response to as when you originate the request using a dial-peer. I do not know of any way to force a sip options ping response via a specific interface

[Sinisa Hreljac]

Hmm...but acctually I think that this is flow in SIP option design in Cisco. When CUBE receives SIP option message, it knows on witch IP address is received (looking at L3 information at network package) so it can easily figure out with wich IP address  reasponse should be sourced. Also, source IP for reasponse could easily be determined by SIP headers in SIP option message, because there are informations with sender and receiver IP.

There is even third method to determine correct source IP; as in SIP header source and destination IP is known, it can lookup at witch dial-peer is appearing IP address of remote CUBE and apply binding that is configured at that dial-peer.

So, there are three possible methods that I can figure out to determine correct source IP for response on SIP option message, but Cisco is not using any of them. The question is...why? Current behaviour does not make any sense to me.

[Vivek Batra]

This is really interesting and confusing too.

AFAIK, CUBE doens't check dial-peer configuration while recieving OPTION message. It should use the same interface to give response on which OPTION message was recieved. I would definitely like to give a try on it as soon as possible.

- Vivek

[jesus Barrios]

Hi there is an update for this case, I have the same problem. :(

[Jose Goncalves]

Did anyone got this issue solved?

i'm trying with Sip profiles, but not being able to do so.

[Jose Goncalves]

I was told a way that solves this issue, with Voice class uri:

voice class uri 10 sip
host XXX.XXX.XXX.XXX
!
dial-peer voice 6000 voip
description Default PSTN -> Cube
session protocol sipv2
session target sip-uri
session transport udp
incoming uri from 10
voice-class sip bind control source-interface Loopback0
voice-class sip bind media source-interface Loopback0
!

You can base your default dial-peer on the remote IP address os the via uri and the the response of the SIP-options will be based on the voice-class sip bind commands on that dial-peer.

You can give it a trie.

[reindl_mc]

I was trying your workaround - but it did not work for me

I think to answer SIP Option Pings - there is no need to match a dial-peer. And when no dial-peer is matching it will not use the Loopback address which is bind to answer the Pings. Therefore cube takes the interface address where it receives the message.

The only workaround for me was to configure the Loopback binding globally under voip service voip - sip. Then it uses  always this address to answer Pings.

kind regards

[Roger Kallberg]

SIP option ping does absolutely use dial peer to match the interface. If this doesn’t work for you there is something that is incorrect in your configuration. My preference for inbound dial peer match is to use VIA header information. Make sure that your inbound dial peer match as you intended it in configuration.

[Anthony McGarry]

This worked for me when using the redundancy group VIP on the interface in a CUBE HA solution. Thanks 

[UjjwalGoel49281]

Configure the interface from which you want the responses to be sent under voice service voip. For example if you are receiving the options ping on the loopback100(external interface) from the gsip/itsp provider then configure below to generate responses from the loopback100:

voice service voip

   sip
   bind control source-interface Loopback100
   bind media source-interface Loopback100