Re: [rtcweb] Lower-overhead protocol variations

[Salvatore Loreto <[e-mail]>]

On 2/27/13 8:32 PM, Michael Tuexen wrote:
>
> Not sure we can choose based on SCTP. The port numbers can be the same and we have no addresses
> available. Maybe we can use the client/server identity from DTLS (the DTLS client uses even,
> the DTLS server uses odd).
>>>>>> The MMUSIC SCTP draft (draft-ietf-mmusic-sctp-sdp-03.txt) says:
>>>>>>
>>>>>> 6.  The Setup and Connection Attributes and Association Management
>>>>>>
>>>>>>    The use of the 'setup' and 'connection' attributes in the context of
>>>>>>    an SCTP association is identical to the use of these attributes in
>>>>>>    the context of a TCP connection.  That is, SCTP endpoints MUST follow
>>>>>>    the rules in Sections 4 and 5 of RFC 4145 [RFC4145] when it comes to
>>>>>>    the use of the 'setup' and 'connection' attributes in offer/answer
>>>>>>    [RFC3264] exchanges.
>>>>>>
>>>>>> The relevant table from section 4 of RFC 4145 is:
>>>>>>
>>>>>>            Offer      Answer
>>>>>>             ________________
>>>>>>             active     passive / holdconn
>>>>>>             passive    active / holdconn
>>>>>>             actpass    active / passive / holdconn
>>>>>>             holdconn   holdconn
>>>>>>
>>>>>> I think that based on RFC 4145, it would be reasonable to say that the party in the "active" role uses the even channels and the party in the "passive" role uses the odd channels, and that if the initiator uses "actpass", no channel assignment can be made until the answer comes back as either "active" or "passive".
>>>>> OK. I was writing the statement based on how things are currently implemented
>>>>> in Firefox. Both side are the active side...
>>>>>
>>>>> Thanks for the clarification.
>>>> That confuses me ... do both sides send INIT (RFC 4960 section 5.1 step A)?
>>> Yes...
>>>> Collision is described in section 5.2.1 section B - I guess that if that's something that makes sense to provoke on a regular basis, "both active" can make sense.
>>> Yes, SCTP handles INIT collisions. In API terms: Bots call connect() (using the 1to1 style API).
>>> This is possible, since both sides know the port number of the peer.
>> thanks for the clarification Michael.
>>
>> just to be clear before I do any changes in the The MMUSIC SCTP draft,
>> is this something always true? (i.e. implementation independent)
> No. It is how it is currently handled in Firefox. If i remember it correctly,
> ekr preferred a symmetric solution. So he hasn't to figure out which side
> is active and which side is passive. Could be related to the fact, the Firefox
> currently doesn't use SDP for the data channels (if I remember it correctly).
>> even if I haven't checked I am not sure it is true also for the "1 to many" model...
>> and that make me cautious on doing any changes unless we do not restrict the scope of
>> the draft to 1to1 style
> INIT collision is also handled by 1-to-1 style sockets.
thanks for the answer Michael,
so for the time being it seems that I don't need to do any modification 
to the draft-ietf-mmusic-sctp-sdp draft
about the active/passive role

however I would like to hear more comments from people on this aspect:
i.e. the Active/Passive role

cheers
/Salvatore
>
> Best regards
> Michael
>> br
>> /Salvatore
>>
>>
>>> Best regards
>>> Michael
>>>> draft-ietf-mmusic-sctp-sdp needs to be updated with this possibility.
>>>>>> This, of course, implies that channel numbers are reassigned from a blank slate if the connection goes down and is reestablished with new values for active and passive. Probably one should say that if the connection goes down, all channels go down too - that the data channel system doesn't attempt to layer yet another layer of reconnection on top of the already existing ones.
>>>>>>
>>>>>>                    Harald
>>>>>>
>>>>>>
>>


-- 
Salvatore Loreto, PhD
www.sloreto.com