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

Harald Alvestrand <> Mon, 15 August 2011 08:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 17AF721F8A35 for <>; Mon, 15 Aug 2011 01:19:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.572
X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fbYix52zYg47 for <>; Mon, 15 Aug 2011 01:19:42 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 039F421F86DF for <>; Mon, 15 Aug 2011 01:19:42 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2186E39E112; Mon, 15 Aug 2011 10:19:14 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mdNw7xtF7E+2; Mon, 15 Aug 2011 10:19:13 +0200 (CEST)
Received: from ( []) by (Postfix) with ESMTPS id 0111939E074; Mon, 15 Aug 2011 10:19:12 +0200 (CEST)
Message-ID: <>
Date: Mon, 15 Aug 2011 10:20:24 +0200
From: Harald Alvestrand <>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110617 Thunderbird/3.1.11
MIME-Version: 1.0
To: Paul Kyzivat <>
References: <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] I-D Action: draft-alvestrand-one-rtp-00.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 15 Aug 2011 08:19:43 -0000

On 08/12/11 17:24, Paul Kyzivat wrote:
> On 8/12/11 2:49 AM, Harald Alvestrand wrote:
>> On 08/12/11 05:37, Ross Finlayson wrote:
>>> 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.
>> 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".
> 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.
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.
> 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.
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.
> 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?
That is a strong argument in favour of "just don't give any codecs". I'm 
adding that too.
> 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.)
Magic numbers are bad for technological health. I don't think I'd like 
to see that.
>     Thanks,
>     Paul