Send VoiceOps mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://puck.nether.net/mailman/listinfo/voiceops
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of VoiceOps digest..."
Today's Topics:
1. Re: GRE (Ryan Delgrosso)
2. Re: GRE (Mark Lindsey)
----------------------------------------------------------------------
Message: 1
Date: Tue, 13 Aug 2013 13:25:30 -0700
From: Ryan Delgrosso <[email protected]>
To: [email protected]
Subject: Re: [VoiceOps] GRE
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
What you are describing is similar to the Acme TSM product where sip /
rtp are wrapped in a tunnel for nat traversal purposes.
It actually has quite a few strengths but all of them depend on the
tunneling devices ability to detect failure and re-negotiate. If there
are any interfering devices in the middle with ALG's etc it should cut
right through them, and as far as overhead goes, as long as you arent
doing any crypto its actually pretty light.
You will want to be aware of path MTU for signaling traffic since the
extra bits of overhead can pad a large sip packet (think invite with
custom headers and large-ish SDP) over 1500 bytes which will cause
fragmentation issues. Consider going to compact headers to eliminate
this and make some overhead room. RTP wont have this issue of course.
Will you be doing sip over udp or tcp for this?
Who will be managing the GRE tunnel endpoints, and what devices will be
doing the tunneling?
What is your sip redundancy model right now?
On 08/13/2013 07:17 AM, Bob Hancock wrote:
> I have a project in which a user is interesting in interconnecting and
> deploying ATAs for VoIP services but wants to use private IP
> addressing on the devices. My initial though is to NAT these devices
> and allow my SBC to handle NAT traversal for them. This allows the to
> use their dedicated connection to my network or if that link goes down
> fail over to moving to connecting across the internet. They are
> interested in potentially doing a GRE tunnel and keeping the private
> addressing in place as it traverses that tunnel. I am concerned about
> encapsulating the VoIP traffic as well as with the fail over options.
> Does anybody have any experiences with VoIP over GRE tunnels and what
> type of results and challenges you encountered? Thanks.
>
> --BH
>
>
>
>
> _______________________________________________
> VoiceOps mailing list
> [email protected]
> https://puck.nether.net/mailman/listinfo/voiceops
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/voiceops/attachments/20130813/ce1eceef/attachment-0001.html>
------------------------------
Message: 2
Date: Wed, 14 Aug 2013 08:24:53 -0400
From: Mark Lindsey <[email protected]>
To: Bob Hancock <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [VoiceOps] GRE
Message-ID: <-6557404267359656524@unknownmsgid>
Content-Type: text/plain; charset=ISO-8859-1
Allow me to discuss your initial assumption a bit more.
Is the user part of your organization, as used in rfc1918? If you're
not in the same organization as each other, then this sort of sharing
of non-routable IP addresses across organization boundaries is not
really anticipated by rfc1918.
If you can claim that the endpoint devices are part of your
organization, then perhaps an argument can be made. But that implies
there is no collaborative coordination of IP space, but rather direct
control by a controlling authority.
This kind of control does happen when an SP like Comcast/twtelecom
assigns an rfc1918 IP to the EMTA at a customer premise. The customer
has no control at all, and can actually safely reuse any private IP
address he wishes without interfering with the SP.
Collaboration breaks down if you don't have a unified way to guarantee
uniqueness across BOTH organizations. And I've seen this fail. Rfc1918
itself gives examples of the limitations of using private IP address
space.
If you cannot control the use of the rfc1918 space in both
organizations, it's better to use public IPs on the inter-organization
interfaces, with ALG or quality NAT on the endpoints.
>>> [email protected] +12293160013 http://ecg.co/lindsey
On Aug 13, 2013, at 10:19, Bob Hancock <[email protected]> wrote:
> I have a project in which a user is interesting in interconnecting and
> deploying ATAs for VoIP services but wants to use private IP addressing on
> the devices.
------------------------------
Subject: Digest Footer
_______________________________________________
VoiceOps mailing list
[email protected]
https://puck.nether.net/mailman/listinfo/voiceops
------------------------------
End of VoiceOps Digest, Vol 50, Issue 6
***************************************
