Hi Christer and Harald,

I have reviewed both drafts draft-alvestrand-one-rtp-01 and draft-holmberg-mmusic-sdp-multiplex-negotiation-00.

The drafts share the main idea: using the RFC 5888 grouping mechanism to signal that media is multiplexed on the same port (-alvestrand-: TOGETHER; -holmberg-: MULTIPLEX). The following differences caught my attention:

1.       In -alvestrand- port numbers associated with sections of the same TOGETHER group are different in the offer, and then adjusted by the answerer depending on whether it accepts or not. In -holmberg- the port numbers are already the same in the offer.

·         The different port numbers in the offer have an effect on legacy device behaviour: in the -alvestrand- case, the legacy device can accept the port numbers as offered, whereas in the -holmberg- case the legacy device response is not specified (as RFC 4566 does not give a clear indication what to do in case of equal port numbers for different media streams).

2.       In -alvestrand- the interpretation of the "b=" (bandwidth) line is well-defined for multiplexed ports.

·         This is omitted in -holmberg-, but could be specified in a similar manner.

3.       In -alvestrand-, there is the concept of "parameter combining".

·         The draft says: "The general approach when combining the sections is to treat the parameters as if they were all contained in the same section."

·         This seems complicated in general, as there are many SDP attributes that only apply to certain media types or codecs.

·         For example, the "fmtp" attribute contains codec specific parameters, that only apply to the associated codec. For different codecs, a sanity check may resolve this problem (as one codec is likely to not understand the parameters from another codec), but especially in case of multiplexing streams from the same codec this sanity check will not resolve the issue.

·         Maybe "parameter" only points to specific RTP parameters, whereas other parameters/attributes can still be specific for different sections? In that case, it might be better to be more specific, i.e. define and use a term "RTP parameter".

4.       In -alvestrand-, the interpretation of the SDP highly depends on the first media section associated with the TOGETHER group.

·         "If the responder understands the semantics of the TOGETHER extension, the parameters of the first section MUST be used to establish the RTP session, and the parameters for the other sections MUST be ignored".

·         The draft correctly states, that this means that refusing the first "m=" section in a TOGETHER group prohibits establishing the call, whereas other "m=" sections in the same group can be refused.

·         This only holds for specific port and ICE parameters; for other parameters see 4.

·         As this is not specified in -holmberg-, there is a need to consider how to handle possible inconsistencies between "m=" sections associated with one MULTIPLEX group there.

5.       In -holmberg-, there are two criteria to determine the multiplexing of multiple "m=" sections:

·         (1) The sections use the same port.

·         (2) The sections are in the same "MULTIPLEX" group.

·         It is specified, when the answer does not contain  the "MULTIPLEX" group, then multiplexing cannot take place.

·         It is not specified, what to do when the "MULTIPLEX" group is included in the answer but the port numbers of the grouped sections are different.

What is your opinion on these points?

Best regards,

Bert

On 09/14/11 12:40, Christer Holmberg wrote:

This is an alternative to draft-alvestrand-one-rtp-01; we've discussed this.

We're very interested in having feedback on the differences between the two - in the end, there should be only one!