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.
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.
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.
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
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.
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.
I was told a way that solves this issue, with Voice class uri:
voice class uri 10 sip
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.