Re: [rtcweb] JSEP-04: Some comments on Section 5.2.1. and 5.2.2 (19th september)

[Christer Holmberg <[e-mail]>]

Hi Cullen,

>> Q_2:      o- line <sess-version> initial value - forking
>> 
>> When a new PeerConnection is created due to forking, the <sess-version> value must be based (incremented) on the value associated with the "mother" PeerConnection, for which the initial Offer of the whole communication session was created.
>
> uh, that is old text sorry. I'm proposing the principal that any time the SDP changes (including new candidate lines) the version gets larger. 

Yes. But keep in mind that this is an Offer created for a new PeerConnection. 


----------------

 
>> Q_4:      BUNDLE
>> 
>> The text says:
>> 
>> "If a m= section is not being bundled into another m= section, it MUST
>>                generate a unique set of ICE credentials and gather its own set of
>>                candidates.  Otherwise, it MUST use the same ICE credentials and
>>                candidates that were used in the m= section that it is being bundled
>>                into."
>> 
>> As, when BUNDLE is used, the initial Offer will contain identical ICE candidates, does that mean that we will also include identical address information in the initial Offer?
>
> no the initial offer will not have identical stuff other than on lines that "bundle-only" and we still need to add more text on this but idea is to make just like what is in united-plan

Regarding the details (usage of port zero etc) of "bundle-only", that is still something we have to agree upon. But, that discussion belongs to MMUSIC (and, I believe there is a thread about that already :)

But again, in the case of forking, when a new PeerConnection is created, I think we should allow identical stuff in the initial Offer of that PeerConnection. Because, the remote party has already indicated support of BUNDLE, in the Answer that was sent for the "mother" PeerConnection, so the initial Offer for the new PeerConnection will be the second Offer for the remote party.

At some point, we are going to have to add much more details about forking, in the case multiple PeerConnections are used. It is not enough to only say "create a new PeerConnection" :)


----------------


>> Section 5.2.2:
>> -----------------
>> 
>> 
>> Q_5:      Offer when in "local-offer"
>> 
>> The text says:
>> 
>> "If the initial offer was applied using setLocalDescription, but an
>>                answer from the remote side has not yet been applied, meaning the
>>                PeerConnection is still in the "local-offer" state, the steps for
>>                generating an initial offer should be followed,"
>> 
>> I don't understand this. Why would you create a new Offer while you are waiting for an Answer to the previously sent Offer?
>
> Justin has asked for this in the case when the offer has not been sent to anyone else. This is not going to be useful for typical systems trying to have SIP or Jingle compatible flow but who knows ...

Again, we have consensus to base JSEP on 3264. And, if we are going to deviate from 3264, I'd like to have some discussion and justification for that. 

I'd also have a section somewhere which summarizes *all* 3264 deviations that JSEP makes.


Regards,

Christer