Re: [rtcweb] JSEP-02 Comments

Thanks for the review and suggestions, inline …

On Oct 25, 2012, at 7:50 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

>  
> Hi,
>  
> Some comments on JSEP-02.
>  
>  
> Q1: Cloning
>  
> I saw that you have removed the text about cloning from version -02.
>  
> That is a rather fundamental change, so I think the change log should say a little more than "Clarified section on forking.".

agree

>  
>  
> Q2: Gone to W3C
>  
> In the change log you say "Removed stuff that has moved to W3C specificaiton". I think it would be good with a least some key words on exactly what has been moved.
>  
> I know I can do a diff with the previous version, but as one of the issues have been what belongs to IETF and what belongs to W3C I don't think I should have to do that.

fair enough - to be honest, we ran out of time on some of this. You will notice the draft went in seconds before the deadline and the references are also woefully inadequate. 

>  
>  
> Q3: Subsequent offer
>  
> The text says:
>        
>         "In [RFC3264], the constraints at the signaling level is that only one
>          offer can be outstanding for a given session but from the media stack
>          level, a new offer can be generated at any point.  For example, when
>          using SIP for signaling, if one offer is sent, then cancelled using a
>          SIP CANCEL, another offer can be generated even though no answer was
>          received for the first offer.  To support this, the JSEP media layer
>          can provide an offer whenever the Javascript application needs one
>          for the signaling.  The answerer can send back zero or more
>          provisional answers, and finally end the offer-answer exchange by
>          sending a final answer."
>  
> This is one of the issues previously discussed, but IF we want support generating a new offer while the previous one is still pending, then you need to state that only answers associated with the latest offer are provided back to the browser.

I agree with what you are saying but I think it gets a little more complicated once we include the roll back. I hope to get the roll back in the next version but yes, agree with this along with some exceptions to it when doing roll back. 

>  
>  
> Q4: Remove offer
>  
> This is related to the PRANSWER issue.
>  
> Unless I've missed it, the draft does not address the issue raised on the list, where an offer is received from the remote peer while in PRANSWER state.
>  
> (If you solved it on the list, I applogize for not having read it. I've had a flu the whole week, so I am a little behind with my e-mails)]

that's a signaling problem. I doubt the draft should address it any more than there are a few ways of dealing with it and Javascript can do whatever it wants to choose which one it wants. 

>  
>  
> Q5: Trickle ICE
>  
> Don't get me wrong - I support the work on trickle ICE :) '
>  
> BUT, the trickle ICE draft is still "fresh from the owen", so I suggest to e.g. add a note which says that the mechanism has still not been adopted, and that people need to be aware that things may change. It may be clear to people in IETF, but maybe not to others.
>  

agree - (actually, I think the ICE draft is still getting ready to go in the oven :-)

>  
>  
> Q6: ROAP
>  
> Section A.1.1 shows a call flow example with ROAP.
>  
> The latest version of draft-jennings-roap expired in may. Are we going to continue the work on ROAP?
>  

I really have no idea. At first I thought I should take this out. Then I wanted to show something that mapped to another signaling protocol. This should probably go, but something should be put there to help illustrate this type of flow. 

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