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

Good points - proposed resolutions inline …

On Sep 19, 2013, at 3:08 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

> Hi,
> 
> Section 5.2.1:
> -----------------
> 
> Q_1:      o- line <sess-version> initial value - deviation
> 
> What is the reason for recommending a <sess-version> zero value in the initial Offer, when the RFC says SHOULD use an NTP format timestamp?
> 
> I don’t have any strong feelings, but in general: whenever we deviate from the “base” SDP procedures I think we should justify why.

Lets use NTP 

> 
> 
> 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. 

> 
> 
> Q_3:      RTP
> 
> The text says:
> 
> “The <proto> field MUST be set to "RTP/SAVPF". “
> 
> But, that of course only applies to RTP based streams (not the data channel). Also, in general, it needs to be clear what information needs to be in every m- line, and what information is protocol specific. I would suggest to have a “General” sub-section, a “RTP” sub-section, etc.

Yep - I think this should be offers are created with RTP/SAVPF for audio and video and system can reeve offers with SAVPF or SAVP
> 
> 
> 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

> 
> I don’t object to that – I just want to clarify, as it has impacts on the text in the BUNDLE spec :)
> 
> 
> 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 …

> 
> Also, when setRemote() is called, to which Offer does it apply?

The most recent one. And the JS app would have to make sure it passed the write one or you run high odds of getting completely broken behavior. 

> 
> 
> Q_6:      BUNDLE
> 
> We’ll probably also need some text about BUNDLE.
> 

yep - but plan is to match up with unified plan 

> 
> Regards,
> 
> Christer
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb