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

[Randell Jesup <[e-mail]>]

On 8/12/2011 11:24 AM, 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. (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?
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).

> 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.

Agreed.


> 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.)

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
[e-mail]