Subject: [rtcweb] Fwd: I-D Action: draft-alvestrand-one-rtp-00.txt

From: Harald Alvestrand <[email-masked]>
Date: Thu, 11 Aug 2011 13:32:03 +0200

I have taken some of the information I learned from the discussions in 
Quebec City about the issues of putting video and audio into the same 
RTP session and created a draft from them outlining a solution to the 
problem of signalling this configuration using SDP.

Comments welcome, including the recommended context for processing the 
document; in a few days I'll send the same note to AVTCORE and/or MMUSIC.

                       Harald

-------- Original Message --------
Subject: 	I-D Action: draft-alvestrand-one-rtp-00.txt
Date: 	Thu, 11 Aug 2011 04:28:09 -0700
From: 	[email-masked]
Reply-To: 	[email-masked]
To: 	[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-00.txt
	Pages           : 8
	Date            : 2011-08-11

    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-00.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-00.txt
_______________________________________________
I-D-Announce mailing list
[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: Paul Kyzivat <[email-masked]>
Date: Thu, 11 Aug 2011 14:47:03 -0400

> document; in a few days I'll send the same note to AVTCORE and/or MMUSIC.

Harald,

A few questions/comments:

1) If ICE is being used, how do you expect it to be handled on the 2nd 
m-line? Since one of the goals of multiplexing on a single rtp session 
is to minimize ICE processing, one would hope only to do ICE on the 
first of the grouped m-lines. But if the answerer doesn't support this 
grouping, then the ICE will be needed on the others.

2) The draft only shows this mechanism being used to combine one audio 
and one video. Do you also imagine it being used to represent multiple 
audio and/or multiple video streams that might otherwise be handled 
independently? (I see no reason why it couldn't be used that way.) This 
would allow description of different properties for each one.

3) In the example, for an entity that doesn't understand TOGETHER, you 
still show the a=mid lines. This is appropriate for an answerer that 
*does* understand a=group. However an answerer that doesn't implement 
rfc3388 would presumably omit the a=mid lines from the answer. So the 
offerer had better be prepared for that as well.

	Thanks,
	Paul

---

From: Ross Finlayson <[email-masked]>
Date: Thu, 11 Aug 2011 20:37:08 -0700

Thanks, Harald, for this submission.

A nit (I think).  Unless I'm misunderstanding the purpose of the "a=group:TOGETHER" attribute, the port numbers in the two example 'answers' are wrong.

Example 1:
  Answer, from an entity that understands TOGETHER

         v=0
         o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com
         s=
         c=IN IP4 host.biloxi.example.com
         t=0 0
         a=group:TOGETHER foo bar
         m=audio 49174 RTP/AVP 0
         a=mid:foo
         b=AS:200
         a=rtpmap:0 PCMU/8000
         m=video 49170 RTP/AVP 32
         a=mid:bar
         b=AS:1000
         a=rtpmap:32 MPV/90000
Should be (I think):
         ...
         a=group:TOGETHER foo bar
         m=audio 49170 RTP/AVP 0
         a=mid:foo
         b=AS:200
         a=rtpmap:0 PCMU/8000
         m=video 49170 RTP/AVP 32
         a=mid:bar
         b=AS:1000
         a=rtpmap:32 MPV/90000

Example 2:
   Answer, from an entity that understands grouping, but does not
   understand TOGETHER

         v=0
         o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com
         s=
         c=IN IP4 host.biloxi.example.com
         t=0 0
         m=audio 49174 RTP/AVP 0
         a=mid:foo
         a=rtpmap:0 PCMU/8000
         b=AS:200
         m=video 49170 RTP/AVP 32
         a=mid:bar
         a=rtpmap:32 MPV/90000
         b=AS:1000
Should be (I think):
         ...
         m=audio 49170 RTP/AVP 0
         a=mid:foo
         a=rtpmap:0 PCMU/8000
         b=AS:200
         m=video 51372 RTP/AVP 32
         a=mid:bar
         a=rtpmap:32 MPV/90000
         b=AS:1000

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 12 Aug 2011 08:45:41 +0200

> grouping, then the ICE will be needed on the others.
I tried to be explicit that if negotiation is successful, only the ICE 
parameters from the first section listed in the A=group:TOGETHER would 
be used:

    The following parameters are taken from the first section only:

    o  Port number from the m= line

    o  All media-level attributes defined in RFC 5245 section 15.1 - this
       includes "candidate", "remote-candidates", "ice-mismatch", "ice-
       ufrag", "ice-pwd"

Suggestions for improving this language?

> independently? (I see no reason why it couldn't be used that way.) 
> This would allow description of different properties for each one.
I certainly think that any number of m= sections could be combined this 
way, but in other discussions, I've seen people tend towards thinking of 
sections as "one m= section for all the audio channels, one m= section 
for all the video channels". Can you give an example of the usage you're 
thinking of?

I'm worried that we may get too many special rules about how parameters 
from sections are to be combined - multiple codecs with different PT 
numbers are fine, but other parameters could be confusing, so I'd like 
to see examples.
> offerer had better be prepared for that as well.
Yes, that's a reasonable point. I'll add a third example answer.
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 12 Aug 2011 08:49:08 +0200

On 08/12/11 05:37, Ross Finlayson wrote:
> A nit (I think).  Unless I'm misunderstanding the purpose of the 
> "a=group:TOGETHER" attribute, the port numbers in the two example 
> 'answers' are wrong.
I'm not sure. These examples came straight out of RFC 4317, including 
the port numbers; I noted the port number mismatch, and concluded 
(tentatively) that the port number of an offer means "I'll be using this 
port", while the port number of an answer means "I'll be using this 
port" - which means that they SHOULD be expected to be different.

When using ICE, the port number is moot anyway (the "candidates" 
overrides them), so the only purpose of the port number is that the 
special value zero in an answer means "offer not accepted".
>           o=bob 2808844564 2808844564 IN IP4host.biloxi.example.com  <http://host.biloxi.example.com>
>           s=
>           c=IN IP4host.biloxi.example.com  <http://host.biloxi.example.com>
>           t=0 0
>           a=group:TOGETHER foo bar
>           m=audio 49174 RTP/AVP 0
>           a=mid:foo
>           b=AS:200
>           a=rtpmap:0 PCMU/8000
>           m=video 49170 RTP/AVP 32
>           a=mid:bar
>           b=AS:1000
>           a=rtpmap:32 MPV/90000
> Should be (I think):
>           ...
>           a=group:TOGETHER foo bar
>           m=audio 49170 RTP/AVP 0
>           a=mid:foo
>           b=AS:200
>           a=rtpmap:0 PCMU/8000
>           m=video 49170 RTP/AVP 32
>           a=mid:bar
>           b=AS:1000
>           a=rtpmap:32 MPV/90000
> Example 2:
>           o=bob 2808844564 2808844564 IN IP4host.biloxi.example.com  <http://host.biloxi.example.com>
>           s=
>           c=IN IP4host.biloxi.example.com  <http://host.biloxi.example.com>
>           t=0 0
>           m=audio 49174 RTP/AVP 0
>           a=mid:foo
>           a=rtpmap:0 PCMU/8000
>           b=AS:200
>           m=video 49170 RTP/AVP 32
>           a=mid:bar
>           a=rtpmap:32 MPV/90000
>           b=AS:1000
> Should be (I think):
>           ...
>           m=audio 49170 RTP/AVP 0
>           a=mid:foo
>           a=rtpmap:0 PCMU/8000
>           b=AS:200
>           m=video 51372 RTP/AVP 32
>           a=mid:bar
>           a=rtpmap:32 MPV/90000
>           b=AS:1000
>
> Ross Finlayson
> Live Networks, Inc.
> http://www.live555.com/
>
>

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Fri, 12 Aug 2011 18:39:30 +0530

A few comments:
 
1) Section 4 has this:
If the responder understands the semantics of the TOGETHER extension,
the parameters of the first section MUST be used to establish the RTP
session, and the parameters for the other sections MUST be ignored.
 
I think it needs to be:
If the responder understands the semantics of the TOGETHER extension,
the parameters of the first section MUST be used to establish the RTP
and RCP session, and the parameters for the other sections MUST be 
ignored.
 
2) When the RTCP port is not the next higher (odd) port number following
the RTP port described in the m-line, the "a=rtcp" attribute (defined in
RFC-3605) is used to signal it, as in:
m=audio 49170 RTP/AVP 0
a=rtcp:53020 IN IP4 126.16.64.4
 
With the grouping semantics described in the draft, it seems this RTCP
port should be taken only from the first section. So, this could be
could be added to section 4.
 
3) RTCP could be multiplexed with RTP on a single port and signaled
using the "a=rtcp-mux" attribute (defined in RFC 5761). When it is used
together with the grouping semantics described in the draft, it seems
all RTCP sessions of that group need to be multiplexed on the RTP port
from the first section.
 
Muthu
 
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Harald Alvestrand
Sent: Thursday, August 11, 2011 5:02 PM
To: [email-masked]
Subject: [rtcweb] Fwd: I-D Action: draft-alvestrand-one-rtp-00.txt

Comments welcome, including the recommended context for processing the
document; in a few days I'll send the same note to AVTCORE and/or
MMUSIC.

                      Harald

-------- Original Message -------- 
Subject: 
I-D Action: draft-alvestrand-one-rtp-00.txt
Date: 
Thu, 11 Aug 2011 04:28:09 -0700
From: 
[email-masked]
Reply-To: 
[email-masked]
To: 
[email-masked]
 
A New Internet-Draft is available from the on-line Internet-Drafts
directories.

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 12 Aug 2011 15:18:37 +0200

> and RCP session, and the parameters for the other sections MUST be
Good point. Will fix. Normally, I think RTCWEB apps will use RTCP port 
multiplexing (RFC 5761), so I did not think of it.
In general, I think we should keep extensions as orthogonal as possible, 
so the normative language here should just say "establish RTCP sessions 
normally for the first section, and don't do it for other sections".
>
> 2) When the RTCP port is not the next higher (odd) port number 
> following the RTP port described in the m-line, the "a=rtcp" attribute 
> (defined in RFC-3605) is used to signal it, as in:
>
> m=audio 49170 RTP/AVP 0
>
> using the "a=rtcp-mux" attribute (defined in RFC 5761). When it is 
> used together with the grouping semantics described in the draft, it 
> seems all RTCP sessions of that group need to be multiplexed on the 
> RTP port from the first section.
>
There should be only one RTCP session established for all the TOGETHER 
m= lines, yes.
>
> Muthu
>
> *From:[email-masked] [mailto:[email-masked]] *On 
> Behalf Of *Harald Alvestrand
> *Sent:* Thursday, August 11, 2011 5:02 PM
> *To:* [email-masked]
> *Subject:* [rtcweb] Fwd: I-D Action: draft-alvestrand-one-rtp-00.txt
>
> *Subject: *
> *Date: *
> *From: *
> [email-masked] <mailto:[email-masked]>
>
> *Reply-To: *
>
> 	
>
> [email-masked] <mailto:[email-masked]>
>
> *To: *
>
> 	
>
> [email-masked] <mailto:[email-masked]>
>
> [email-masked]  <mailto:[email-masked]>
> Internet-Draft directories:http://www.ietf.org/shadow.html
> orftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Fri, 12 Aug 2011 19:42:06 +0530

|In general, I think we should keep extensions as orthogonal
|as possible, so the normative language here should just say
|"establish RTCP sessions normally for the first section, and 
|don't do it for other sections".
 
Looks good to me. Should it also say "Within a TOGETHER group it is
RECOMMENDED to multiplex RTCP on the same RTP port from the first
section" or something stronger?
 
Muthu
 
From: Harald Alvestrand [mailto:[email-masked]] 
Sent: Friday, August 12, 2011 6:49 PM
To: Muthu Arul Mozhi Perumal (mperumal)
Cc: [email-masked]
Subject: Re: [rtcweb] Fwd: I-D Action: draft-alvestrand-one-rtp-00.txt

1) Section 4 has this:
 
I think it needs to be:

 

 
Muthu

                      Harald

-------- Original Message -------- 
Subject:

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 12 Aug 2011 10:55:37 -0400

> parameters from the first section listed in the A=group:TOGETHER would

Sure. But if the other side *doesn't* support TOGETHER, then ICE will 
need to be negotiated independently for each m-line. And for that to 
work, the port for the 2nd m-line but be active, other ICE candidates 
identified and included for it, etc.

ISTM the implications of that need further explanation.
(I'm not an expert on ICE. If I were, maybe this would be obvious.)

> for all the video channels". Can you give an example of the usage you're

If there was an intent to have multiple streams with different 
properties, then this would provide a way to describe those, that isn't 
otherwise available. For instance, if you wanted one hi-res video stream 
and one low-res video stream.

I'm also thinking ahead to what might be coming from CLUE 
(telepresence). It isn't far enough along to yet be able to predict how 
it will set up its multi-stream calls, but it will probably want to 
multiplex them over a lesser number of RTP streams. And so I'm shopping 
for potential mechanisms that might be exploited there.

> numbers are fine, but other parameters could be confusing, so I'd like

Maybe its premature. But no matter what, rules will need to be written 
on how attributes are combined. So IMO its worthwhile to at least start 
thinking about how to write those in general, rather than writing a few 
special case hacks. It may turn out that the rules that are to be 
followed for combining one audio and one video will also "just work" for 
combining two audio or two video, etc.

	Thanks,
	Paul

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 12 Aug 2011 16:58:45 +0200

> section" or something stronger?
I think it should be up to the offer generator whether he adds 
"a=rtcp-mux" to the first section or not.
Do we need to state that if the first section has it, all the other 
sections have to have it, or can we live with a mixture?
>
> Muthu
>
> *From:*Harald Alvestrand [mailto:[email-masked]]
> *Sent:* Friday, August 12, 2011 6:49 PM
> *To:* Muthu Arul Mozhi Perumal (mperumal)
> *Cc:* [email-masked]
> *Subject:* Re: [rtcweb] Fwd: I-D Action: draft-alvestrand-one-rtp-00.txt
>
> In general, I think we should keep extensions as orthogonal as 
> possible, so the normative language here should just say "establish 
> RTCP sessions normally for the first section, and don't do it for 
> other sections".
>
> *From:[email-masked] <mailto:[email-masked]> 
> [mailto:[email-masked]] *On Behalf Of *Harald Alvestrand
> *To:* [email-masked] <mailto:[email-masked]>

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 12 Aug 2011 17:20:41 +0200

> (I'm not an expert on ICE. If I were, maybe this would be obvious.)
There are 2 possible things to do for the offerer:
- Start ICE procedure on all ports when sending the offer
- Wait until the answer comes back, and either start ICE procedure on 
one port (if the responder understood TOGETHER), or start the ICE 
procedure on all ports (if the responder did not understand TOGETHER)

The first alternative is a number of milliseconds faster, but others 
should chime in on whether that's significant or not.

> properties, then this would provide a way to describe those, that 
> isn't otherwise available. For instance, if you wanted one hi-res 
> video stream and one low-res video stream.
>
> (telepresence). It isn't far enough along to yet be able to predict 
> how it will set up its multi-stream calls, but it will probably want 
> to multiplex them over a lesser number of RTP streams. And so I'm 
> shopping for potential mechanisms that might be exploited there.
>
> on how attributes are combined. So IMO its worthwhile to at least 
> start thinking about how to write those in general, rather than 
> writing a few special case hacks. It may turn out that the rules that 
> are to be followed for combining one audio and one video will also 
> "just work" for combining two audio or two video, etc.
>
>     Thanks,
>     Paul
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 12 Aug 2011 11:24:06 -0400

> special value zero in an answer means "offer not accepted".

I had wondered about this too, and forgot to comment.
IMO the offer is right - you need two different ports in case TOGETHER 
isn't understood by answerer.

But in the answer, if TOGETHER *is* used, I wonder about the port. 
Putting a unique port there certainly implies to me that it will be 
used. (Though ICE may change things.) But using the *same* port in the 
answer may not be right either. In general, SDP doesn't allow you to use 
the same port in multiple m-lines. IIRC there is an exception to that, 
but I'll have to hunt to find what that is.

Putting zero as the port in the 2nd m-line of the answer might be a 
solution. It would certainly indicate that only the one port will be 
used. The issue is that when its zero, generally the rest of the stuff 
about that stream is ignored. However, no matter what, *some* rules have 
to be changed to make TOGETHER work.

I guess a question is: would it ever make sense for the answerer to 
indicate support for TOGETHER, and yet want to refuse one of the m-lines?

As long as there are never more than two m-lines combined with TOGETHER, 
refusing one of them can be done by *not* indicating support for 
TOGETHER, and then giving port=0 for the m-lines not desired. And that 
works even if only the 2nd m-line is desired.

If there were three or more m-lines combined with TOGETHER, it gets more 
complex. (To be concrete, say there was audio, video, and timed text. in 
the offer.) And suppose the answerer only wants audio and timed text. In 
that case I guess it does need a way to reject the video while still 
using TOGETHER. And port=0 for the video is the obvious way.

That brings up another peculiar case. Suppose the m-lines in question 
were, in order, video, audio, and timed text, and the answerer again 
only wanted to use audio and timed text. In that case, will it still 
want to use the port offered for video??? How would the answer be 
constructed, and where would the answering port be placed?

It occurs to me that there is another "special" port that might be 
co-opted for use here: port 9, the discard port. Perhaps port 9 could be 
used in the answer, when TOGETHER is used in the answer, to indicate 
m-lines that *are* to be combined with one of the other m-lines, while 
port 0 would be used to indicate m-lines that are being rejected 
entirely. Then there should only be one m-line in the group that has a 
port not equal to either 0 or 9, and it would be the one to use. (Or the 
one to negotiate ICE on.)

	Thanks,
	Paul

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 12 Aug 2011 17:24:08 +0200

> "just work" for combining two audio or two video, etc.
That's why I'm urging you to come up with concrete examples; I think 
it's easier to work out the general principles when we have worked 
through more than one example.

At the moment we have the "ICE way" (take the first), the "bandwidth 
way" (add the numbers), and the "codec way" (use them all, but require 
that they don't conflict).

If you have a good example-from-real-life of an SDP offer where you 
would like to use TOGETHER, let's see whether there are more cases.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 12 Aug 2011 11:57:14 -0400

Trimming, and changing subject

> should chime in on whether that's significant or not.

(I don't know much about ICE, so just call me on it if I say something 
stupid)

IIUC, there are some aspects of ICE that MUST be done before sending the 
offer. Specifically that involved gathering the candidate list, which 
may involve assignment of multiple local ports, interactions with a TURN 
server, etc. I don't think everything can be deferred until the answer 
is received.

(I suppose one approach would be for the initial offer to set the port 
to zero in all but the first m-line. Then, once the first answer is 
received, indicating whether TOGETHER is supported, another offer can be 
generated, using appropriate ICE based on whether using TOGETHER or not. 
But that does start to get complex.)

	Thanks,
	Paul

---

From: Randell Jesup <[email-masked]>
Date: Fri, 12 Aug 2011 13:34:50 -0400

> indicate support for TOGETHER, and yet want to refuse one of the m-lines?
Yes.  One m= line is audio, one is video, and I don't support video.  (Or I
do, but can't handle something else about it, or I support it but answered
with an "audio-only" button).

> using TOGETHER. And port=0 for the video is the obvious way.

Agreed.

> one to negotiate ICE on.)

Well, since this is a response and we now know both sides support the new
mechanisms, we could special-case another port.  I can't say I love it, but
if there's no better alternative I'd be ok.  I suspect there's a better
alternative though.

-- 
Randell Jesup
[email-masked]

---

From: Randell Jesup <[email-masked]>
Date: Fri, 12 Aug 2011 13:41:28 -0400

>> should chime in on whether that's significant or not.
1/2 RTT is significant especially on slower/longer-distance connections,
since I think all the other setup stuff we're talking about adds up.
We have to make sure that we don't have the "...lo?" problem when
answering an incoming connection.  (Setup delay of more than a couple
hundred ms causes first syllables to be lost.)  It might even be worse on a
computer if the person has a headset on or answers in speakerphone mode with
a button press - you don't have the natural delay of bringing a receiver to
face.

> server, etc. I don't think everything can be deferred until the answer
Right; one assumes you've done them.

> But that does start to get complex.)
That forces a full extra RTT plus overhead...  Ouch.

-- 
Randell Jesup
[email-masked]

---

From: Justin Uberti <[email-masked]>
Date: Fri, 12 Aug 2011 13:46:03 -0400

On Fri, Aug 12, 2011 at 11:20 AM, Harald Alvestrand <[email-masked]>wrote:

>> Sure. But if the other side *doesn't* support TOGETHER, then ICE will need
>> to be negotiated independently for each m-line. And for that to work, the
>> port for the 2nd m-line but be active, other ICE candidates identified and
>> included for it, etc.
>>
> - Wait until the answer comes back, and either start ICE procedure on one
> port (if the responder understood TOGETHER), or start the ICE procedure on
> all ports (if the responder did not understand TOGETHER)
>
> The first alternative is a number of milliseconds faster, but others should
> chime in on whether that's significant or not.

The former is what is recommended by the rtcp-mux RFC. If we don't do this
(and optimistically only obtain ICE candidates for one transport), we'd have
to do another exchange in the fallback case to provide the additional
candidates.

>> If there was an intent to have multiple streams with different properties,
>> then this would provide a way to describe those, that isn't otherwise
>> available. For instance, if you wanted one hi-res video stream and one
>> low-res video stream.
>>
>> I'm also thinking ahead to what might be coming from CLUE (telepresence).
>> It isn't far enough along to yet be able to predict how it will set up its
>> multi-stream calls, but it will probably want to multiplex them over a
>> lesser number of RTP streams. And so I'm shopping for potential mechanisms
>> that might be exploited there.
>>
>> Maybe its premature. But no matter what, rules will need to be written on
>> how attributes are combined. So IMO its worthwhile to at least start
>> special case hacks. It may turn out that the rules that are to be followed
>> for combining one audio and one video will also "just work" for combining
>> two audio or two video, etc.
>>
>>    Thanks,
>>    Paul
>>
>>>> ______________________________**_________________
>>>> rtcweb mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/**listinfo/rtcweb<https://www.ietf.org/mailman/listinfo/rtcweb>
>>>>
>>>>
>>>
>>>
>>
>>
> ______________________________**_________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/rtcweb<https://www.ietf.org/mailman/listinfo/rtcweb>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 12 Aug 2011 13:56:56 -0400

> a button press - you don't have the natural delay of bringing a receiver to

Note that this matters if the extra signaling happens after the callee 
answers. If it happens *before* the answer, then it just extends the 
"ring time" but doesn't cause clipping.

> That forces a full extra RTT plus overhead... Ouch.

Again, if the extra round trip happens during "alerting" it may not be 
objectionable.

Also, if the first m-line is audio, it can get going sooner, with the 
video to follow with a slight lag.

But I agree this isn't the nicest of solutions. I'm just putting out 
some candidates to consider.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 13 Aug 2011 00:26:42 +0200

Hi Harald,

When putting the draft together, did you consider intermediaires that do not support the mechanism? Even if the endpoints support it, intermediaries would still see and expect separate streams.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 13 Aug 2011 00:29:47 +0200

Hi Harald,

I would like to see some text on, when using the mechanism, how new streams would be added, or existing ones would be removed, later during a session.

Regards,

Christer

---

From: Harald Alvestrand <[email-masked]>
Date: Sat, 13 Aug 2011 22:11:40 +0200

On 08/13/11 00:26, Christer Holmberg wrote:
> Hi Harald,
> When putting the draft together, did you consider intermediaires that 
> do not support the mechanism? Even if the endpoints support it, 
> intermediaries would still see and expect separate streams.
I had not really considered this .... I am not convinced it is a problem.
Brief analysis:

Either they are in the media path or they are not in the media path.

If they are not in the media path, they will not see the difference, and 
will not care.

If they are in the media path.... we have a problem, but that same 
problem applies to any other SDP extension that affects the media, such 
as RTCP multiplexing; if that's successful, that's a hopeful sign that 
they either don't exist or aren't important.

(One special form of "intermediares" are wiretap units - they are in 
fact mentioned in the draft...)

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 14 Aug 2011 21:12:53 +0200

Hi,

>>When putting the draft together, did you consider intermediaires that do not support the mechanism? Even if the >>endpoints support it, intermediaries would still see and expect separate streams.
>
>If they are not in the media path, they will not see the difference, and will not care.
>
>If they are in the media path.... we have a problem, but that same problem applies to any other SDP extension that >affects the media, such as RTCP multiplexing; if that's successful, that's a hopeful sign that they either don't exist or >aren't important.

I guess the question is what the impacts are.

In this case, the SDP offer/answer as such may go fine, but the intermediary might reserve bandwidth only for a single media type (the one which the SDP answer indicates will eventually be used for the multiplex) - even if that media type will consist of multiple multiplexed media types. 

Regards,

Christer

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 15 Aug 2011 09:50:54 +0200

I added this text in a non-normative appendix:

This document does not specify anything about RTCP sessions. Since a 
purpose of the specification is to minimize the number of transport 
connections, it's natural to use the "a=rtcp-mux" attribute defined in 
[RFC5761], but this document does not specify anything about that matter.

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 15 Aug 2011 10:20:24 +0200

On 08/12/11 17:24, Paul Kyzivat wrote:
> Putting a unique port there certainly implies to me that it will be used.
I don't see such an implication. Numbers are cheap, and having an unique 
number avoids having to specify specific rules for this issue.
> (Though ICE may change things.) But using the *same* port in the 
> answer may not be right either. In general, SDP doesn't allow you to 
> use the same port in multiple m-lines. IIRC there is an exception to 
> that, but I'll have to hunt to find what that is.
The grouping RFC explicitly calls out the prohibition. So no luck there.
> about that stream is ignored. However, no matter what, *some* rules 
> have to be changed to make TOGETHER work.
>
> As long as there are never more than two m-lines combined with 
> TOGETHER, refusing one of them can be done by *not* indicating support 
> for TOGETHER, and then giving port=0 for the m-lines not desired. And 
> that works even if only the 2nd m-line is desired.
>
> If there were three or more m-lines combined with TOGETHER, it gets 
> more complex. (To be concrete, say there was audio, video, and timed 
> text. in the offer.) And suppose the answerer only wants audio and 
> timed text. In that case I guess it does need a way to reject the 
> video while still using TOGETHER. And port=0 for the video is the 
> obvious way.
Yep, that makes sense. Another way, which could be equally "obvious", 
would be to accept the section, but just not put any a=rtpmap: lines in 
it - this too "looks a bit odd", so I'm putting the "port zero" option 
in the draft.
> constructed, and where would the answering port be placed?
That is a strong argument in favour of "just don't give any codecs". I'm 
adding that too.
> co-opted for use here: port 9, the discard port. Perhaps port 9 could 
> be used in the answer, when TOGETHER is used in the answer, to 
> indicate m-lines that *are* to be combined with one of the other 
> m-lines, while port 0 would be used to indicate m-lines that are being 
> rejected entirely. Then there should only be one m-line in the group 
> that has a port not equal to either 0 or 9, and it would be the one to 
> use. (Or the one to negotiate ICE on.)
Magic numbers are bad for technological health. I don't think I'd like 
to see that.

---

From: Randell Jesup <[email-masked]>
Date: Mon, 15 Aug 2011 10:52:25 -0400

> That is a strong argument in favour of "just don't give any codecs". I'm

If you're suggesting "m=video 4321 RTP/AVP" as an SDP line, it's illegal to
not have a payload listed, I'm afraid (though many implementations will 
accept
it).  That includes when you reject an m= line with port 0.

>> co-opted for use here: port 9, the discard port.

Agreed, though occasionally it's ok, even if not optimal (port 0 for 
reject for example).

-- 
Randell Jesup
[email-masked]

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 15 Aug 2011 17:14:02 +0200

On 08/15/11 16:52, Randell Jesup wrote:
> not have a payload listed, I'm afraid (though many implementations 
> will accept
Hm. Yes, since a=rtpmap attributes are only required for dynamic 
numbers, leaving all the a=rtpmap: attributes out doesn't help, and the 
grammar of the m= line is given in RFC 4566 as

       m=<media> <port> <proto> <fmt> ...

  which seems like "one or more". So scratch that idea.
> Agreed, though occasionally it's ok, even if not optimal (port 0 for 
Yup, zero and one are kind of OK to have magical.

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Wed, 17 Aug 2011 14:57:24 +0530

|I think it should be up to the offer generator whether
|he adds "a=rtcp-mux" to the first section or not.
 
Since the goal is to minimize the number of transport connections I
think we should put something stronger to encourage the offerer and
answerer to support RTCP multiplexing. At the minimum, a normative
statement recommending the use of RTCP multiplexing with this grouping
semantics would go a long way (symmetric RTP for e.g is a
recommendation, but virtually all implementations support it).
 
|Do we need to state that if the first section has it, all 
|the other sections have to have it, or can we live with a 
|mixture?
 
If the first section has it, it can be applied to all other section
within that group, so it shouldn't matter whether the reset of the
sections have it or not. A mixture doesn't seem would serve any purpose.
 
Muthu
 
From: Harald Alvestrand [mailto:[email-masked]] 
Sent: Friday, August 12, 2011 8:29 PM
To: Muthu Arul Mozhi Perumal (mperumal)
Cc: [email-masked]
Subject: Re: [rtcweb] Fwd: I-D Action: draft-alvestrand-one-rtp-00.txt

  
Muthu

 
1) Section 4 has this:
 
I think it needs to be:

 

 
Muthu

                      Harald

-------- Original Message -------- 
Subject:

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 17 Aug 2011 11:42:21 +0200

> recommendation, but virtually all implementations support it).
I agree that this is critical in the RTCWEB context. It may not be 
critical for all contexts.
I think that should be a matter the (not yet existing) draft referenced 
here should say:

5.  Data framing and securing

    SRTP [RFC3550] is used for transport of all real-time media.

    The detailed considerations for usage of functions from RTP and SRTP,
    as well as for non-media real-time data, are given in <WORKING GROUP
    DRAFT "MEDIA TRANSPORTS">.

(this is from the -overview document)
> sections have it or not. A mixture doesn't seem would serve any purpose.
When TOGETHER is applied, the other sections' values doesn't matter at all.
When TOGETHER does NOT apply (fallback), it may matter.
I don't see any purpose with a mixture either. But we'll see what 
further review brings.
> *Sent:* Friday, August 12, 2011 8:29 PM
> *Cc:* [email-masked] <mailto:[email-masked]>

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 17 Aug 2011 11:42:27 +0200

---

From: Colin Perkins <[email-masked]>
Date: Mon, 22 Aug 2011 17:57:21 +0100

On 17 Aug 2011, at 10:27, Muthu Arul Mozhi Perumal (mperumal) wrote:
>> I think it should be up to the offer generator whether he adds "a=rtcp-mux" to the first section or not.
>>  
> Since the goal is to minimize the number of transport connections I think we should put something stronger to encourage the offerer and answerer to support RTCP multiplexing. At the minimum, a normative statement recommending the use of RTCP multiplexing with this grouping semantics would go a long way (symmetric RTP for e.g is a recommendation, but virtually all implementations support it).

Such recommendations are in draft-perkins-rtcweb-rtp-usage-02. Feedback on that draft is appreciated.

-- 
Colin Perkins
http://csperkins.org/