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

From: "Christian Huitema" <[email-masked]>
Date: Thu, 11 Oct 2001 13:48:36 -0700

>          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

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 12 Oct 2001 08:04:40 +0300

Hi,

>the definition of FID in the draft-ietf-mmusic-fid-05.txt;

First, since we are going to pick one of these streams, I am not sure
they should be grouped using FID, since that would indicate a SINGLE
logical stream. And, as Christian writes futher down, that is not what
we want.

Second, IF we want to group them (there could be a THEORETICAL scenario
where the media agent may want to switch between an IP4- and IP6 network
during the session) we come to another issue, which has been discussed
before: The fid draft says that if the codec is the same then the media
should be sent on BOTH streams (unless some direction attribute forbids
it, of course). This is, however, another example (I have mentioned some
others) where that is not true.

>second, it creates a lot of overhead. (and I guess that a=IN IP6 is a typo for c=IN
>IP6).
> 

H.248 solves this by using the ReserveGroup and ReserveValue
parameters... :)

>doubling the size of the SDP description.

That is true, but it would only be in the first message. If we remove
one of the streams in the respons, by setting the port to zero, I don't
think we have to include all the attributes for that stream, do we?

Regards,

Christer Holmberg
Ericsson Finland

>Even if we accept that the overhead is not too much of the problem, we have to understand the

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 12 Oct 2001 16:21:12 +0300

Hello,

> flow, such as PCM and Tones, as in:

Yes, my origianl idea when we first released FID was that all the m
lines grouped with FID had different codec type. Then, depending on the
codec type, the media would have been sent to different transport
addresses. Exactly as you describe in your example with DTMF tones.

However, we had to define semantics just in case two m lines with the
same codec were grouped. The decision was that media had to be sent to
both at the same time. Therefore, FDI is the right thing to do for
grouping both the IPv4 address and the IPv6 address in the scenario we
are dealing with.

However, as you also point out, we do not provide any means for
signalling "pick only one of the m lines". Actually this was excluded
from the scope of FID from the beginning, since it is a different
problem. We can certainly define an attribute that says "pick only one
of the m lines".

Regards,

Gonzalo

-- 
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                   
USA                              [email-masked]