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

["Makaraju, Maridi Raju (Raju)" <[e-mail]>]

> Hi,
> 
> >> 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.
> >
> > <Raju>
> > You are right. Section 8.2.1 of draft-ietf-mmusic-sdp-bundle-negotiation
> > says the m= line should have unique 4-tuple to allow possibility of BUNDLE
> rejection. Very valid.
> > However, to facilitate multiple SCTP over same bundled SCTP, won't the
> following work?
> > - Offerer adds one m= line for each SCTP association needed.
> > - If the answerer selects BUNDLE then all the SCTP m= lines now map
> >  and use the same DTLS association.
> > - If the answerer does not accept BUNDLE then we don't have the option
> >  of negotiating multiple SCTPs over same DTLS anyway; so it will result
> >  in multiple DTLS, which still gives you a way to get multiple SCTPs.
> >
> > With this approach a new subsequent SDP offer is not needed to add SCTP m=
> lines.
> > </Raju>
> 
> Correct.
> 
> But, still, without BUNDLE you will only be able to negotiate a single SCTP
> association per DTLS connection.

<Raju>
This is also apparent from the fact that only one a=sctp-port allowed per m= line.
Mandating the use of BUNDLE to allow multiple SCTP associations seems reasonable to me.
</Raju>

> 
> >>> 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.
> >
> > <Raju>
> > So, these 2 clarifications are needed in draft-ietf-mmusic-sctp-sdp as it
> deviates from referred RFC 4145.
> > </Raju>
> 
> Yes, it will be covered in the next version.
> 
> But, I also want to be sure that people are ok with such approach. So, if
> someone thinks we should use the setup attribute to negotiate which endpoint
> initiates the SCTP association, please speak up now :)

<Raju>
I see that the NAT traversal as a big advantage of both peers attempt to open SCTP association. SCTP INIT chunk will punch holes in NAT box which will then allows incoming INIT CHUNK or INT ACK. All this is possible because SCTP RFC http://tools.ietf.org/html/rfc4960#section-5.2.1 allows such INIT collisions and converts them into a single SCTP association; however the 4-tuple (+additional IPs) should match though.
This is the issue with a=setup usage for TCP and SDP descriptions (without ICE) specifying only the server port; though TCP allows simultaneous open, per a=setup only one side can initiate TCP conn which will not punch a hole in other end's NAT and results in TCP SYN being dropped. 

How about the concern of NATs and hosts not supporting simultaneous SCTP open? there by limiting the success rate?
Similar concerns were voiced here at http://tools.ietf.org/html/rfc6544#appendix-A for TCP.

</Raju>

BR
Raju