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

[Harald Alvestrand <[e-mail]>]

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