Subject: Re: [MMUSIC] [Fwd: I-D Action:draft-garcia-mmusic-sdp-cs-00.txt]

From: "Even, Roni" <[email-masked]>
Date: Wed, 9 Apr 2008 10:11:24 +0300

Miguel,
I looked at the draft and also read the thread on alternative in capability negotiations.
I understand this application and we were looking at other cases where you need alternative media configurations like I can do one video steam at H.264 or two video streams at H.263.
I think that the approach should be based on grouping and not by adding a new capability and defining new alternative mode instead of preference order in the capability negotiation draft. There are two reasons

1. The preference in the capability negotiation is in line with the m line semantics were codecs are listed by priority order.

2. The CS and IP are two separate m lines that have some relationship. Currently there is defined semantics to associate by default between two m-lines carrying the same media type accept by using grouping. I think that such grouping enabling the definition of preference or alternatives between m-lines is the right way to go

Regards

Roni Even     

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Miguel Garcia
> Sent: Monday, February 18, 2008 9:34 AM
> To: mmusic
> Subject: [MMUSIC] [Fwd: I-D Action:draft-garcia-mmusic-sdp-cs-00.txt]
> 
> We have just published an Internet-Draft that indicates how to describe
> circuit-switched media streams in SDP. Comments are welcome.
> 
> /Miguel
> --
> Miguel A. Garcia           tel:+358-50-4804586
> Nokia Siemens Networks     Espoo, Finland

_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Miguel Garcia <[email-masked]>
Date: Wed, 09 Apr 2008 12:27:54 +0300

Roni:

Thanks for your comment, but I don't agree with you. Whenever you have 
an m= line in SDP it indicates that you are willing to establish a media 
stream according to the desired parameters. If you have two "m=" lines 
it indicates you want to establish two simultaneous media streams. This 
is the case when you setup a audio/video session.

However, here we don't want to establish two simultaneous m=audio lines 
(one over RTP the other over CS). We want to indicate an alternative, or

The Grouping framework is a way to say: I have these two "m=" lines that 
  are part of the same group. RFC 3388 defines two groups, one is used 
for lip synchronization, the other to keep the two streams as part of 
the same flow. None of them will really work for our purposes. We would 
need to create a new semantics for choosing alternative stuff. This is 
what the Alternative network Address Types does.

But, there is a higher problem here: the backward compatibility issue. 
If one of the endpoints do not support the extensions, then we end up 
establishing two simultaneous audio streams, one over RTP the other over 
CS. We have a strong requirement on backwards compatibility.

I think that the MMUSIC solution for offering alternative configurations 
is the SDP capability negotiation framework. Please correct me if I am 
wrong, but I think this is EXACTLY the problem that SDP capability 
negotiation solves. And it solves it very nicely, particularly, 
addressing the backward compatibility issues. To be precise: if an 
endpoint creates an offer with a single m=audio line (for RTP), and an 
alternative for CS audio, if the remote endpoint does not understand the 
capability negotiation, then a single RTP audio stream is established. 
This is our desired behavior.

So, I think we should continue using the SDP capability framework for 
this purpose.

/Miguel

---

From: "Even, Roni" <[email-masked]>
Date: Wed, 9 Apr 2008 12:38:29 +0300

Miguel,
I agree with your analysis but I was pointing out that the issue of alternative offers which are not by order of preferences has other use cases, so I suggested looking at all the requirements.
So if we have all the requirements we may need to specify the alternative relations at the media level and at the session level

BTW: this functionality is available for H.323. During the specification of the capability negotiation work this was discussed and people at the time thought that there is no need to go to the simultaneous / alternate capabilities of H.323.

Roni 

> From: Miguel Garcia [mailto:[email-masked]]
> Sent: Wednesday, April 09, 2008 12:28 PM
> To: Even, Roni
> Cc: mmusic
> Subject: Re: [MMUSIC] [Fwd: I-D Action:draft-garcia-mmusic-sdp-cs-00.txt]
> 
> Roni:
> 
> > I understand this application and we were looking at other cases where
> you need alternative media configurations like I can do one video steam at
> H.264 or two video streams at H.263.
> > I think that the approach should be based on grouping and not by adding
> a new capability and defining new alternative mode instead of preference
> order in the capability negotiation draft. There are two reasons
> >
> > 1. The preference in the capability negotiation is in line with the m
> line semantics were codecs are listed by priority order.
> >
> > 2. The CS and IP are two separate m lines that have some relationship.
> Currently there is defined semantics to associate by default between two
> m-lines carrying the same media type accept by using grouping. I think
> that such grouping enabling the definition of preference or alternatives
> between m-lines is the right way to go
> >
> > Regards
> >
> > Roni Even
> >

---

From: Bob Gilman <[email-masked]>
Date: Wed, 09 Apr 2008 17:51:13 -0600

Miguel-
I agree that the problem you posed can be handled via the current media
capabilities negotiation scheme, and that seems most convenient under
the circumstances, but Roni's point is well taken: the problem could
also be solved as an exclusive choice between two media streams, one
over IP and the other circuit-switched.  The latter approach could be
generalized to include cases like the audio with one or two video
streams example Roni put forward in his reply.

While working on the media capabilities negotiation draft, I gave some
thought to how the framework might be extended to include acceptable
combinations of media streams.  Clearly, the combinations should be
expressed at the session level - it's similar to grouping, but it must
refer to configurations within media streams, not just stream IDs.
One way to do that is to define different mids via acap attributes for
different configurations, then, in spite of section 4 in RFC 3388,
define a new group attribute sematic - let's call it "CAP" for now.
Then we might write something like the following (stolen from RFC 3388
and modified to our use) to indicate support for
	a) one audio stream and one H.264 video stream
or
	b) one audio stream and two H.263 video streams.

        v=0
        o=Laura 289083124 289083124 IN IP4 one.example.com
        t=0 0
        c=IN IP4 224.2.17.12/127
        a=creq:med-v0
        a=group:CAP 1 2 3
        a=group:LS 1 2

        m=audio 30000 RTP/AVP 0
        rtpmap:0 PCMU/8000
        a=mid:1

        m=video 30002 RTP/AVP 34
        a=rtpmap:34 H263/90000
        a=mid:2
        a=mcap:10 H264/90000
        a=acap:1 mid:4
        a=acap:2 group:LS 1 4
        a=acap:3 group:CAP 1 4
        a=pcfg:15 m=10 a=-ms:1,2,3 pt=10:100

        m=video 30004 RTP/AVP 101
        a=rtpmap:101 H263/90000
        a=mid:3

This doesn't treat the precedence problem in general, although it's
implied because pcfg:1 prefers H.264, and that specifies
        a=group:CAP 1 4
and eliminates
        a=group:CAP 1 2 3.
I don't think this would work very well in general when there are more
complex combinations to consider - a simple ordered list of allowed
configurations is better.

Another possibility is to define a new capability attribute, call it the
cfgcap, to specify supported configurations as prioritized lists of
potential configurations - something like

        a=cfgcap:1 15 25
        a=cfgcap:2 15|16 35 45
where "|" denotes exclusive-or (see next example.)  This has the great
disadvantage that it can't refer to the base configurations easily - but
we can modify the original SDP to make the base configuration redundant:

        v=0
        o=Laura 289083124 289083124 IN IP4 one.example.com
        t=0 0
        c=IN IP4 224.2.17.12/127
        a=creq:med-v0
        a=cfgcap:1 15|16 25
        a=cfgcap:2 15 35 45
        a=group:LS 1 2

        m=audio 30000 RTP/AVP 0
        a=rtpmap:0 PCMU/8000
        a=mid:1
        a=mcap:10 PCMU/8000
        a=pcfg:15 m=10 pt=10:0
        a=mcap:11 G729/8000
        a=pcfg:16 m=11 pt=11:8

        m=video 30002 RTP/AVP 34
        a=rtpmap:34 H263/90000
        a=mid:2
        a=mcap:20 H264/90000
        a=pcfg:25 m=20 pt=20:100
        a=mcap:30 H263/90000
        a=pcfg:35 m=30 pt=30:34

        m=video 30004 RTP/AVP 101
        a=rtpmap:101 H263/90000
        a=mid:3
        a=mcap:40 H263/90000
        a=pcfg:45 m=40 pt=40:101

The above SDP favors the PCMU (or G729)/H264 combination, but will
default to the PCMU/H263/H263 combination if the answerer can't do
H.264, or doesn't understand the media capability negotiations.
The above SDP counts on the replacement/deletion rule for rtpmap/mcap
as defined in <draft-ietf-mmusic-sdp-media-capabilities-03.txt>.

Eventually, I hope we reach the point where the base configuration
can be empty, and all configs are expressed as capabilities.  For
example, the above SDP might be written as:

        v=0
        o=Laura 289083124 289083124 IN IP4 one.example.com
        t=0 0
        c=IN IP4 224.2.17.12/127
        a=creq:med-v1
        a=cfgcap:1 15|16 25
        a=cfgcap:2 15 35 45
        a=group:LS 1 2

        m=audio 30000 RTP/AVP -
        a=mid:1
        a=mcap:10 PCMU/8000
        a=pcfg:15 m=10 pt=10:0
        a=mcap:11 G729/8000
        a=pcfg:16 m=11 pt=11:8

        m=video 30002 RTP/AVP -
        a=mid:2
        a=mcap:20 H264/90000
        a=pcfg:25 m=20 pt=20:100
        a=mcap:30 H263/90000
        a=pcfg:35 m=30 pt=30:34

        m=video 30004 RTP/AVP -
        a=mid:3
        a=mcap:40 H263/90000
        a=pcfg:45 m=40 pt=40:101

This is clearly not backward compatible with endpoints that don't
support capability negotiation, but it does eliminate the problems
of which base-level attributes (if any) to delete or replace or keep:
they should all be kept for whatever configuration is selected.

Your example

    v=0
    o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5
    s=
    t=0 0
    m=audio 49170 RTP/AVP 0 8 3
    c=IN IP4 10.47.16.5
    a=mcap:1 audio GSM AMR
    a=tcap:1 CS
    a=ccap:1 CS - -
    a=pcfg:1 m=1|2 t=1 c=1

could be rewritten using "capability grouping" where the sematics
of "CAP" mean "pick one of the groups":

    v=0
    o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5
    s=
    t=0 0
    a=group:CAP 1
    a=group:CAP 2
    a=group:CAP 3
    m=audio 49170 RTP/AVP 0 8 3
    a=mid:1
    c=IN IP4 10.47.16.5
    m=audio 1 CS GSM
    a=mid:2
    c=CS - -
    m=audio 2 CS AMR
    a=mid:3
    c=CS - -

This does seem worse than the cap negotiation form, since it
depends on recognition of the "CAP" group semantics to do the
right thing (and to avoid the horrible possibility of opening
three audio streams.)  Precedence is still a problem unless we
make the first argument after "CAP" be the precedence, not a
mid, or we somehow append a precedence to the "CAP".

Does this make sense?  Any alternative suggestions?
Is this stuff worth pursuing?  How important is the ability to
specify supportable combinations of media streams?
-Bob
-------------------------------------------------------------
Bob Gilman        [email-masked]      +1 303 898 9780