[cisco-voip] SIP Binding: Different Binds for Carrier vs Internal

Fri Sep 11 22:16:07 EDT 2020

Doh! You're absolutely right.  It was a mistake in thought process on my
part.  You would not need to bind if a single interface.  You would only
need to bind when there is more than one possible egress interface to
source your traffic from.

In your case, with loopbacks, you'll need to bind.

Something tricky the CUBE does, in my opinion, is how it responds to
OPTIONS messages.  You will need to either match your incoming leg on Via
header, or create a specific dial-peer matching on Via header just to set
the bind, to the OPTIONS reply uses the correct interface.

On Fri, Sep 11, 2020 at 6:34 PM Matthew Loraditch <
MLoraditch at heliontechnologies.com> wrote:

> The way you  have #2 written is bothering me, if you only have one
> interface period you should never need to bind, but if you only have one
> egress interface and need certain traffic to be on IP A and some on IP B
> (via loopbacks) then you would need to bind and that is my scenario.
>
>
>
>
>
> I have a complicated (to me!) routing situation and I need my PSTN traffic
> to the ITSP to be on an IP that only they know about and my internal
> traffic to be the same. This was the best way I could think of to make that
> happen.
>
>
>
>
>
>
>
>
>
>
>
>
>
> Matthew Loraditch
> Sr. Network Engineer
> p: *443.541.1518* <443.541.1518>
> w: *www.heliontechnologies.com* <http://www.heliontechnologies.com/>  |
> e: *MLoraditch at heliontechnologies.com* <MLoraditch at heliontechnologies.com>
> [image: Helion Technologies] <http://www.heliontechnologies.com/>
> [image: Facebook] <https://facebook.com/heliontech>
> [image: Twitter] <https://twitter.com/heliontech>
> [image: LinkedIn] <https://www.linkedin.com/company/helion-technologies>
>
> *From:* Anthony Holloway <avholloway+cisco-voip at gmail.com>
> *Sent:* Friday, September 11, 2020 5:46 PM
> *To:* Matthew Loraditch <MLoraditch at heliontechnologies.com>
> *Cc:* cisco-voip at puck.nether.net
> *Subject:* Re: [cisco-voip] SIP Binding: Different Binds for Carrier vs
> Internal
>
>
>
> [EXTERNAL]
>
>
>
> First up, you don't need to bind your interfaces.  You should bind your
> interfaces in two scenarios though:
>
>
>
> 1. You're trying to source your IP from a loopback address
>
> 2. You only have one interface
>
>
>
> Otherwise, let the router do it's routing and it will pick the correct
> interface to "bind" SIP too, by the nature of which interface the packet
> leaves the router from.
>
>
>
> Now, you can bind, if you want to, but it doesn't do anything extra, to
> the best of my knowledge.
>
>
>
> When you say, "[n]ever see the other’s IP," you should know that this
> happens by default.  That's what a B2BUA does.  It terminates a dialog with
> one peer, and then turns around and originates a new dialog with a
> different peer.
>
>
>
> And yes, flow through is default, but that does not affect signaling,
> which it kind of sounds like is the topic at hand.  Otherwise, flow around
> means your carrier knows how to hit your inside IP Phone addresses
> directly, and that's not likely the case.
>
>
>
> So literally, you do not have to do anything extra or special to get what
> you want.  You simply configure the router as a device with two interfaces
> on two different networks, and teach it how to route (e.g., static routing
> or something, I don't know I'm not a CCIE Routing and Switching).
>
>
>
> On Fri, Sep 11, 2020 at 2:25 PM Matthew Loraditch <
> MLoraditch at heliontechnologies.com> wrote:
>
> I need to bind call legs to my carrier to one IP and all legs to CUCM on
> another IP on the same router and neither side ever see the other’s IP nor
> need to route to it
>
>
>
> I’ve done something, at least similar, many years in the past but no
> longer have access to the environment to verify the behavior and am trying
> to refresh myself on the setting.
>
>
>
> In that setup we bound the dial peers to the relevant interfaces and
> enabled allow-connections sip to sip and address-hiding in my voice service
> voip config.
>
>
>
> From what I further understand media flow-through is the default behavior
> so as long as I do the binding, I will get what I want to happen happening.
>
>
>
> Am I generally correct in all of my current thoughts? Anything I’m not
> thinking of?
>
>
>
>
>
>
>
>
>
>
>
>
>
> *Matthew Loraditch***
>
> *Sr. Network Engineer*
>
> p: *443.541.1518* <443.541.1518>
>
> w: *www.heliontechnologies.com* <http://www.heliontechnologies.com/>
>
>  |
>
> e: *MLoraditch at heliontechnologies.com* <MLoraditch at heliontechnologies.com>
>
> [image: Helion Technologies] <http://www.heliontechnologies.com/>
>
> [image: Facebook] <https://facebook.com/heliontech>
>
> [image: Twitter] <https://twitter.com/heliontech>
>
> [image: LinkedIn] <https://www.linkedin.com/company/helion-technologies>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20200911/95968b74/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 431 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20200911/95968b74/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 561 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20200911/95968b74/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image005.png
Type: image/png
Size: 444 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20200911/95968b74/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 6884 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20200911/95968b74/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image258912.png
Type: image/png
Size: 9409 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20200911/95968b74/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image366568.png
Type: image/png
Size: 431 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20200911/95968b74/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image312824.png
Type: image/png
Size: 561 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20200911/95968b74/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image227199.png
Type: image/png
Size: 444 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20200911/95968b74/attachment-0007.png>