Re: [MMUSIC] MMUSIC Virtual Interim Meeting dial in information

Paul Kyzivat <> Tue, 21 May 2013 17:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 092D521F981B for <>; Tue, 21 May 2013 10:19:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.02
X-Spam-Status: No, score=-0.02 tagged_above=-999 required=5 tests=[AWL=-0.183, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_14=0.6, RDNS_NONE=0.1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oKbMwIXv6GrX for <>; Tue, 21 May 2013 10:19:10 -0700 (PDT)
Received: from ( [IPv6:2001:558:fe14:44:76:96:59:212]) by (Postfix) with ESMTP id 334B621F97FA for <>; Tue, 21 May 2013 10:19:09 -0700 (PDT)
Received: from ([]) by with comcast id egzF1l0040QuhwU5EhK9NU; Tue, 21 May 2013 17:19:09 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([]) by with comcast id ehK81l00w3ZTu2S3NhK9DQ; Tue, 21 May 2013 17:19:09 +0000
Message-ID: <>
Date: Tue, 21 May 2013 13:19:08 -0400
From: Paul Kyzivat <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=q20121106; t=1369156749; bh=AaSqFbnE54L7IvSS3LdhbmmQbRjCkGbJm/U3rkZtKVs=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=rQxoZlJbktDR/uZiSv+QNmZvLr0g2T/ssMmVG1EU+oZpvkzi0ligfe/NfUKsYBNsa GU6mA0o70OK6q/MQ3KB/cxisESg+Lzp01w7m60zPP+GQAxX8lHFp0KbpXzt3eVU+6I 3F/mGE1nltgKbtsAHEMKTHBAiiVhRrWquZw9Vx+J4anwDreS9VjvpovC1sY2mKv95/ UuB/nkhkuPLH0RJEf3TIzJA3pqzEhTL+cSIcGkmdDjqDK91W6/fzfkI7hSQugOsXv5 kp4E8ZOD14PED4CAFOXwza1fWybsMbFu2i6ocd5QuikufzPUxCL6/wxFqCGJLamohM 0oNhGr3VeB5Og==
Subject: Re: [MMUSIC] MMUSIC Virtual Interim Meeting dial in information
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 21 May 2013 17:19:15 -0000

On 5/21/13 10:22 AM, Cullen Jennings (fluffy) wrote:
> On May 21, 2013, at 8:00 AM, Ari Keränen <> wrote:
>> 1)	How to demux RTP (and other media types, but RTP is the most critical). This is currently discussed within the "Plan A vs Plan B" context on the RTCWEB list.
> If we don't end up with the people in the call that are involved wight he proposals on this, I don't think we will be able to do this. I see it breaking into two different topics
> 1a) How to demux SCTP data channel stuff from RTP
> 1b) How to demux RTP

I would cut this slightly differently:

X) relevant ways of classifying packets received on a 5-tuple
Y) relevant ways to use those attributes to associate each packet with
    an m-line in a bundle
Z) how to signal a choice from (Y) in SDP

For X:

There is one layer of classification that distinguishes DTLS from RTP 
from ICE.

Then DTLS can further be classified into the stuff used for DTLS/SRTP 
keying, and DTLS payload packets.

What the DTLS payload packets contain depends on what is layered on top 
of DTLS. The only case we are considering is SCTP. (But we may need to 
make provision for the possibility that something else might be.)

SCTP packets can be demuxed by sctp port. (But there seems no interest 
in this.)

RTP packets can be classified by at least SSRC and PT. We have also been 
discussed using an RTP extension header to provide another 
classification attribute.

For Y:

I guess there is no intent to associate ICE packets with an m-line?

RTP packets can be associated with an m-line based on SSRC *if* an 
a=ssrc line mentioning that SSRC is present in exactly one m-line of the 

RTP packets can be associated with an m-line based on PT *if* that PT is 
present on exactly one m-line of the bundle.

RTP packets can be associated with an m-line based on the extension 
header *if* the value in that header is present in exactly one m-line of 
the bundle.

If none of the above work, then if some combination of the above is 
present in exactly one m-line then that can be used to do the association.

DTLS payload packets can be associated with the collection of m-lines 
with proto of DTLS/* other than DTLS/SRTP.

If all m-lines in the bundle with a proto of DTLS/* but not DTLS/SRTP 
are DTLS/SCTP, then they can be associated with a single m-line based on 
SCTP port *if* there is exactly one m-line bound to that port. (This 
only works if there is a way to associate an SCTP port with a DTLS/SCTP 

For Z:

Mostly implicit above: PT in m-lines, a=ssrc present with m-lines.

We will need a new attribute for the new header value if that is to be 

People didn't want to define a way to specify SCTP port with DTLS/SCTP. 
Without that there can only be one DTLS/SCTP in a bundle. And that is 
probably fine.

As long as there is only one DTLS/* proto other than DTLS/SRTP then all 
DTLS payload packets can go there, so it doesn't really need to be 
specialized for DTLS/SCTP.

Clearly there can't be any UDP or DTLS protos in the bundle, or anything 
other than the above based on UDP.

No additional SDP is needed to say how to classify *if* some combination 
of SSRC, PT, and new header value is unique for each m-line. But we may 
need something else to indicate how to classify any packets that don't 
match. (E.g., an SSRC that is not mentioned in the SDP.)


> Cullen (and to be clear all my emails on this list are in my individual contributor role)
> _______________________________________________
> mmusic mailing list