Subject: [MMUSIC] Draft submission: draft-holmberg-mmusic-sdp-multiplex-negotiation

From: Christer Holmberg <[email-masked]>
Date: Wed, 14 Sep 2011 12:40:59 +0200

Hi,

I've submitted a new draft, draft-holmberg-mmusic-sdp-multiplex-negotiation, which defines a mechanism and grouping framework extension in order to negotiate multiplexing of media associated with multiple m= lines.

Comments are welcome :)

Regards,

Christer

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 14 Sep 2011 20:43:35 +0200

On 09/14/11 12:40, Christer Holmberg wrote:
> Hi,
> I've submitted a new draft, 
> draft-holmberg-mmusic-sdp-multiplex-negotiation, which defines a 
> mechanism and grouping framework extension in order to negotiate 
> multiplexing of media associated with multiple m= lines.
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!
> Comments are welcome :)
> Regards,
> Christer
>
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Bert Greevenbosch <[email-masked]>
Date: Thu, 15 Sep 2011 05:36:41 +0000

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

From: [email-masked] [mailto:[email-masked]] On Behalf Of Harald Alvestrand
Sent: 15 September 2011 02:44
To: Christer Holmberg
Cc: MMUSIC WG
Subject: Re: [MMUSIC] Draft submission: draft-holmberg-mmusic-sdp-multiplex-negotiation

Hi,

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

Comments are welcome :)

Regards,

Christer

mmusic mailing list

[email-masked]<mailto:[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 15 Sep 2011 09:00:35 +0200

Hi Bert,
 
Comments inline.

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

Correct. 

(In order to avoid confusion, I used a different name for the grouping :)

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

Correct.

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

My personal experience is that products will accept the offer in a normal way, and reply with different 
ports, because they aren't really affected by the fact that the remote end uses the same port.

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

Correct.

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

The draft shall say that it is not allowed - neither in the offer or in the answer.

Thanks for your comments!

Regards,

Christer

	Hi,

	

	Comments are welcome :)

	Regards,

	Christer

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 15 Sep 2011 15:49:03 +0200

On 09/15/11 07:36, Bert Greevenbosch wrote:
>
> 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).
>
This is a place where we want input from others' experience. I am 
particularly worried about whether or not there is a case where the 
responder expects to be able to answer from a single port, in which case 
things would fail.
>
> 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".
>
This is a hairy subject, because of the richness of parameters in the 
various SDP extensions; the "fmtp" attribute from RFC 4566 section 6 has 
a <format> attached to it, presumably the payload type number, so they 
can be freely combined, since draft-alvestrand already requires that the 
payload types from the various sections do not collide with each other - 
it is still clear which payload type each "a=fmtp:" attribute is 
associated with.

It seemed better to me to specify a rule and see if that was a workable 
rule than to be silent; if we can't solve it, that may mean the approach 
described is unworkable.

> 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.
>
Agreed.
>
> 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.
>
We could declare such an answer to be malformed?
> What is your opinion on these points?
And similarly ... what is your opinion?
>
> Best regards,
>
> Bert
>
> *From:[email-masked] [mailto:[email-masked]] *On 
> Behalf Of *Harald Alvestrand
> *Sent:* 15 September 2011 02:44
> *To:* Christer Holmberg
> *Cc:* MMUSIC WG
> *Subject:* Re: [MMUSIC] Draft submission: 
> draft-holmberg-mmusic-sdp-multiplex-negotiation
>
> We're very interested in having feedback on the differences between 
> the two - in the end, there should be only one!
>
> Comments are welcome :)
>
> Regards,
>
> Christer
>
>   
>   
> [email-masked]  <mailto:[email-masked]>

---

From: Bert Greevenbosch <[email-masked]>
Date: Fri, 16 Sep 2011 03:06:01 +0000

Hi Harald, Christer, all,

> And similarly ... what is your opinion?

Although draft-holmberg seems to be more straight-forward, it does not yet address some of the issues that have already been addressed by draft-alvestrand. I would be interested in whether these issues would be resolved similarly, or what are the alternatives.

Concerning issue of having a multiplex group with different port numbers, I think it is related to how a legacy device responses to an offer of multiple media streams with the same port. From a standardisation viewpoint, RFC 4566 doesn't forbid it and RFC 3264 allows changing the port number in the answer, but this doesn't mandate anything. Since we can only define something for a compliant answerer, it seems safest to assign different port numbers in the offer, but have the answerer set them to the same when it understands and accepts multiplexing.

What worries me in draft-alvestrand is the parameter combining. Exactly because of the richness in SDP extensions, it seems hard to define a general rule that says all parameters hold for all associated media sections. I think it would be better to define that parameters only hold for the associated media sections, except for certain specific single-appearance parameters (which need to be identified in the draft). For most parameters, this would be consistent with their usage for non-multiplexed media streams. For those single-appearance parameters, we could specify that the first appearance in a multiplex group of those parameters prevails, or declare an answer with conflicting parameters malformed.

Best regards,
Bert

From: Harald Alvestrand [mailto:[email-masked]]
Sent: 15 September 2011 21:49
To: Bert Greevenbosch
Cc: Christer Holmberg; IETF - MMUSIC
Subject: Re: [MMUSIC] Draft submission: draft-holmberg-mmusic-sdp-multiplex-negotiation

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).
This is a place where we want input from others' experience. I am particularly worried about whether or not there is a case where the responder expects to be able to answer from a single port, in which case things would fail.

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.

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".
This is a hairy subject, because of the richness of parameters in the various SDP extensions; the "fmtp" attribute from RFC 4566 section 6 has a <format> attached to it, presumably the payload type number, so they can be freely combined, since draft-alvestrand already requires that the payload types from the various sections do not collide with each other - it is still clear which payload type each "a=fmtp:" attribute is associated with.

It seemed better to me to specify a rule and see if that was a workable rule than to be silent; if we can't solve it, that may mean the approach described is unworkable.

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

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.
We could declare such an answer to be malformed?

Best regards,
Bert

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Harald Alvestrand
Sent: 15 September 2011 02:44
To: Christer Holmberg
Cc: MMUSIC WG
Subject: Re: [MMUSIC] Draft submission: draft-holmberg-mmusic-sdp-multiplex-negotiation

Hi,

Comments are welcome :)

Regards,

Christer

mmusic mailing list

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 16 Sep 2011 08:07:54 +0200

Hi Bert, 

>Although draft-holmberg seems to be more straight-forward, it does not yet address some of the issues that have already been addressed by draft-alvestrand. I would be interested in whether 
>these issues would be resolved similarly, or what are the alternatives.

You mentioned the b= parameter, but are there other issues you have in mind?

The default assumption in draft-holmberg is that, as far as describing the characteristics of each media (as represented by the m= line) we use normal SDP procedures. What we then need to identity, and describe, are the impacts caused by the fact that these medias are multiplexed. For example, how do you use the b= parameters for each individual media to calculate the needed bandwidth for the multiplex, etc.	 

>Concerning issue of having a multiplex group with different port numbers, I think it is related to how a legacy device responses to an offer of multiple media streams with the same port. 
>From a standardisation viewpoint, RFC 4566 doesn't forbid it and RFC 3264 allows changing the port number in the answer, but this doesn't mandate anything. Since we can only define something 
>for a compliant answerer, it seems safest to assign different port numbers in the offer, but have the answerer set them to the same when it understands and accepts multiplexing.

Well, you COULD do that, and then the offerer could send a NEW offer with the same port numbers (instead of saying that one uses the port number of the first m= line, and does not care about the others). But, that would of course mandate a second offer/answer.

However, I would be really interested to hear whether same-port-in-offer really causes problems in existing deployments. From my experience it doesn't, but I of course don't have knowledge about all the products and deployments out there :)

Regards,

Christer

	Hi Christer and Harald,

	

	Agreed.

	 

	 

	Best regards,

	Bert

	Hi,

	

	Comments are welcome :)

	Regards,

	Christer

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Fri, 16 Sep 2011 12:20:31 +0530

|However, I would be really interested to hear whether 
|same-port-in-offer really causes problems in existing 
|deployments. From my experience it doesn't, but I 
|of course don't have knowledge about all the products 
|and deployments out there :)

I agree -- this is unlikely to break any existing deployment. In
addition it simplifies the implementation for RTCWeb apps because they
can just reserve and listen on a single port, instead of reserving and
listening on multiple ports and releasing the resources corresponding to
all other ports but one based on the answer. 

Considering that RTCWeb apps will likely talk to RTCWeb apps and the
chance that it would break an existing implementation is remote I think
it would be pragmatic to fix such a poor existing implementation instead
of adding additional complexity to every RTCWeb app.

Muthu

|-----Original Message-----
|From: [email-masked] [mailto:[email-masked]] On
Behalf Of Christer Holmberg
|Sent: Friday, September 16, 2011 11:38 AM
|To: Bert Greevenbosch; Harald Alvestrand
|Cc: IETF - MMUSIC
|Subject: Re: [MMUSIC] Draft submission:
draft-holmberg-mmusic-sdp-multiplex-negotiation
|
|
|Hi Bert,
|
|>>And similarly ... what is your opinion?
|>
|>Although draft-holmberg seems to be more straight-forward, it does not
yet address some of the issues
|that have already been addressed by draft-alvestrand. I would be
interested in whether
|>these issues would be resolved similarly, or what are the
alternatives.
|
|You mentioned the b= parameter, but are there other issues you have in
mind?
|
|The default assumption in draft-holmberg is that, as far as describing
the characteristics of each
|media (as represented by the m= line) we use normal SDP procedures.
What we then need to identity, and
|describe, are the impacts caused by the fact that these medias are
multiplexed. For example, how do
|you use the b= parameters for each individual media to calculate the
needed bandwidth for the
|multiplex, etc.
|
|>Concerning issue of having a multiplex group with different port
numbers, I think it is related to
|how a legacy device responses to an offer of multiple media streams
with the same port.
|>From a standardisation viewpoint, RFC 4566 doesn't forbid it and RFC
3264 allows changing the port
|number in the answer, but this doesn't mandate anything. Since we can
only define something
|>for a compliant answerer, it seems safest to assign different port
numbers in the offer, but have the
|answerer set them to the same when it understands and accepts
multiplexing.
|
|Well, you COULD do that, and then the offerer could send a NEW offer
with the same port numbers
|(instead of saying that one uses the port number of the first m= line,
and does not care about the
|others). But, that would of course mandate a second offer/answer.
|
|However, I would be really interested to hear whether
same-port-in-offer really causes problems in
|existing deployments. From my experience it doesn't, but I of course
don't have knowledge about all
|the products and deployments out there :)
|
|Regards,
|
|Christer
|
|
|
|
|
|
|	From: Harald Alvestrand [mailto:[email-masked]]
|	Sent: 15 September 2011 21:49
|	To: Bert Greevenbosch
|	Cc: Christer Holmberg; IETF - MMUSIC
|	Subject: Re: [MMUSIC] Draft submission:
draft-holmberg-mmusic-sdp-multiplex-negotiation
|
|
|
|	On 09/15/11 07:36, Bert Greevenbosch wrote:
|
|	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:
|
|
|
|	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).
|
|	This is a place where we want input from others' experience. I
am particularly worried about
|whether or not there is a case where the responder expects to be able
to answer from a single port, in
|which case things would fail.
|
|
|
|	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.
|
|	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".
|
|	This is a hairy subject, because of the richness of parameters
in the various SDP extensions;
|the "fmtp" attribute from RFC 4566 section 6 has a <format> attached to
it, presumably the payload
|type number, so they can be freely combined, since draft-alvestrand
already requires that the payload
|types from the various sections do not collide with each other - it is
still clear which payload type
|each "a=fmtp:" attribute is associated with.
|
|	It seemed better to me to specify a rule and see if that was a
workable rule than to be silent;
|if we can't solve it, that may mean the approach described is
unworkable.
|
|
|
|
|
|	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.
|
|	Agreed.
|
|
|
|	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.
|
|	We could declare such an answer to be malformed?
|
|
|
|
|
|	What is your opinion on these points?
|
|	And similarly ... what is your opinion?
|
|
|
|
|
|	Best regards,
|
|	Bert
|
|
|
|
|
|	From: [email-masked] [mailto:[email-masked]]
On Behalf Of Harald Alvestrand
|	Sent: 15 September 2011 02:44
|	To: Christer Holmberg
|	Cc: MMUSIC WG
|	Subject: Re: [MMUSIC] Draft submission:
draft-holmberg-mmusic-sdp-multiplex-negotiation
|
|
|
|	On 09/14/11 12:40, Christer Holmberg wrote:
|
|
|
|	Hi,
|
|
|
|	I've submitted a new draft,
draft-holmberg-mmusic-sdp-multiplex-negotiation, which defines a
|mechanism and grouping framework extension in order to negotiate
multiplexing of media associated with
|multiple m= lines.
|
|	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!
|
|
|
|
|
|
|	Comments are welcome :)
|
|
|
|	Regards,
|
|
|
|	Christer
|
|
|
|
|
|	_______________________________________________
|	mmusic mailing list
|	[email-masked]
|	https://www.ietf.org/mailman/listinfo/mmusic
|
|
|
|
|
|_______________________________________________
|mmusic mailing list
[email-masked]
|https://www.ietf.org/mailman/listinfo/mmusic

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Fri, 16 Sep 2011 10:35:32 +0200

I think there are two major points of difference between the TOGETHER and 
the MULTIPLEX approach:

1) Usage of port numbers in the SDP offer

2) Combination of additional parameters from the SDP offer

Let me analyze 1) in more detail. I believe a stream of media is 
identified by the transport addresses of both endpoints and the protocol 
(RTP/RTCP in this case). So, if we take the MULTIPLEX approach, the 
offerer will include the same port number in all its multiplexed streams. 
Now, if the answerer decides to multiplex, then we will have a single 
stream, because the transport addresses of all the RTP flows are equal.

In this MULTIPLEX approach, if the answerer does not support the 
extension or does not want to use it, it will create an SDP answer that 
contains different port numbers. Therefore, each RTP flow will be send 
over a different 5-tuple, and each RTP flow will constitute a different 
media stream, even when all the transport addresses at one endpoint are 
equal. So I don't see this creating a problem with any existing endpoint 
that does not support the extension.

In the TOGETHER approach, the offerer has to open a different port for 
each media stream, even when then they won't be used (if the answerer 
uses multiplex). But the offerer has to be ready to receive media in 
those ports, so a socket must be created and listening there when the SDP 
is published. If the answerer decides to use multiplex, we need a new SDP 
O/A to explicitly indicate in SDP the result of the negotiation (similar 
to ICE when picking up a candidate different than the m/c lines). A 
second O/A is unavoidable in this case.

Needless to say, the TOGETHER approach will confuse any intermediary that 
inspects the SDP. Ok, this is not a problem for RTCWEB since the 
signaling is encrypted, but in the general case, and considering existing 
deployments, this is a problem. Of course, a second O/A will solve this 
problem.

Therefore, I see the MULTIPLEX approach done according to the SDP 
procedures and with less side-effects than the TOGETHER approach.

About issue 2). The MULTIPLEX approach seems to be more respectful with 
the expression of parameters (e.g., bandwidth). Each parameter still 
keeps their original semantics, meaning that if it is a media-level 
modifier, it still modifies that media, and not the multiplexed group.

The TOGETHER approach is less respectful with that declaration. In 
particular, it less at the mercy of the answerer (which decides whether 
to multiplex or not) the decision on the semantics of the parameters, 
e.g., whether they apply to the multiplexed group or to each of the RTP 
flows. That is a recipe for disaster, because if you take an isolated SDP 
offer, you don't know the semantics until you get an SDP answer. I kindly 
request you not going into this direction, please.

As a summary, I believe the MULTIPLEX approach is more backwards 
compatible than the TOGETHER approach, and we should go into this direction.

BR,

      Miguel (as an individual).

On 16/09/2011 8:50, Muthu Arul Mozhi Perumal (mperumal) wrote:
> |> From a standardisation viewpoint, RFC 4566 doesn't forbid it and RFC
> |the "fmtp" attribute from RFC 4566 section 6 has a<format>  attached to

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 16 Sep 2011 19:56:23 +0000

I agree with Miguel's analysis.

In particular, the current TOGETHER draft uses different port numbers in the offer/answer but ignores the second one if grouping is achieved.  It further says:
   Third-party interceptors that sniff negotiation but do not understand
   the extension may end up listening to the wrong port number for some
   of the media flows.  This is not deemed greatly harmful.

Unfortunately, that's not the case.  There are SIP middleboxes in actual deployment today which will detect no RTP on the wrong port numbers, which not only generate logs/alarms for such conditions, but will generate BYEs to tear down the call.  That is harmful, to the application trying to use TOGETHER.  It would be nice to say "well make the middleboxes not do that", but that's not gonna help - especially if it's someone else's middlebox multiple domains way that the SIP call happens to traverse through.

-hadriel

On Sep 16, 2011, at 4:35 AM, Miguel A. Garcia wrote:

> I think there are two major points of difference between the TOGETHER and the MULTIPLEX approach:
> 
> Let me analyze 1) in more detail. I believe a stream of media is identified by the transport addresses of both endpoints and the protocol (RTP/RTCP in this case). So, if we take the MULTIPLEX approach, the offerer will include the same port number in all its multiplexed streams. Now, if the answerer decides to multiplex, then we will have a single stream, because the transport addresses of all the RTP flows are equal.
> 
> In this MULTIPLEX approach, if the answerer does not support the extension or does not want to use it, it will create an SDP answer that contains different port numbers. Therefore, each RTP flow will be send over a different 5-tuple, and each RTP flow will constitute a different media stream, even when all the transport addresses at one endpoint are equal. So I don't see this creating a problem with any existing endpoint that does not support the extension.
> 
> In the TOGETHER approach, the offerer has to open a different port for each media stream, even when then they won't be used (if the answerer uses multiplex). But the offerer has to be ready to receive media in those ports, so a socket must be created and listening there when the SDP is published. If the answerer decides to use multiplex, we need a new SDP O/A to explicitly indicate in SDP the result of the negotiation (similar to ICE when picking up a candidate different than the m/c lines). A second O/A is unavoidable in this case.
> 
> Needless to say, the TOGETHER approach will confuse any intermediary that inspects the SDP. Ok, this is not a problem for RTCWEB since the signaling is encrypted, but in the general case, and considering existing deployments, this is a problem. Of course, a second O/A will solve this problem.
> 
> Therefore, I see the MULTIPLEX approach done according to the SDP procedures and with less side-effects than the TOGETHER approach.
> 
> 
> About issue 2). The MULTIPLEX approach seems to be more respectful with the expression of parameters (e.g., bandwidth). Each parameter still keeps their original semantics, meaning that if it is a media-level modifier, it still modifies that media, and not the multiplexed group.
> 
> The TOGETHER approach is less respectful with that declaration. In particular, it less at the mercy of the answerer (which decides whether to multiplex or not) the decision on the semantics of the parameters, e.g., whether they apply to the multiplexed group or to each of the RTP flows. That is a recipe for disaster, because if you take an isolated SDP offer, you don't know the semantics until you get an SDP answer. I kindly request you not going into this direction, please.
> 
> As a summary, I believe the MULTIPLEX approach is more backwards compatible than the TOGETHER approach, and we should go into this direction.
> 
> BR,
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 16 Sep 2011 20:05:17 +0000

> The draft shall say that it is not allowed - neither in the offer or in the answer.

It would be better to have the draft say to treat such a received offer/answer as just not multiplexing. (ie, continue as before this draft)

-hadriel

---

From: Bert Greevenbosch <[email-masked]>
Date: Tue, 20 Sep 2011 01:19:42 +0000

Hi Christer,

> You mentioned the b= parameter, but are there other issues you have in mind?

The other issues that come to my mind are the possible inconsistencies in port numbers and parameters. I think we are having a good discussion on that at the mailing list right now. I like the approach of keeping the separation between the parameters of separate "m=" lines, even when the associated streams are multiplexed.

> However, I would be really interested to hear whether same-port-in-offer really causes problems in existing deployments. From my experience it doesn't, but I of course don't have knowledge about al…

Yes, as there are many implementations, I believe it is hard to make any general statement on what they do. However, I agree with the expectation that many legacy implementations will update the port number, or at least detect multiple usage of the same port.

Best regards,
Bert

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]] 
Sent: 16 September 2011 14:08
To: Bert Greevenbosch; Harald Alvestrand
Cc: IETF - MMUSIC
Subject: RE: [MMUSIC] Draft submission: draft-holmberg-mmusic-sdp-multiplex-negotiation

Hi Bert, 

Regards,

Christer

	Hi Christer and Harald,

	

	Agreed.

	 

	 

	Best regards,

	Bert

	Hi,

	

	Comments are welcome :)

	Regards,

	Christer

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 20 Sep 2011 05:41:39 +0000

BTW, regarding differences between the two approaches: when draft-alvestrand-one-rtp-01 succeeds, it creates a single RTP/RTCP session; when draft-holmberg-mmusic-sdp-multiplex-negotiation-00 succeeds, it doesn't say anything about the RTP/RTCP in the draft... I assume they're still separate RTP/RTCP sessions and just happen to be multiplexed onto a single 5-tuple, and de-multiplexed by SSRC/PT.  Right?  The draft should make it clearer.

In particular, draft-alvestrand-one-rtp-01 means there's only one SRTP/SRTCP context/key/session, and RTCP SR/RR/etc. messages could be concatenated for the different streams into one UDP packet, and if one stream is AVPF then all streams are AVPF, etc.  If for draft-holmberg-mmusic-sdp-multiplex-negotiation-00 they are different RTP/RTCP sessions, however, then they're separate SRTP contexts de-muxed by SSRC/PT, and separate RTCP messages would need to be in separate UDP packets, etc.

In other words, draft-alvestrand-one-rtp-01 is a muxing function logically built inside the RTP/RTCP layer, whereas draft-holmberg-mmusic-sdp-multiplex-negotiation-00 is a logical muxing layer below RTP/RTCP (and below SRTP if it's used), like a bump-in-the-wire.  Right?

Why does this matter?
1) It would clarify the SDP media-sessions/attribute handling.

2) Because if we assume an interworking gateway would be required in rtcweb <-> PSTN cases, and if the gateway could do TOGETHER/MULTIPLEX on the rtcweb side while doing normal separate 5-tuple streams on the other side... then such a gateway would be cheaper/scale-better if it could demux UDP packets based on SSRC, and let RTCP and SRTP go end-to-end.  Otherwise in the TOGETHER approach, the gateway has to terminate SRTP, and parse deep into RTCP packets to split them apart... or revert the rtcweb side to using separate ports instead of TOGETHER.

-hadriel

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 20 Sep 2011 15:04:55 +0200

Hi Hadriel,

>BTW, regarding differences between the two approaches: when
>draft-alvestrand-one-rtp-01 succeeds, it creates a single
>RTP/RTCP session; when
>draft-holmberg-mmusic-sdp-multiplex-negotiation-00 succeeds,
>it doesn't say anything about the RTP/RTCP in the draft... I
>assume they're still separate RTP/RTCP sessions and just
>happen to be multiplexed onto a single 5-tuple, and
>de-multiplexed by SSRC/PT.  Right?  The draft should make it clearer.

You bring up an important point, which I've also been thinking about.

In general, I think the draft should allow both cases: a single RTP session, and one-session-per-m-line.

The question is whether we want to have some kind of indicator which is used.

Also, for both cases, we would need a description, or a reference to a description, about the impacts on the RTP level. For example, in the case of multiple RTP sessions, we need to know how they are distinguished.  I think people are working on drafts which will describe the RTP details.

Regards,

Christer

>
> In particular, draft-alvestrand-one-rtp-01 means there's only
> one SRTP/SRTCP context/key/session, and RTCP SR/RR/etc.
> messages could be concatenated for the different streams into
> one UDP packet, and if one stream is AVPF then all streams
> are AVPF, etc.  If for
> draft-holmberg-mmusic-sdp-multiplex-negotiation-00 they are
> different RTP/RTCP sessions, however, then they're separate
> SRTP contexts de-muxed by SSRC/PT, and separate RTCP messages
> would need to be in separate UDP packets, etc.
>
> In other words, draft-alvestrand-one-rtp-01 is a muxing
> function logically built inside the RTP/RTCP layer, whereas
> draft-holmberg-mmusic-sdp-multiplex-negotiation-00 is a
> logical muxing layer below RTP/RTCP (and below SRTP if it's
> used), like a bump-in-the-wire.  Right?
>
> Why does this matter?
> 2) Because if we assume an interworking gateway would be
> required in rtcweb <-> PSTN cases, and if the gateway could
> do TOGETHER/MULTIPLEX on the rtcweb side while doing normal
> separate 5-tuple streams on the other side... then such a
> gateway would be cheaper/scale-better if it could demux UDP
> packets based on SSRC, and let RTCP and SRTP go end-to-end.
> Otherwise in the TOGETHER approach, the gateway has to
> terminate SRTP, and parse deep into RTCP packets to split
> them apart... or revert the rtcweb side to using separate
> ports instead of TOGETHER.
>
> -hadriel
>
>
> > In particular, the current TOGETHER draft uses different
> port numbers in the offer/answer but ignores the second one
> if grouping is achieved.  It further says:
> > Unfortunately, that's not the case.  There are SIP
> middleboxes in actual deployment today which will detect no
> RTP on the wrong port numbers, which not only generate
> logs/alarms for such conditions, but will generate BYEs to
> tear down the call.  That is harmful, to the application
> trying to use TOGETHER.  It would be nice to say "well make
> the middleboxes not do that", but that's not gonna help -
> especially if it's someone else's middlebox multiple domains
> way that the SIP call happens to traverse through.
> >
> > -hadriel
> >
> >
> >> Let me analyze 1) in more detail. I believe a stream of
> media is identified by the transport addresses of both
> endpoints and the protocol (RTP/RTCP in this case). So, if we
> take the MULTIPLEX approach, the offerer will include the
> same port number in all its multiplexed streams. Now, if the
> answerer decides to multiplex, then we will have a single
> >> In this MULTIPLEX approach, if the answerer does not
> support the extension or does not want to use it, it will
> create an SDP answer that contains different port numbers.
> Therefore, each RTP flow will be send over a different
> 5-tuple, and each RTP flow will constitute a different media
> stream, even when all the transport addresses at one endpoint
> are equal. So I don't see this creating a problem with any
> existing endpoint that does not support the extension.
> >>
> >> In the TOGETHER approach, the offerer has to open a
> different port for each media stream, even when then they
> won't be used (if the answerer uses multiplex). But the
> offerer has to be ready to receive media in those ports, so a
> socket must be created and listening there when the SDP is
> published. If the answerer decides to use multiplex, we need
> a new SDP O/A to explicitly indicate in SDP the result of the
> negotiation (similar to ICE when picking up a candidate
> different than the m/c lines). A second O/A is unavoidable in
> this case.
> >>
> >> Needless to say, the TOGETHER approach will confuse any
> intermediary that inspects the SDP. Ok, this is not a problem
> for RTCWEB since the signaling is encrypted, but in the
> general case, and considering existing deployments, this is a
> problem. Of course, a second O/A will solve this problem.
> >>
> >> Therefore, I see the MULTIPLEX approach done according to
> the SDP procedures and with less side-effects than the
> TOGETHER approach.
> >>
> >>
> >> About issue 2). The MULTIPLEX approach seems to be more
> respectful with the expression of parameters (e.g.,
> bandwidth). Each parameter still keeps their original
> semantics, meaning that if it is a media-level modifier, it
> still modifies that media, and not the multiplexed group.
> >>
> >> The TOGETHER approach is less respectful with that
> declaration. In particular, it less at the mercy of the
> answerer (which decides whether to multiplex or not) the
> decision on the semantics of the parameters, e.g., whether
> they apply to the multiplexed group or to each of the RTP
> flows. That is a recipe for disaster, because if you take an
> isolated SDP offer, you don't know the semantics until you
> get an SDP answer. I kindly request you not going into this
> direction, please.
> >>
> >> As a summary, I believe the MULTIPLEX approach is more
> backwards compatible than the TOGETHER approach, and we
> should go into this direction.
> >>
> >> BR,
> >>
> deployments.
> >>> |From my experience it doesn't, but I of course don't
> have knowledge
> >>> |about all the products and deployments out there :)
> >>>
> >>> addition it simplifies the implementation for RTCWeb apps because
> >>> they can just reserve and listen on a single port, instead of
> >>> reserving and listening on multiple ports and releasing the
> >>> resources corresponding to all other ports but one based
> on the answer.
> >>>
> >>> chance that it would break an existing implementation is remote I
> >>> think it would be pragmatic to fix such a poor existing
> >>> implementation instead of adding additional complexity to
> every RTCWeb app.
> >>>
> >>> Muthu
> >>>
> >>> |>Although draft-holmberg seems to be more
> straight-forward, it does
> >>> |>not
> >>> |You mentioned the b= parameter, but are there other
> issues you have
> >>> |in
> >>> mind?
> >>> |
> >>> |The default assumption in draft-holmberg is that, as far as
> >>> |describing
> >>> |you use the b= parameters for each individual media to calculate
> >>> |the
> >>> needed bandwidth for the
> >>> |multiplex, etc.
> >>> |
> >>> |> From a standardisation viewpoint, RFC 4566 doesn't
> forbid it and
> >>> |> RFC
> >>> |number in the answer, but this doesn't mandate anything.
> Since we
> >>> |can
> >>> only define something
> >>> |Well, you COULD do that, and then the offerer could send a NEW
> >>> |offer
> >>> |(instead of saying that one uses the port number of the first m=
> >>> |line,
> >>> |existing deployments. From my experience it doesn't, but I of
> >>> |course
> >>> |in the offer, and then adjusted by the answerer depending on
> >>> |whether it
> >>> |       The different port numbers in the offer have an effect on
> >>> | legacy
> >>> |case the legacy device response is not specified (as RFC
> 4566 does
> >>> |not
> >>> |       This is a place where we want input from others'
> experience.
> >>> | I
> >>> |whether or not there is a case where the responder expects to be
> >>> |able
> >>> |       In -alvestrand- the interpretation of the "b="
> (bandwidth)
> >>> | line
> >>> |associated codec. For different codecs, a sanity check
> may resolve
> >>> |this
> >>> problem (as one codec is
> >>> |can still be specific for different sections? In that case, it
> >>> |might be
> >>> |       This is a hairy subject, because of the richness of
> >>> | parameters
> >>> |the "fmtp" attribute from RFC 4566 section 6 has a<format>
> >>> |attached to
> >>> |types from the various sections do not collide with each
> other - it
> >>> |is
> >>> |       It seemed better to me to specify a rule and see
> if that was
> >>> | a
> >>> |       In -alvestrand-, the interpretation of the SDP highly
> >>> | depends on
> >>> the first media section
> >>> |       The draft correctly states, that this means that refusing
> >>> | the
> >>> |group prohibits establishing the call, whereas other
> "m=" sections
> >>> |in
> >>> |       This only holds for specific port and ICE parameters; for
> >>> | other
> >>> parameters see 4.
> >>> |
> >>> |       It is not specified, what to do when the
> "MULTIPLEX" group
> >>> | is
> >>> |       From: [email-masked]
> >>> | [mailto:[email-masked]]

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 21 Sep 2011 14:02:13 +0200

> In particular, draft-alvestrand-one-rtp-01 means there's only one SRTP/SRTCP context/key/session, and RTCP SR/RR/etc. messages could be concatenated for the different streams into one UDP packet, a…
My belief after reading Magnus' opus on multiplexing and listening to 
all the discussions in Montreal was that demuxing of two RTP sessions 
based on SSRC/PT was a Really Bad Idea, and we shouldn't do it - so I 
tried to find a way to work around the limitations in SDP signalling so 
that we could complete signallling to get one RTP session.
> In other words, draft-alvestrand-one-rtp-01 is a muxing function logically built inside the RTP/RTCP layer, whereas draft-holmberg-mmusic-sdp-multiplex-negotiation-00 is a logical muxing layer belo…
I read draft-holmberg as another way to get one RTP session (when it 
succeeds).
> 2) Because if we assume an interworking gateway would be required in rtcweb<->  PSTN cases, and if the gateway could do TOGETHER/MULTIPLEX on the rtcweb side while doing normal separate 5-tuple streams on the other side... then such a gateway would be cheaper/scale-better if it could demux UDP packets based on SSRC, and let RTCP and SRTP go end-to-end.  Otherwise in the TOGETHER approach, the gateway has to terminate SRTP, and parse deep into RTCP packets to split them apart... or revert the rtcweb side to using separate ports instead of TOGETHER.
Such a gateway should, in my opinion, refuse to multiplex, and negotiate 
two 5-tuples.

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 21 Sep 2011 15:23:36 +0200

Hi,

What is missing in this discussion is the draft that Lennox and
Rosenberg was tasked to provide. The one discussing multiple media types
in one RTP session. As that is the current assumption in the RTCWEB WG
to use one RTP session for multiple media types to use only a single
lower layer transport context, in most cases a given UDP flow defined by
the source and destination address and port.

I would note that I am working on the more generic issue of explicit
multiplexing of several RTP sessions on the same lower layer transport.
So far I do believe that this can in fact use the same signalling
mechanism as described in this draft with the extension of having an
attribute in each media description to identify the RTP session and its
multiplexing identifier.

I will inform when that draft is available.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 21 Sep 2011 15:51:52 +0200

> the source and destination address and port.
Lennox and Rosenberg have not spoken. I am very uncomfortable with the 
idea that we should stop work on this important matter because of people 
that have obviously found that other things have taken priority In Real 
Life. I would be delighted to get input from them, but I don't feel we 
can block on them.
> I will inform when that draft is available.
Looking forward to seeing what the RTP headers look like in your draft.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 21 Sep 2011 21:38:22 +0200

Hi,

As Magnus says, the actual RTP details would be specified elsewhere, and the negotiation draft would refer to those specifications.

However, me might still need to define an indicator in the negotiation draft, which can be used in SDP to indicate whether a single, or multiple, RTP sessions are used.

Regards,

Christer

-----Original Message-----
From: Magnus Westerlund 
Sent: 21. syyskuuta 2011 16:24
To: Harald Alvestrand
Cc: Hadriel Kaplan; IETF - MMUSIC; Christer Holmberg
Subject: Re: [MMUSIC] Draft submission: draft-holmberg-mmusic-sdp-multiplex-negotiation

Hi,

What is missing in this discussion is the draft that Lennox and Rosenberg was tasked to provide. The one discussing multiple media types in one RTP session. As that is the current assumption in the RTCWEB WG to use one RTP session for multiple media types to use only a single lower layer transport context, in most cases a given UDP flow defined by the source and destination address and port.

I would note that I am working on the more generic issue of explicit multiplexing of several RTP sessions on the same lower layer transport.
So far I do believe that this can in fact use the same signalling mechanism as described in this draft with the extension of having an attribute in each media description to identify the RTP session and its multiplexing identifier.

Cheers

Magnus Westerlund

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 24 Sep 2011 00:05:01 +0000

Magnus,
Can you explain what your draft will do?  For example, will it just add a shim header below RTP/RTCP? (ie, like the 16-bit channel number field in TURN)

It would be nice to re-use whatever multiplexing scheme ends up being used in RTCWEB, for generic SIP applications. And it would be really nice not to have 3 ways of doing it. :)
So if you're going to propose a simple channel header for multiplexing, I don't see why we wouldn't just make it the one-and-only muxing model... even for RTCWEB, if it can be done quickly enough.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 24 Sep 2011 03:46:57 +0000

> However, me might still need to define an indicator in the negotiation draft, which can be used in SDP to indicate whether a single, or multiple, RTP sessions are used.

I would prefer we pick one and only one way to multiplex.  If it's one RTP session, or multiple RTP sessions demuxed by SSRC/PT, or multiple RTP sessions over a shim... let's just pick one of those to put in an RFC.  Otherwise you'll get a mishmash of vendor A doing X and vendor B doing Y. 

-hadriel

---

From: Harald Alvestrand <[email-masked]>
Date: Sat, 24 Sep 2011 08:18:24 +0200

> I would prefer we pick one and only one way to multiplex.  If it's one RTP session, or multiple RTP sessions demuxed by SSRC/PT, or multiple RTP sessions over a shim... let's just pick one of those…
I see this debate as concerning two different things.

One is the need to remove the restriction that the top level MIME type 
constrains what media streams can be combined in an RTP session. That 
was (in my opinion) an architectural mistake of SDP, and actually has 
nothing whatsoever to do with RTP; requiring this particular separation 
on this particular dividing line is inappropriate for multiple reasons.

Another is the need to develop a way to run multiple RTP sessions (for 
those cases where multiple RTP sessions are appropriate tools) across a 
single 5-tuple. As I understand Magnus' missive, this is what he intends 
to have his draft describe.

In all cases, I think we preserve all 3 levels of the RTP multiplex: 
Payload type, SSRC and RTP session. They are tools we should use when 
they are appropriate.

                         Harald

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 25 Sep 2011 20:11:16 +0200

Hi,

I think it would be great if there was only one way of doing the multiplexing.

However, as far as I understand, people might have different requirements on the multiplexing (for example, RTCWEB and CLUE), and I don't want us having to define a new SDP negotiation mechanism for every multiplexing mechanism... :)

But, I think it would be great to have a discussion about that in AVTCORE.

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Harald Alvestrand
Sent: 24. syyskuuta 2011 9:18
To: Hadriel Kaplan
Cc: Magnus Westerlund; IETF - MMUSIC; Christer Holmberg
Subject: Re: [MMUSIC] Draft submission: draft-holmberg-mmusic-sdp-multiplex-negotiation

One is the need to remove the restriction that the top level MIME type constrains what media streams can be combined in an RTP session. That was (in my opinion) an architectural mistake of SDP, and actually has nothing whatsoever to do with RTP; requiring this particular separation on this particular dividing line is inappropriate for multiple reasons.

Another is the need to develop a way to run multiple RTP sessions (for those cases where multiple RTP sessions are appropriate tools) across a single 5-tuple. As I understand Magnus' missive, this is what he intends to have his draft describe.

In all cases, I think we preserve all 3 levels of the RTP multiplex: 
Payload type, SSRC and RTP session. They are tools we should use when they are appropriate.

                         Harald

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 26 Sep 2011 13:41:07 +0200

On 2011-09-24 02:05, Hadriel Kaplan wrote:
> 
> Magnus, Can you explain what your draft will do?  For example, will
> it just add a shim header below RTP/RTCP? (ie, like the 16-bit
> channel number field in TURN)

I have looked at the ideas that was thrown around in Quebec in how
multiple RTP sessions can be transported one lower layer transport. None
was really good. I am proposing an shim layer with the explicit session
ID. However instead of placing it in between the UDP and RTP header I am
placing it last in the UDP payload. Thus this is an evolution of the
ideas I have had before.  That way the packet will be RTP for anyone
looking at it. For RTP payloads that has variable length none without
the signalling can determine if this is the multiplexing solution or
not. Thus it should have excellent firewall traversal behavior. Sure,
the ultrastrict FWs will still stumble on it. But, I don't see that we
can use FW as an argument for stopping all innovation in the RTP layer.

> 
> It would be nice to re-use whatever multiplexing scheme ends up being
> used in RTCWEB, for generic SIP applications. And it would be really
> nice not to have 3 ways of doing it. :) So if you're going to propose
> a simple channel header for multiplexing, I don't see why we wouldn't
> just make it the one-and-only muxing model... even for RTCWEB, if it
> can be done quickly enough.
> 

I agree, and if we in fact can get the specification for how to support
multiple RTP sessions over one 5-tuple in time for RTCWEB then that is
likely better than the current compromise with a single session solution
for RTCWEB and continuing working on a multiple session solution.
However, I can't strongly argue that line myself as feel bound by the
agreement from Quebec. But I promise to work diligent on providing the
alternative solution.

Cheers

Magnus Westerlund