Subject: [MMUSIC] Dealing with un-defined multiplexing behavior - SDP MUX Draft

From: Suhas Nandakumar <[email-masked]>
Date: Mon, 29 Jun 2015 10:53:00 -0700

Hello All

  I am looking for some feedback on dealing with the multiplexing category
analysis of SDP attributes for which BUNDLE doesn't explicitly define
Multiplexing and De-Multiplexing behavior ( /protocol identification)

Examples include transport over TCP such as  MSRP (RFC4975),  SDP File
transfer (RFC5547) and things like SDP Extensions for Circuit Switched
Bearer  in PSTN (RFC7195)

Section 9.1 for BUNDLE draft provides general considerations for protocol
identification but clearly says

 Each "m=" line within a BUNDLE group MUST use the same transport-
   layer protocol.  If bundled "m=" lines use different protocols on top
   of the transport-layer protocol, there MUST exist a publicly
   available specification which describes a mechanism, for this
   particular protocol combination, how to associate a received data
   with the correct protocol

Here is the proposal
 - For each of these attributes assign category "TBD"
 - Add an explanatory note indicating there doesn't exist mechanisms to
analyze the multiplexing behavior of these attributes and when future
specifications are defined for dealing with such protocols, their
multiplexing behaviors needs to be reanalyzed.

Please let me know your thoughts.

Cheers
Suhas

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 29 Jun 2015 14:35:27 -0400

On 6/29/15 1:53 PM, Suhas Nandakumar wrote:
> Hello All
>
>    I am looking for some feedback on dealing with the multiplexing
> category analysis of SDP attributes for which BUNDLE doesn't explicitly
> define Multiplexing and De-Multiplexing behavior ( /protocol identification)
>
> Section 9.1 for BUNDLE draft provides general considerations for
> protocol identification but clearly says
>

This is probably a reasonable approach.

I think each of the things you meantion need their own treatment (except 
of course that file transfer over msrp is a special case of msrp.)

MSRP is an interesting case because it is already possible to multiplex 
it over MSRP relays. So it may be possible to leverage that to allow 
multiplexing over a bundle. Still, it will take a specific effort to 
work it out.

	Thanks,
	Paul

> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: "Stach, Thomas" <[email-masked]>
Date: Tue, 30 Jun 2015 08:21:15 +0000

Suhas,

I agree, the approach  is reasonable.

Regards
Thomas
> -----Original Message-----
> From: mmusic [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: Montag, 29. Juni 2015 20:35
> To: [email-masked]
> Subject: Re: [MMUSIC] Dealing with un-defined multiplexing behavior - SDP MUX
> Draft
>

---

From: Suhas Nandakumar <[email-masked]>
Date: Tue, 30 Jun 2015 07:04:40 -0700

Thanks Paul and Thomas. I will work on getting the draft updated.

Cheers
Suhas