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

[Paul Kyzivat <[e-mail]>]

On 11/25/14 2:13 PM, Christer Holmberg wrote:
> Hi Paul,
>
> My question was not about multihoming, about the fact that an SCTP
> endpoint is only allowed to create a single association, which would
> mean that we could only have one SCTP usage per SDP session.

I know your question wasn't about multihoming. I brought it up because 
of an inference on my part that the restriction you reference is 
probably related to multihoming - that different addresses will be bound 
to the same association rather than to different ones. That assumes 
there is isn't any way to distinguish the differing usages and allow 
them to coexist in some sensible way.

> ...unless, "SCTP device" is bound to a specific address:port, in which
> case an SDP body could contain multiple SCTP associations - at least if
> they were un-bundled. Within a BUNDLE group, however, it would mean that
> only one SCTP association is allowed.

In a bundle group, with SCTPoDTLS, ISTM you could have multiple SCTP 
associations, each on a distinct SCTP port. I don't see any ambiguity 
there. But it will require added specification of how bundle works in 
that case. Clearly they won't be multihomed - SCTPoDTLS can't be.

	Thanks,
	Paul

> Regards,
>
> Christer
>
>
> Sent from my Windows Phone
> ------------------------------------------------------------------------
> From: Paul Kyzivat <mailto:[e-mail]>
> Sent: ‎25/‎11/‎2014 21:05
> To: [e-mail] <mailto:[e-mail]>
> Subject: Re: [MMUSIC] Single SCTP usage per SDP session?
>
> I've been trying to follow this thread, without much success. But I
> hadn't seen much said that seemed to be authoritative about SCTP until I
> got to this message. But without going to study 4960 I don't find the
> quote below to be very enlightening either.
>
> It does seem like it must be important to identify exactly what an SCTP
> endpoint is. It may well be that an SDP offerer or answerer might be
> allowed to be managing multiple SCTP endpoints.
>
> I will guess that the constraint Christer is asking about has something
> to do with multihomed SCTP associations, and the need to recognize that
> all of those are tied together. I don't know how that is expected to be
> done in SDP, if at all. I don't see any way within SDP to explicitly
> identify multiple IP address/port combinations for the same SCTP
> association. Perhaps if the c-line has a DNS name, and that can be
> resolved to multiple IP addresses?
>
> ISTM that, absent some additional bundle extensions, every SCTP m-line
> in an SDP offer/answer should be considered to be bound to a separate
> SCTP association.
>
>          Thanks,
>          Paul
>
> On 11/25/14 9:26 AM, Schwarz, Albrecht (Albrecht) wrote:
>> To SCTP (RFC 4960), - and without consideration of SCTP protocol object
>> represenation in SDP:
>>
>> RFC 4960 defines actually /(SCTP)-transport-connection-endpoints/ (using
>> OSI-BRM terminology), equated as SCTP endpoint.
>>
>> Whereas an /(SCTP)-endpoint/ usually relates to the /SCTP protocol
>> implementation/ in an open system (terminal, gateway, etc).
>>
>> An (SCTP)-endpoint is always able to /instantiate multiple
>> (SCTP)-connection-endpoint/ or /(SCTP)-transport-connection-endpoint
>> objects/ (given that the open systems provides multihomed IP host support).
>>
>> Hence, there’s a 1:N relation between (SCTP)-endpoint and
>> (SCTP)-(transport)-connection-endpoints.
>>
>> Consequently, an SDP media description ( c/m lines) indicates an
>> (SCTP)-transport-connection-endpoint object, but not an (SCTP)-endpoint.
>>
>> Fairly precise and clear in OSI-BRM terms (but you might be in trouble
>> if you equate both).
>>
>> -Albrecht
>>
>> *From:*mmusic [mailto:[e-mail]] *On Behalf Of *Christer
>> Holmberg
>> *Sent:* Dienstag, 25. November 2014 15:04
>> *To:* Makaraju, Maridi Raju (Raju); [e-mail]
>> *Subject:* Re: [MMUSIC] Single SCTP usage per SDP session?
>>
>> Hi,
>>
>> /<Christer> This was discussed in Honolulu, and the agreement was that the setup attribute will NOT be used to determine who initiates the SCTP association. Instead BOTH endpoints are supposed to trigger the initiation. The setup attribute will only be used  to determine the TLS role./
>>
>> */<Raju2>/*
>>
>> /2 use cases:/
>>
>> /1.SCTP over DTLS: For this yes, a=setup is for DTLS./
>>
>> /   The sctp port usage needs be clarified indicating it is the server port, not the client port./
>>
>> /  /
>>
>> /<Christer2> Yes./
>>
>> /  /
>>
>> /  /
>>
>> /2.Native SCTP: I believe a=setup is for SCTP association./
>>
>> /When a=setup:passive/actpass is used the sctp port usage needs to be clarified indicating it is the server port. When a=setup:active is used port must be 9 (discard port). This needs clarification as well./
>>
>> /Both sides trying to open SCTP simultaneously is probably ok because SCTP allows them to be converted into single association if there are simultaneous INITs (or INIT chunk received in ESTABLISHED state) on the same 4-tuple. This is per RFC 4960 section5.2.1<http://tools.ietf.org/html/rfc4960#section-5.2.1>  and5.2.2
> <http://tools.ietf.org/html/rfc4960#section-5.2.2>  ./
>>
>> /But the key here is same 4-tuple, which means the client must use same **server port** to initiate an outgoing association. If this is not done then, the end result will be 2 SCTP associations setup and/or one of them may be rejected and may depend on implementation./
>>
>> /So, I believe some clarifications are needed in this area./
>>
>> /  /
>>
>> /<Christer2> So, assuming we don’t use (per the agreement in Honolulu) a=setup for the SCTP association, we would need to mandate (or, at least say SHOULD) usage of the server port also to initiate an outgoing association, in order to avoid 2 SCTP associations./
>>
>> /  /
>>
>> /But, that also applies to SCTP over DTLS, doesn’t it?/
>>
>> */<Raju3>/*
>>
>> */Sorry, it actually ONLY applies to SCTP over DTLS. I misplaced the above description under “native SCTP” instead of “SCTP over DTLS”. For native SCTP, as discussed, a=setup negotiation determines which side initiates SCTP association, so the semantics are  very clear here./*
>>
>> */  /*
>>
>> /<Christer3> The idea was to not use a=setup for any “type” of SCTP, including native SCTP./
>>
>> /  /
>>
>> /Regards,/
>>
>> /  /
>>
>> /Christer/
>>
>>
>>
>> _______________________________________________
>> mmusic mailing list
>> [e-mail]
>>https://www.ietf.org/mailman/listinfo/mmusic
>>
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic