Re: [dispatch] Migrating SIP to IPv6 Media Without Connectivity Checks

["Kevin P. Fleming" <[e-mail]>]

On 08/27/2010 04:09 PM, Dan Wing wrote:
> At IETF78 we had a Bar BoF discussing why folks don't like ICE for doing
> connectivity checks for dual-stack hosts.  The outcome of this Bar BoF was
> an idea that Andrew and I wrote up,
> 
> Abstract:
>    During the migration from IPv4 to IPv6, it is anticipated that an
>    IPv6 path might be broken for a variety of reasons, causing endpoints
>    to not receive RTP data.  Connectivity checks would detect and avoid
>    the user noticing such a problem, but there is industry reluctance to
>    implement connectivity checks.
> 
>    This document describes a mechanism allowing dual-stack SIP endpoints
>    to attempt communications over IPv6 and fall back to IPv4 if the IPv6
>    path is not working.  The mechanism does not require connectivity
>    checks.
> 
> http://tools.ietf.org/html/draft-wing-dispatch-v6-migration
> 
> I didn't know where to best send this (MMUSIC did ICE, BEHAVE did ICE's
> connectivity checking protocols), so I'm trying DISPATCH because this is
> mostly about how dual-stack SIP endpoints can avoid IPv6 network breakage.

For SIP servers that are controlling media gateway devices, this could
be rather hard to implement. When media gateway devices are upgraded to
support IPv6, they'll be dual-stack like the controlling entity, which
is adequate to be able to send and receive media streams over IPv6.

However, in my experience dealing with media gateways, they generally do
*not* have the ability to direct a media stream to two destinations
simultaneously unless a conference bridge of some sort is involved...
and that will result in the two streams being independent (thus having
different sequence numbers and timestamps).

It's already going to be hard enough to get STUN support implemented in
gateways so that SIP servers can use them to do ICE connectivity checks;
this seems like it would be even more work for gateway implementors to
build, not less.

I can sympathize with the desire to have a simpler mechanism for doing
*only* v4/v6 path selection, but since either method will require
implementors of media endpoints to develop the required support, I'd
rather push them towards implementing STUN. The SHA-1 overhead for a few
packets at the beginning of a session seems (to me, anyway) to be far
less CPU burden than the low bitrate codec (or modem) that the gateway
will eventually be operating on that channel anyway.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: [e-mail]
Check us out at www.digium.com & www.asterisk.org