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

[Paul Kyzivat <[e-mail]>]

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?

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

>> Example 1:
>>    Answer, from an entity that understands TOGETHER
>>
>>           v=0
>>           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:
>>     Answer, from an entity that understands grouping, but does not
>>     understand TOGETHER
>>
>>           v=0
>>           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/
>>
>>
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb
>
>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb