Subject: Re: [MMUSIC] Request for review: I-D Action: draft-alvestrand-one-rtp-01.txt

From: Christer Holmberg <[email-masked]>
Date: Wed, 17 Aug 2011 20:07:44 +0200

Hi Harald,

First, I think it is good to indicate that RTCWEB as a WG has made no decision regarding this draft.

I have some issues with the draft. Some I have already mentioned in RTCWEB, but I will repeat them here for the MMUSIC community.

Editorial
=====

Q: When referring to a m- line, rather than talking about "section", I would suggest to use "media description".

SDP offer/answer
===========

Rejecting a stream
----------------------

The text says:

   "The answerer cannot refuse the first m= section and establish the
   call.  [[NOTE IN DRAFT: This could be relaxed by allowing it when ICE
   is in use, or saying that the first non-zero port number is used.
   Both lead to nonobvious edge cases.  Is the extra complexity worth
   it?]]"

Q: It must be possible for the answerer to reject a specific stream - including the one described in the first media description.

Adding/remvoing a stream
------------------------------

Q: I would like to see some text on how adding/removing streams in subsequent SDP offer/answers. For example, what if you want to remove the stream associated with the first media descriptor, currently used for the multiplex?

Intermediaries

=========

Q: Intermediaries that do not understand the extension will assume that media will be sent according to the media descriptions in the SDP offer and answer. For example,

they might reserve bandwidth (and/or allow codecs) specified for the media description now used for all streams part of the multiplex.

Regards,

Christer

________________________________
From: [email-masked] [[email-masked]] On Behalf Of Harald Alvestrand [[email-masked]]
Sent: Wednesday, August 17, 2011 12:49 PM
To: MMUSIC WG
Subject: [MMUSIC] Request for review: I-D Action: draft-alvestrand-one-rtp-01.txt

I have attempted to synthesize a possible solution to the "multiple media types on one RTP session" problem that was discussed in Quebec City. I feel that it is urgent for RTCWEB to get this issue to a point where we have consensus on where we're going in the short term, so apologies in advance if I seem to be rushing things.

Feedback (including on how to process this) is VERY welcome!

                    Harald Alvestrand

-------- Original Message --------
Subject:        I-D Action: draft-alvestrand-one-rtp-01.txt
Date:   Wed, 17 Aug 2011 01:48:18 -0700
From:   [email-masked]<mailto:[email-masked]>
Reply-To:       [email-masked]<mailto:[email-masked]>
To:     [email-masked]<mailto:[email-masked]>

A New Internet-Draft is available from the on-line Internet-Drafts directories.

        Title           : SDP Grouping for Single RTP Sessions
        Author(s)       : Harald Tveit Alvestrand
        Filename        : draft-alvestrand-one-rtp-01.txt
        Pages           : 12
        Date            : 2011-08-17

   This document describes an extension to the Session Description
   Protocol (SDP) to describe RTP sessions where media of multiple top
   level types, for example audio and video, are carried in the same RTP
   session.

   This document is presented to the RTCWEB, AVTCORE and MMUSIC WGs for
   consideration.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-alvestrand-one-rtp-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-alvestrand-one-rtp-01.txt
_______________________________________________
I-D-Announce mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 18 Aug 2011 08:00:03 +0200

> I have some issues with the draft. Some I have already mentioned in RTCWEB, but I will repeat them here for the MMUSIC community.
Thanks for repeating, Christer!
As before, I'm happy to hear if you have any suggestions on how to solve 
these issues.
> Q: When referring to a m- line, rather than talking about "section", I would suggest to use "media description".
Will do. Thanks.
> SDP offer/answer
That's a requirement - can you give a little more background on why you 
think it's a requirement?
And just to verify - for the case when TOGETHER is successfully 
negotiated - when you say "stream", you mean "all media that uses the 
payload types listed in that specific media description", right?
> Adding/remvoing a stream
My problem here is that I don't understand what you mean when you say 
"add/remove stream". We might have different interpretations of the word 
"stream".

In the case where TOGETHER is successfully negotiated, how does this 
relate to manipulating media descriptions?
Can you give a description/example of the scenario you're trying to 
enable, down to the details of payload types and SSRC numbers?
Or a reference to a document describing adding/removing streams when 
TOGETHER is not used?

Happy to talk through this offline if you want.
> they might reserve bandwidth (and/or allow codecs) specified for the media description now used for all streams part of the multiplex.
I added a description part in the draft of this issue, as far as I 
understand it:

B.4.  SDP-inspecting intermediaries

    There may exist intermediaries that inspect, but do not modify, the
    SDP flow, and take some action based on what they parse there.

    Such intermediaries are architecturally unsound in general (if they
    really are needed, they should be explicit participants and be able
    to refuse to carry the extension they don't understand; if not, their
    working is of no concern to the callers), but they still exist.

    In the RTCWEB use case, they may have more problems existing, since
    the negotiation will normally be carried over encrypted HTTPS
    connections.  In other cases, where negotiation is done in the clear,
    they may be more common.

For figuring out where we are: Are you talking about intermediaries that 
snoop the SDP flow without being in the flow, or are you talking about 
intermediaries that are part of the SDP flow?
If you talk about intermediaries that snoop the flow, where would you 
think those would be placed for the RTCWEB use case, given that 
signalling traffic is likely to be carried over encrypted connections?

                        Harald

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 18 Aug 2011 09:03:51 +0200

Hi Harald, 

>>I have some issues with the draft. Some I have already 
>>mentioned in RTCWEB, but I will repeat them here for the 
>>MMUSIC community.
>As before, I'm happy to hear if you have any suggestions on 
>how to solve these issues.

I have been thinking about a different solution. But, there are also some issues with such approach.

>>SDP offer/answer
>>================
>>
>>Rejecting a stream
>>----------------------
>>
>>The text says:
>>
>>     "The answerer cannot refuse the first m= section and 
>>     establish the call.  [[NOTE IN DRAFT: This could be relaxed by 
>>     allowing it when ICE is in use, or saying that the first non-zero port 
>>     number is used. Both lead to nonobvious edge cases.  Is the extra 
>>     complexity worth it?]]"
>>
>>
>>
>>Q: It must be possible for the answerer to reject a 
>>specific stream - including the one described in the first 
>>media description.
>That's a requirement - can you give a little more background 
>on why you think it's a requirement?

It wasn't a suggested requirement, but rather a comment on your text.

>And just to verify - for the case when TOGETHER is 
>successfully negotiated - when you say "stream", you mean 
>"all media that uses the payload types listed in that 
>specific media description", right?

When I talk about "stream", I refer to an individual media type, e.g. audio or video. Whether they are sent as individual media streams, or as part of a multiplex, is not relevant.

But, maybe I should talk about "media type" instead?

But, to clarify my issue:

If the first media descriptor (m- line) describes audio, and I don't want that audio (again, no matter whether sent as an individual stream, or as part of a multiplex) I should have the possibility to reject that audio. 

In my opinoin entities need to be able to explicitly negotiate what media will be sent - even in a multiplex.

>>Q: I would like to see some text on how adding/removing 
>>streams in subsequent SDP offer/answers. For example, what if 
>>you want to remove the stream associated with the first media 
>>descriptor, currently used for the multiplex?
>>My problem here is that I don't understand what you mean when 
>>you say "add/remove stream". We might have different 
>>interpretations of the word "stream".
> 
>In the case where TOGETHER is successfully negotiated, how 
>does this relate to manipulating media descriptions?
>Can you give a description/example of the scenario you're 
>trying to enable, down to the details of payload types and 
>SSRC numbers?
>Or a reference to a document describing adding/removing 
>streams when TOGETHER is not used?
> 

When the session is established, I SOMEHOW negotiate a multiplex stream that contains audio from my microphone and a video from my front camera.

Later, I want to negotiate the removal of the video. Using "normal" SDP, I would send an offer where I put the port number of the media descriptor associated with the video stream to zero.

You seem to suggest, that once the multiplex has been negotiated, entities can send whatever within it, and there is no need to negotiate when different types of media are addedd/removed. Or?

>>Intermediaries
>>==============
>>
>>
>>
>>Q: Intermediaries that do not understand the extension will assume 
>>that media will be sent according to the media descriptions 
>>in the SDP offer and answer. For example,
>>
>>they might reserve bandwidth (and/or allow codecs) 
>>specified for the media description now used for all streams 
>>part of the multiplex.
>I added a description part in the draft of this issue, as far 
>as I understand it:
> 
>     There may exist intermediaries that inspect, but do not 
>     modify, the SDP flow, and take some action based on what 
>     they parse there.
> 
>     Such intermediaries are architecturally unsound in 
>     general (if they really are needed, they should be explicit 
>     participants and be able to refuse to carry the extension they 
>     don't understand; if not, their working is of no concern to the 
>     callers), but they still exist.

It would be so simple if we in IETF could dictate exactly how the intermediaries behave :)

>     In the RTCWEB use case, they may have more problems 
>     existing, since the negotiation will normally be carried over 
>     encrypted HTTPS connections. In other cases, where negotiation is 
>     done in the clear, they may be more common.

Sure. But, security is a separate issue.

>For figuring out where we are: Are you talking about 
>intermediaries that snoop the SDP flow without being in the 
>flow, or are you talking about intermediaries that are part 
>of the SDP flow?

I am talking about intermediaries that will anchor the media flow, and will reserve resources etc based on the SDP.

>If you talk about intermediaries that snoop the flow, where 
>would you think those would be placed for the RTCWEB use 
>case, given that signalling traffic is likely to be carried 
>over encrypted connections?

I don't know yet. Maybe there will be no intermediary between the browser and the webserver/legacy GW, but there could be between webservers. And, even if whatever happens there is outside the scope of RTCWEB, we need to keep in mind that the SIP/SDP signalling extensions etc we define might be used there.

However, keep in mind that CLUE most likely will also be interested in a solution to negotiate a multiplex. And, CLUE entities will be located in "legacy" networks where these kind of entities do exist.

Many also want to be able to participate in video conferences using a browser, and I think it would be good if there was a common system for negotiationg the usage of multiplex.

Regards,

Christer

---

From: Randell Jesup <[email-masked]>
Date: Thu, 18 Aug 2011 09:48:55 -0400

> In my opinoin entities need to be able to explicitly negotiate what media will be sent - even in a multiplex.

Agreed - there are all sorts of reservations (and UI implications) attached to knowing
if video will be part of the session.  The UI typically would be different for an
audio-only connection.  And for VRS and other hearing-impaired calls, they may not
want to use audio (and there are other instances where audio would not be the default,
and would only be added later if wanted).

Now, for other reasons we may not want to reject the m= line with port=0, but instead
include an attribute marking it as not to be used (a=rejected).   Or can we use
inactive here?  That might confuse things if a=inactive caused a midbox/TURN/etc
to not expect any traffic.

If we allow it to be rejected it can be re-added later by a new offer-answer pair,
as normal.  This is also how adding "sessions" (or changing codecs, codec params,
etc beyond the agreed to set) should happen later.

> You seem to suggest, that once the multiplex has been negotiated, entities can send whatever within it, and there is no need to negotiate when different types of media are addedd/removed. Or?

Well, you don't *have* to send anything - but without renegotiation of some sort
it's hard to stop the other person from burning bandwidth sending to you.  And it's
bad to leave them thinking you're seeing something you're not (usually).

Starting/stopping your camera (Mute) doesn't need negotiation; and adding another
camera stream (if it has compatible codec/etc specs) doesn't require negotiation (and
conversely, having the other end (or conference) add another stream doesn't normally
need negotiation given this approach.  (Note that I have issues with wanting to be
to say to an incoming connection "enough!" and stop it from sending me more streams
and wasting bandwidth on what I won't see (and hurting what I will).)

-- 
Randell Jesup
[email-masked]

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 18 Aug 2011 18:37:47 +0200

Hi Randell,

>and would only be added later if wanted).

Correct. 

>to not expect any traffic.

"Inactive" will still maintain the RTCP traffic.

But, sure, there may be cases where you want to use something else than port=0. But, I think those cases should be the same no matter if you use multiplex or not.

>etc beyond the agreed to set) should happen later.

Correct. But, again that is normal offer/answer behavior.

>and wasting bandwidth on what I won't see (and hurting what I will).)

Sure, there may be moments where you don't send anything (in case of "mute" etc).

But, my point was that when you do something, it should be something that you have explicitly negotiated to send.

Regards,

Christer

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 24 Aug 2011 16:50:37 +0200

> In my opinoin entities need to be able to explicitly negotiate what media will be sent - even in a multiplex.
I think that in the larger context, they should be able to negotiate 
what streams are sent, even when those streams have the same data type 
and travel on the same RTP session - I should be able to shut off a 
stream I do not want. But SDP doesn't offer that functionality.

I'm trying to work out where to do the tradeoff here - do we continue to 
preserve the functionality that SDP currently does partway, or do we 
give up at the SDP layer and claim that it has to be done elsewhere?
> You seem to suggest, that once the multiplex has been negotiated, entities can send whatever within it, and there is no need to negotiate when different types of media are addedd/removed. Or?
That's exactly right, as long as the payload types are within the 
negotiated payload types for the combined stream.
> It would be so simple if we in IETF could dictate exactly how the intermediaries behave :)
Yes, wouldn't it? :-)
in this case, I think what we can do is to flag that "these 
intermediaries will get into trouble, but we think that's an acceptable 
cost of deploying this technology". That's what I tried to say above, 
but I may have been too mild.
> Sure. But, security is a separate issue.
Security is never a separate issue :-)
> I am talking about intermediaries that will anchor the media flow, and will reserve resources etc based on the SDP.
What does the term "anchor the media flow" mean?
And you did not answer my question on whether these intermediaries are 
part of the SDP flow or not.
> However, keep in mind that CLUE most likely will also be interested in a solution to negotiate a multiplex. And, CLUE entities will be located in "legacy" networks where these kind of entities do e…
When you say "network", do you mean "physical network", or "network of 
SIP entities"?
Browsers will definitely be on the physical network too, but will 
probably not be directly on the web of SIP-interconnected entities.
> Many also want to be able to participate in video conferences using a browser, and I think it would be good if there was a common system for negotiationg the usage of multiplex.
That's why the spec has no references to RTCWEB apart from background....