Re: [MMUSIC] IPv6 transition and ICE

Yes, the only use-case for ANAT is a very controlled environment. No wonder
why US DoD chose to use it..

Muthu

On Wed, Apr 21, 2010 at 10:45 AM, Dan Wing <dwing@cisco.com> wrote:

> > -----Original Message-----
> > From: Muthu Arul [mailto:muthu.arul@gmail.com]
> > Sent: Tuesday, April 20, 2010 7:53 PM
> > To: Dan Wing
> > Cc: Simon Perreault; mmusic@ietf.org
> > Subject: Re: [MMUSIC] IPv6 transition and ICE
> >
> > This is why we have RFC 4092. An ANAT offerer would typically
> > use the sdp-anat option tag in a Require header, giving no
> > choice to the answerer to misinterpret the offer. Of course,
> > it breaks backward compatibility.
>
> And would fail with SIP forking if any of the forked endpoints
> doesn't support the Option Tag.
>
> -d
>
>
> > Muthu
> >
> >
> > On Wed, Apr 21, 2010 at 3:39 AM, Dan Wing <dwing@cisco.com> wrote:
> >
> >
> >       > On 04/20/2010 05:40 PM, Dan Wing wrote:
> >       > > When we do talk about those Other Reasons (which I agree we
> >       > > should), can we
> >       > > put draft-ietf-mmusic-sdp-capability-negotiation on the
> >       > > table for a way to do
> >       > > IPv6?  It doesn't do connectivity checks, either.
> >       >
> >       > And at that time I would also like to be reminded why
> > ANAT doesn't fit
> >       > the bill.
> >
> >
> >       Sure.
> >
> >       But here is a justification in email:
> >
> >
> >       ANAT (RFC4091) is not backwards-compatible with endpoints that
> >       don't know ANAT.  Which is why ICE,
> >       draft-ietf-mmusic-sdp-media-capabilities,
> >       draft-boucadair-mmusic-altc, and
> > draft-hutton-mmusic-icemicrolite
> >       are all using "a=" rather than putting things optional
> > transports
> >       on "m=" lines.
> >
> >
> >       An example of ANAT's problem, using the example from
> > RFC4091 as an Offer:
> >
> >            v=0
> >            o=bob 280744730 28977631 IN IP4 host.example.com
> >            s=
> >            t=0 0
> >            a=group:ANAT 1 2
> >            m=audio 25000 RTP/AVP 0
> >            c=IN IP6 2001:DB8::1
> >            a= <ICE-encoded additional IPv6 addresses (and ports)>
> >            a=mid:1
> >            m=audio 22334 RTP/AVP 0
> >            c=IN IP4 192.0.2.1
> >            a= <ICE-encoded additional IPv4 addresses (and ports)>
> >            a=mid:2
> >
> >       Per SDP processing rules, a device that doesn't understand ANAT
> >       would ignore the "a=" lines it doesn't understand and would
> >       process the following, which means there are two audio streams
> >       (one on IPv6 the other on IPv4) when we really wanted to signal
> >       "choose one":
> >
> >            v=0
> >            o=bob 280744730 28977631 IN IP4 host.example.com
> >            s=
> >            t=0 0
> >            m=audio 25000 RTP/AVP 0
> >            c=IN IP6 2001:DB8::1
> >            m=audio 22334 RTP/AVP 0
> >            c=IN IP4 192.0.2.1
> >
> >
> >       Also, if the UDP ports are the same (as would commonly occur
> >       with a dual-stack host, and as would occur with stateless
> >       NAT64), the meaning of the same UDP ports is undefined
> >       which is why Section 7.5.3 of RFC3388 prohibits that.
> >
> >       -d
> >
> >
> >       _______________________________________________
> >       mmusic mailing list
> >       mmusic@ietf.org
> >       https://www.ietf.org/mailman/listinfo/mmusic
> >
> >
> >
> >
>
>