Subject: [rtcweb] JSEP-02 Comments

From: Christer Holmberg <[email-masked]>
Date: Thu, 25 Oct 2012 13:50:46 +0000

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

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.

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.

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)

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.

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?

Regards,

Christer

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Fri, 26 Oct 2012 03:51:01 +0000

Thanks for the review and suggestions, inline …

> That is a rather fundamental change, so I think the change log should say a little more than "Clarified section on forking.".

agree

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

> 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 l…

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. 

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

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

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

> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 29 Oct 2012 12:44:03 +0000

Hi,
 
>> That is a rather fundamental change, so I think the change log should say a little more than "Clarified section on forking.".

And, do we have a WG concensus to remove cloning?

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

It's a use-case I'd like the API to support.

But, even without PRANSWER it would be tricky, as you have removed cloning.

Regards,

Christer

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 30 Oct 2012 14:02:30 +0100

> I saw that you have removed the text about cloning from version -02.

So is it already decided that local PeerConnection cloning will not exist?

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Parthasarathi R" <[email-masked]>
Date: Tue, 30 Oct 2012 23:47:56 +0530

Cullen,

PRANSWER open issue is related to JSEP State machine wherein PRANSWER state
could not handle OFFER event. Offer event in PRANSWER state is required for
the early-dialog UPDATE Offer and on the other hand, ANSWER event in
PRANSWER state is required by SIP serial forking. Also, the issue is not
related to signaling problem.  

Christer,

IIRC, cloning is removed as there is a consensus not to have parallel
forking in one of the earlier interim meeting.

Thanks
Partha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Christer Holmberg
Sent: Monday, October 29, 2012 6:14 PM
To: Cullen Jennings (fluffy)
Cc: [email-masked]
Subject: Re: [rtcweb] JSEP-02 Comments

Hi,
 
>> That is a rather fundamental change, so I think the change log should say
a little more than "Clarified section on forking.".

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

Regards,

Christer

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 30 Oct 2012 11:47:14 -0700

Partha said: 

"Christer,

Thanks
Partha"

[BA] Can you send a pointer to the consensus determination you are referring
to?  Also, I cannot find a consensus call on this subject sent to the RTCWEB
mailing list.   If in fact a consensus determination has been made (either
in IETF or W3C), can someone send a pointer to it?

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 30 Oct 2012 19:13:57 +0000

Hi,

There has been discussions about using cloning for SERIAL forking, because it would solve some issues.

Regards,

Christer 

-----Original Message-----
From: Bernard Aboba [mailto:[email-masked]] 
Sent: 30. lokakuuta 2012 20:47
To: 'Parthasarathi R'; Christer Holmberg
Cc: [email-masked]
Subject: RE: [rtcweb] JSEP-02 Comments

Partha said: 

"Christer,

IIRC, cloning is removed as there is a consensus not to have parallel forking in one of the earlier interim meeting.

Thanks
Partha"

[BA] Can you send a pointer to the consensus determination you are referring to?  Also, I cannot find a consensus call on this subject sent to the RTCWEB
mailing list.   If in fact a consensus determination has been made (either
in IETF or W3C), can someone send a pointer to it?

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 31 Oct 2012 11:42:20 +0100

> There has been discussions about using cloning for SERIAL forking, because it would solve some issues.

PRANSWER just solves a specific *SIP* usecase or need (but not all).

Cloning would solve all the related problems and would allow
implementing any kind of logic on top of WebRTC (including full SIP).

So IMHO PRANSWER looks like a hack introduced by SIP guys into WebRTC,
regardless it makes no sense at all in the WWW world.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Matthew Kaufman <[email-masked]>
Date: Wed, 31 Oct 2012 10:58:02 +0000

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Iñaki Baz Castillo
>

Well, since using SDP Offer/Answer as the API is a "hack introduced by SIP guys into WebRTC", I'm not at all surprised to see requirements for things like PRANSWER showing up.

Next you're going to wonder why a single RTCPeerConnection object represents open ICE sessions with RTP media flowing between this browser and *any number* of remote peers.

Matthew Kaufman

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 31 Oct 2012 12:13:18 +0100

> Well, since using SDP Offer/Answer as the API is a "hack introduced by SIP guys into WebRTC", I'm not at all surprised to see requirements for things like PRANSWER showing up.

Yes, I understand, but the real requirement for really respecting RFC
3264 was implementing cloning (see below please), instead of PRANSWER
which is a pseudo-hack for allowing some specific and existing use
cases of SIP (but not all).

If I make a call, receive two 183 with early media (different
early-dialogs), and want to render both audio streams locally, how to
do that with PRANSWER? Cloning was the key for that.

> Next you're going to wonder why a single RTCPeerConnection object represents open ICE sessions with RTP media flowing between this browser and *any number* of remote peers.

AFAIR the "cloning" proposal means that you end with N
RTCPeerConnection instances, each of them having media with a single
remote peer. The only they share is the same local SDP.

-- 
Iñaki Baz Castillo
<[email-masked]>