Subject: RE: draft-olson-sdp-ipv6-02.txt

From: Kelvin Porter <[email-masked]>
Date: Thu, 11 Oct 2001 17:54:01 -0400

Hi,

Perhaps to avoid the combinatoric affects of presenting two addressing
options, we can propose a new addressing scheme - a scheme which
encapsulates the two (roughly) equivalent addresses.

Something like:

C=IN IP4or6 131.160.1.112[3ffe:1200:3012:c006:290:27ff:fe7d:d024]

This allows SDP to be used without adjustment.

And I think that it better models the underlying problem.

You could even indicate a preference for the addressing scheme to be used
(e.g., the first form is the preferred form).

Regards,

Kelvin R. Porter

PS Maybe this indicates a need for a multi-network addressing scheme (that
could even encode a preference list for alternative networks and address).
The rough equivalent to MIME. - KRP

>-----Original Message-----
>From: Christian Huitema [mailto:[email-masked]]
>Sent: Thursday, October 11, 2001 3:49 PM
>To: Gonzalo Camarillo; Jonathan Rosenberg
>Cc: Pekka Pessi; Sean Olson; [email-masked]
>Subject: RE: draft-olson-sdp-ipv6-02.txt
>
>
>>          a=group:FID 1 2
>>          m=audio 30000 RTP/AVP 0
>>          c=IN IP4 131.160.1.112
>>          a=mid:1
>>          m=audio 20000 RTP/AVP 0
>>          a=IN IP6 3ffe:1200:3012:c006:290:27ff:fe7d:d024
>>          a=mid:2
>
>There are two issues with this proposal: first, it does correspond to
>the definition of FID in the draft-ietf-mmusic-fid-05.txt; second, it
>creates a lot of overhead. (and I guess that a=IN IP6 is a 
>typo for c=IN
>IP6).
>
>FID is defined as multiple or complementary definitions of the same
>flow, such as PCM and Tones, as in:
>
>         v=0
>         o=Laura 289083124 289083124 IN IP4 six.example.com
>         t=0 0
>         c=IN IP4 131.160.1.112
>         a=group:FID 1 2
>         m=audio 30000 RTP/AVP 0
>         a=mid:1
>         m=audio 20000 RTP/AVP 97
>         c=IN IP4 131.160.1.111
>         a=rtpmap:97 telephone-events
>         a=mid:2
>
>This is not what we need. We want to say, "send this flow to 
>either IPv4
>or IPv6." A possibility would be to create a new token in the group
>attribute, e.g. "a=group:ALT 1 2", which would mean "pick one or the
>other", and possibly convey an order of preference. 
>
>But this raises a second issue, overhead. Suppose a realistic example,
>in which we don't just propose PCM, but actually offer the choice
>between multiple codecs. We would get something like:
>
>        a=group:ALT 1 2
>        m=audio 30000 RTP/AVP 0 96 97 98
>        a=rtpmap:96 codec-1-and-parameters
>        a=rtpmap:97 codec-2-and-parameters
>        a=rtpmap:96 codec-3-and-parameters
>        c=IN IP4 131.160.1.112
>        a=mid:1
>        m=audio 20000 RTP/AVP 0 96 97 98
>        a=rtpmap:96 codec-1-and-parameters
>        a=rtpmap:97 codec-2-and-parameters
>        a=rtpmap:96 codec-3-and-parameters
>        c=IN IP6 3ffe:1200:3012:c006:290:27ff:fe7d:d024
>        a=mid:2
>
>I don't know whether this is a real concern, but we are by an large
>doubling the size of the SDP description. Even if we accept that the
>overhead is not too much of the problem, we have to understand the
>relative priorities of FID and ALT. Going back to the FID example, this
>would give us:
>
>         v=0
>         o=Laura 289083124 289083124 IN IP4 six.example.com
>         t=0 0
>         a=group:FID 1 2 3 4
>         a=group:ALT 1 2
>         a=group:ALT 3 4
>         m=audio 30000 RTP/AVP 0
>         c=IN IP6 3ffe:1200:3012:c006:290:27ff:fe7d:d024
>         a=mid:1
>         m=audio 30000 RTP/AVP 0
>         c=IN IP4 131.160.1.112
>         a=mid:2
>         m=audio 20000 RTP/AVP 97
>         c=IN IP6 3ffe:1200:3012:c006:6789:ABCD:EF01:2345
>         a=rtpmap:97 telephone-events
>         a=mid:3
>         m=audio 20000 RTP/AVP 97
>         c=IN IP4 131.160.1.111
>         a=rtpmap:97 telephone-events
>         a=mid:4
>
>Now, that may be exactly what we want -- I can definitely generate and
>parse that -- but it is not exactly intuitive...
>
>-- Christian Huitema
>