Re: [rtcweb] Lower-overhead protocol variations

[Harald Alvestrand <[e-mail]>]

On 02/28/2013 09:48 AM, Salvatore Loreto wrote:
> 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

You have to change the reference to RFC 4145, stating that active/active 
is a possible configuration - if someone gets a=active in an offer, it 
is OK to reply with a=active in the answer.

If you don't do that, the reference to RFC 4145 says that this is illegal.

       Harald