Re: [MMUSIC] SCTP question: Where does it multiplex?

Paul Kyzivat <> Tue, 11 December 2012 20:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E7B5711E8099 for <>; Tue, 11 Dec 2012 12:20:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.401
X-Spam-Status: No, score=-0.401 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vRcBTrB0D4Iq for <>; Tue, 11 Dec 2012 12:20:05 -0800 (PST)
Received: from ( [IPv6:2001:558:fe14:43:76:96:62:64]) by (Postfix) with ESMTP id EAEB811E8097 for <>; Tue, 11 Dec 2012 12:20:04 -0800 (PST)
Received: from ([]) by with comcast id aKve1k0031ZXKqc57LL4rD; Tue, 11 Dec 2012 20:20:04 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([]) by with comcast id aLL31k01Y3ZTu2S3hLL4SW; Tue, 11 Dec 2012 20:20:04 +0000
Message-ID: <>
Date: Tue, 11 Dec 2012 15:20:03 -0500
From: Paul Kyzivat <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Dan Wing <>
References: <> <> <> <> <> <> <010401cdd7d0$d006d310$70147930$> <> <023f01cdd7d5$48e33c70$daa9b550$>
In-Reply-To: <023f01cdd7d5$48e33c70$daa9b550$>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=q20121106; t=1355257204; bh=yy8UseKF1wAPGL59KFeelhANl9zP7wqOnQO9IFK8bn0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=RO+tn9c/UUIVoltg/DwLK57l0jXyEL3yLliqEjGrxC/0Z448+8tTkchBp12TydR2J MU8oQYRwlBQS6rc5suMUvp3BE9LWyVt+7cuZUsADVfquiknb+NcjVGweolIgmUDlOv prB5t8YZ+bWsgjF3am0tJdjZlB9/M4RfLQdh/a7z7W1KQfK9YR7FW6i1f8dDx7LhmO ozh9KwKIIE/DZvDkJv14tW3YaTs2FQ98Ak9p71IPNkDZqExHpvJCrCNsK6htFe46OV hOaTZtB3hStecikBnpT6rREevdjda+p6ERDvG6QSmVzXT1QL/27WpKysDw0+ZAlNw8 Z1FcZH5APBjIw==
Subject: Re: [MMUSIC] SCTP question: Where does it multiplex?
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, 11 Dec 2012 20:20:06 -0000


On 12/11/12 2:25 PM, Dan Wing wrote:
>> -----Original Message-----
>> From: Paul Kyzivat []
>> Sent: Tuesday, December 11, 2012 11:17 AM
>> To: Dan Wing
>> Cc:
>> Subject: Re: [MMUSIC] SCTP question: Where does it multiplex?
>> Hi Dan,
>> Comments inline
>> On 12/11/12 1:53 PM, Dan Wing wrote:
>>>> -----Original Message-----
>>>> From: [] On
>>>> Behalf Of Paul Kyzivat
>>>> Sent: Tuesday, December 11, 2012 7:43 AM
>>>> To:
>>>> Subject: Re: [MMUSIC] SCTP question: Where does it multiplex?
>>>> More inline.
>>>> On 12/11/12 4:08 AM, Salvatore Loreto wrote:
>>>>> Hi Paul,
>>>>> see in line!
>>>>> On 12/3/12 10:00 PM, Paul Kyzivat wrote:
>>>>>> Commenting on a different point
>>>>>> On 12/1/12 9:53 AM, Harald Alvestrand wrote:
>>>>>>> The interesting difference is that the multiplexing between
>>>>>>> DTLS/SCTP traffic and BUNDLE multiplexing is that DTLS/SCTP
>>>>>>> traffic is not carried in SSRCs, which means:
>>>>>>> - There can be only one DTLS/SCTP stream in a bundle (which may
>>>>>>> have multiple associations, as you state below); you can't have
>>>>>>> multiple lines with proto DTLS/SCTP in a bundle.
>>>>>> I am not an SCTP expert. But IIUC, SCTP was designed to run
>>>>>> directly over IP. It has its own notion of port used to demux
>>>>>> multiple SCTP associations over the same IP address.
>>>>>> I presume that that same mechanism is still there when SCTP is run
>>>>>> over DTLS over UDP.
>>>>>> So, the traffic coming over DTLS must first be demuxed into RTP
>>>>>> traffic and SCTP traffic.
>>>>> based on the current stack the SCTP traffic is the only traffic that
>>>>> runs directly over the DTLS stack.
>>>> Yes, that is what I thought. But Harald has been asking about
>>>> multiplexing this with RTP traffic. (Actually I think it would be
>>>> DTLS/SRTP traffic that it would be multiplexed with.)
>>>>> What I am trying to do is to include the Randell Jesup (I am
>>>>> including him in CC as I am not sure he is subscribed to this
>> mailing list)
>>>>>     suggestion to give the possibility to have multiple SCTP
>>>>> *associations* running  on top of the same DTLS session and of
>>>>> course providing a way to signal it in SDP.
>>>> IIUC, SCTP (having been designed as a transport layer protocol)
>>>> defines its own notion of port, and has fields in its protocol to
>>>> carry the local and remote port number. Presumably those fields are
>>>> still there when run over UDP or DTLS. So it should be possible to
>>>> support multiple SCTP associations over the same DTLS connection,
>>>> each distinguished by its own port pair.
>>> Yes, SCTP has its own notion of ports.  How this works when SCTP is
>>> carried over UDP is not quite clear, especially because SCTP assumes a
>>> NAPT will not rewrite the SCTP port number (SCTP endeavors to make
>>> such port rewriting difficult).  But of course a NAPT (and the MAP
>>> techniques) rewrite UDP port numbers.  I believe SCTP would only be
>>> able to successfully convey its UDP port numbers for a device that is
>>> not behind a NAT (that is, a server sitting directly on the Internet,
>>> rather than a remote peer that is behind a NAT).  Creative use of PCP,
>>> NAT-PMP, or UPnP IGD would improve that situation in the future.
>> I find what you say above confusing.
> It is confusing, because SCTP's specifications require different
> things of a NAPT than UDP, TCP, or DCCP.  Specifically, SCTP's
> specifications require the NAPT to not rewrite (not change) the
> source port number of outgoing SCTP-over-IP packets.  Reference
> draft-ietf-behave-sctpnat.
>> SCTP running naked over IP would still have its own ports.
>> If that ran over a path with a NAPT, then I could see why the NAPT might
>> want to do the same as it does with UDP and TCP, and so replace
>> addr/port pairs to minimize addr usage. (That's if the NAPT supported
>> SCTP at all - I  gather most don't.)
> I am not aware of any shipping NAPT that supports SCTP.
>> But with SCTP over DTLS over UDP, there is a UDP port, and then
>> presumably a separate SCTP port carried in the SCTP protocol within the
>> UDP message.
> Right.
> And the new SCTP_REMOTE_UDP_ENCAPS_PORT socket option has some
> relationship, but I do not understand how it works.  Reference
> draft-ietf-tsvwg-sctp-udp-encaps.

1) draft-ietf-tsvwg-sctp-udp-encaps doesn't seem to cover SCTP over DTLS

2) I guess that would only apply for a kernel implementation of SCTP 
over UDP, accessed via the socket interface.

So I don't think it is relevant for the immediate future plans for user 
mode implementations over UDP.

>> An NAPT on the path would presumably be messing with the UDP port. Given
>> use of DTLS, the NAPT won't even be able to tell that SCTP is being
>> used, much less mess with the SCTP port.
> Right.
>>>> That of course depends on having a signaling mechanism to set it up.
>>> After the initial SCTP association is created, SCTP could be allowed
>>> to do its own thing (that is, chose to find and use other ports).
>> Here you are talking about finding and using other UDP addr/port pairs?
> Yes, for mobility.
>> That is explicitly excluded in the DTLS/SCTP mapping.
> I am thinking about where to layer mobility and multipath for RTP
> (MPRTP) and for SCTP.  Do we do that with MICE
> (draft-wing-mmusic-ice-mobility) or does SCTP do mobility itself?  If
> we do it with MICE, we need to disable or prevent SCTP from adding
> / removing interfaces itself, which is why SCTP includes its own
> ability to signal IP addresses and ports in SCTP itself.

OK. That will require extensions here and there over what drafts 
currently say.


> -d
>> 	Thanks,
>> 	Paul
>>> SCTP's behavior in this regard is similar to MPRTP (multipath RTP),
>>> but of course they are not identical.
>>>>> to be clear: at moment WebRTC allows only one SCTP association per
>>>>> PC, so this is something that would be nice to define just to be
>>>>> ready for the future.
>>>> AFAIK WebRTC is just one possible user of this mechanism. The SDP
>>>> mechanism shouldn't be limited by the constraints of WebRTC. It would
>>>> be very difficult to define the SDP so that it was impossible to set
>>>> up multiple SCTP associations over different 5-tuples.
>>>>>> Then the RTP traffic can be demuxed based on SSRC, and SCTP traffic
>>>>>> can be demuxed based on SCTP port. And once the traffic for a
>>>>>> single SCTP port is identified, it can be demuxed based on stream
>> number.
>>>>>> Representing this in SDP is a challenge. Some variant of the bundle
>>>>>> proposal might allow bundling together several RTP m-lines and some
>>>>>> DTLS/SCTP m-lines. This would require a mechanism for specifying
>>>>>> the SCTP port number - already an open issue (#3) in
>>>>>> draft-ietf-mmusic-sctp-sdp-02.
>>>>> I agree that it is a challange how then to bundle everything
>>>>> together
>>>> But it is a challenge that needs to be tackled if we are to realize
>>>> Harald's dream.
>>> -d