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

Harald Alvestrand <harald@alvestrand.no> Mon, 15 August 2011 08:19 UTC

Return-Path: <harald@alvestrand.no>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17AF721F8A35 for <rtcweb@ietfa.amsl.com>; Mon, 15 Aug 2011 01:19:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.572
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fbYix52zYg47 for <rtcweb@ietfa.amsl.com>; Mon, 15 Aug 2011 01:19:42 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 039F421F86DF for <rtcweb@ietf.org>; Mon, 15 Aug 2011 01:19:42 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2186E39E112; Mon, 15 Aug 2011 10:19:14 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mdNw7xtF7E+2; Mon, 15 Aug 2011 10:19:13 +0200 (CEST)
Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 0111939E074; Mon, 15 Aug 2011 10:19:12 +0200 (CEST)
Message-ID: <4E48D6C8.6010208@alvestrand.no>
Date: Mon, 15 Aug 2011 10:20:24 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11
MIME-Version: 1.0
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
References: <4E43BDB3.8000504@alvestrand.no> <4E4423A7.2000501@alum.mit.edu> <E17059F7-DF14-4552-8D01-609D3E4BB77C@live555.com> <4E44CCE4.8080307@alvestrand.no> <4E454596.6050700@alum.mit.edu>
In-Reply-To: <4E454596.6050700@alum.mit.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] I-D Action: draft-alvestrand-one-rtp-00.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=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