Re: [rtcweb] Multiplexing using the same port number for multiple media descritions

[Christer Holmberg <[e-mail]>]

Hi Harald,

>>One possible alternative solution for SDP multiplex negotiation could be based on the assumption of using the same port number in multiple SDP m- lines (yes, I know SDP does not allow it, and I will come back to that).
>>
>>Something like:
>>
>>SDP offer:
>>
>>m=audio 10000 ...
>>a=rtpmap ...
>>a=rtpmap ...
>m=video 10000 ...
>a=rtpmap ...
>a=rtpmap ...
>
>
>SDP answer (multiplex supported/accepted):
>
>m=audio 20000 ...
>a=rtpmap ...
>a=rtpmap ...
>m=video 20000 ...
>a=rtpmap ...
>a=rtpmap ...
>
>In this case, packets flow from/to port 10000 to port 20000 for both media types.

Yes.

(The question is then whether we need something in addition, e.g. something like the TOGETHER grouping, to actually indicate that they are multiplexed. But, I guess that depends e.g. on the actual multiplex mechanism we'll use.)


>SDP answer (multiplex not-supported/rejected):
>
>m=audio 20000 ...
>a=rtpmap ...
>a=rtpmap ...
>m=video 30000 ...
>a=rtpmap ...
>a=rtpmap ...
>
>In this case, packets would presumably flow between port 10000 and port 20000 for audio, and port 10000 and port 30000 for video.
>Is that a correct interpretation of how you think this would work?

Yes.

>In that case, we have an RTP spec problem, not just an SDP problem: RTP "straight" claims to identify sessions by destination address + port (RFC 3550 section 5.2, for instance). In normal unicast / point-to-point usage, we expect all packets to come from the same 
>address + port too, but RFC 3550 doesn't say that.
>
>I don't know if this is an issue. If it is an issue, sender might have to start over.

I am not sure I understood the issue.

However, I am not saying there aren't any issues - I just think we should allow ourselves to look into different solution alternatives :)

Regards,

Christer