Re: [MMUSIC] Single SCTP usage per SDP session?

[Christer Holmberg <[e-mail]>]

-----Original Message-----
From: Makaraju, Maridi Raju (Raju) [mailto:[e-mail]] 
Sent: 26 November 2014 17:30
To: Christer Holmberg; Salvatore Loreto
Cc: [e-mail]
Subject: RE: [MMUSIC] Single SCTP usage per SDP session?


> 
> >>> Hopefully there are some SCTP experts in da hause that can clarify 
> >>> the
> following:
> >>>
> >>> Previously, in the SCTP-SDP discussions, we have agreed that for a 
> >>> given
> SCTP/SCTPoDTLS/DTLSoSCTP association, we will only allow a single 
> usage (e.g. a webrtc-datachannel).
> >>>
> >>> So, if one wants multiple usages, one needs to establish multiple
> associations, using multiple m- lines.
> >>>
> >>> BUT, according to RFC 4960, two SCTP endpoints MUST NOT have more 
> >>> than
> one SCTP association between them at any given time. Not exactly sure 
> why, but that is what the text says.
> >>>
> >>>      "SCTP association: A protocol relationship between SCTP endpoints,
> >>>                 composed of the two SCTP endpoints and protocol 
> >>> state
> information
> >>>                 including Verification Tags and the currently 
> >>> active set
> of
> >>>                 Transmission Sequence Numbers (TSNs), etc.  An
> association can be
> >>>                 uniquely identified by the transport addresses 
> >>> used by
> the
> >>>                 endpoints in the association.  Two SCTP endpoints 
> >>> MUST
> NOT have
> >>>                 more than one SCTP association between them at any 
> >>> given
> time."
> >>>
> >>> <Sal>
> >>> That is not a problem.
> >>> As it has also already suggested it is enough to use a different 
> >>> port
> number on one side.
> >>> </Sal>
> >>
> >> After discussing with an SCTP expert, my understanding is that it 
> >> is
> enough to have a unique 4-tuple for each SCTP association.
> >>
> >> So, that means that SDP can contain multiple m- lines describing an 
> >> SCTP
> association, as long as each use unique 4-tuples.
> >>
> >> However, afaik, that means that a BUNDLE group CANNOT contain 
> >> multiple
> SCTP associations, as they would all share the same 4-tuple.
> >>
> >>
> >>> <Sal>
> >>> note also that in
> >>> https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-dtls-encaps-06
> >>> we already have the following text that implies that is possible 
> >>> to have multiple SCTP associations between two endpoints
> >>>
> >>>  o  Multiple SCTP associations MAY be multiplexed over a single DTLS
> >>>     connection.  The SCTP port numbers are used for multiplexing and
> >>>     demultiplexing the SCTP associations carried over a single DTLS
> >>>     connection.
> >>
> >> Based on the one-SCTP-assocation-per-4-tuple assumption, isn't that 
> >> text
> wrong?
> >
> > <Sal>
> > the text is correct!
> > because it implies that different SCTP associations use different 
> > ports
> (i.e. each of them use an unique 4-tuples)
> >	-> "The SCTP port numbers are used for multiplexing and
> demultiplexing..."
> > </Sal>
> 
> Well, in case of SCTPoDTLS one could claim that the SCTP port is not 
> really part of the 4-tuple. But, if the tsvwg folks are ok to 
> multiplex multiple SCTP associations using a single UDP/TCP port, then 
> fine... I don't have any strong opinion - I just want to clarify :)
> 
> However, in the SCTP-SDP discussions in Honolulu it was agreed to only 
> allow a single SCTP association in the case of SCTPoDTLS (even if 
> draft-ietf- tsvwg-sctp-dtls-encaps allows multiple). The reason is 
> that you would otherwise have multiple m- lines with the same port 
> value (even if you don't use BUNDLE), as the port indicates the UDP/TCP port - not the SCTP port.

<Raju>
> Per my understanding, draft-ietf-tsvwg-sctp-dtls-encaps just talks about SCTP over DTLS and allowing multiple SCTP associations, which is perfectly fine.
> Then it is possible to come up with SCTP-SDP semantics to use that capability.
> One m= line allowing one SCTP over DTLS limit is fine. Using BUNDLE you can replicate same 4-tuple in multiple m= lines. Then there is only one DTLS association 
> established and multiple SCTP associations over that is possible (one per m= line).
> If BUNDLE is not used then I believe same 4-tuple on multiple m= lines are NOT possible. This is because, per my understanding, unlike TCP/native-SCTP used under non-
> ICE environments, in ICE-environments the TCP/UDP port specified is used both as client and server port for DTLS. 

Even with BUNDLE, you would have to use the same m= line port value from the beginning, which is not allowed. So, you basically would have to add the additional SCTPoDTLS m= lines once the usage of BUNDLE has been negotiated.

> I am not sure if draft-ietf-mmusic-sctp-sdp makes any distinction between use of ICE or not. I believe the semantics for port in m= line are different when ICE is used vs. ICE > is not used.
> - When ICE is used it is the client as well as the server port.
>-  When ICE is not used, the port is the server port and not the client port. For a=setup:active cases discard port 9 is used per RFC 4145, which draft-ietf-mmusic-sctp-sdp 
> refers.

Per the agreement in Honolulu, there will be no port 9 for SCTP, as the agreement was that both endpoints will initiate the SCTP association.

And, in order to prevent two separate SCTP associations to be established, the m= line port needs to indicate both the client and server port also without ICE.

Regards,

Christer