Subject: [rtcweb] Agenda requests for Atlanta meeting

From: Magnus Westerlund <[email-masked]>
Date: Tue, 2 Oct 2012 17:08:23 +0200

WG,

We chairs like to have input into what you see should be on the Agenda
for our two meeting slots in Atlanta. Both document editors/authors and
participant are welcome to request or inform the WG or the chairs only
about issues that needs to be discussed in the meeting.

Two items we chairs believe should be on the agenda are:

- Video codec selection
- JSEP

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Thu, 4 Oct 2012 15:44:04 +0000

With my individual contributor hat on …

Justin and I would like to have some time for JSEP. I think there are a bunch of issues, particularly around the use of SDP and timing of various things that need discussion. 

Thanks, Cullen

On Oct 2, 2012, at 9:08 AM, Magnus Westerlund <[email-masked]> wrote:

> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 8 Oct 2012 11:47:20 +0200

Hi,

I would like to discuss the different alternatives in order to support forking, e.g. whether we use cloning, whether we simply set additional local descriptor, and whether we can get rid of PRANSWER.

As it is related to JSEP and SDP, I guess it should be part of the JSEP discussion. I am willing to help with material.

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Cullen Jennings (fluffy)
Sent: 4. lokakuuta 2012 18:44
To: [email-masked]
Subject: Re: [rtcweb] Agenda requests for Atlanta meeting

With my individual contributor hat on .

Thanks, Cullen

On Oct 2, 2012, at 9:08 AM, Magnus Westerlund <[email-masked]> wrote:

> for our two meeting slots in Atlanta. Both document editors/authors 
> and participant are welcome to request or inform the WG or the chairs 
> only about issues that needs to be discussed in the meeting.
>

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Mon, 8 Oct 2012 22:52:54 +0000

> I would like to discuss the different alternatives in order to support forking, e.g. whether we use cloning, whether we simply set additional local descriptor, and whether we can get rid of PRANSWE…

Seriously? we have discussed this so many times and always come to the same conclusion. I have not seen anything on the list that suggests why we need to remove this or how mapping to SIP 180 with sequential forking is going to work without it. It also has other important uses. There are a bunch of changes that are needed to the JSEP draft to remove some of the inconsistencies in this and clarify some parts but I'd rather wait till we had that updated before we got into a whole discussion about exploding it yet again. 

Why don't we have a phone call to try and outline what the problems you are trying to solve that the current solution does not work for then figure out how much we want to explode this. 

I'll note that current clone text has lots of "miracles happen here, insert supper fluffy hand wave" in it and plenty of weasel room on failure to allocate required resources on the clone. It's more or less a sketch of an idea at this point. I'm perfectly happy to see people try and sort out the details on clone but using it explode the consensus we have come to around PRANSWER seems like a really bad idea at this point. 

Cullen

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Mon, 8 Oct 2012 22:53:05 +0000

Cullen

---

From: Roman Shpount <[email-masked]>
Date: Mon, 8 Oct 2012 18:58:55 -0400

Cullen,

I have an existing interop problem with SIP serial forking that I cannot
solve with the proposed schema. With PRANSWER, how would I handle SIP
UPDATE sith SDP received in early dialog?

Regards,
_____________
Roman Shpount

On Mon, Oct 8, 2012 at 6:53 PM, Cullen Jennings (fluffy)
<[email-masked]>wrote:

> > I would like to discuss the different alternatives in order to support
> forking, e.g. whether we use cloning, whether we simply set additional
> local descriptor, and whether we can get rid of PRANSWER.
>
> Seriously? we have discussed this so many times and always come to the
> same conclusion. I have not seen anything on the list that suggests why we
> need to remove this or how mapping to SIP 180 with sequential forking is
> going to work without it. It also has other important uses. There are a
> bunch of changes that are needed to the JSEP draft to remove some of the
> inconsistencies in this and clarify some parts but I'd rather wait till we
> had that updated before we got into a whole discussion about exploding it
> yet again.
>
> Why don't we have a phone call to try and outline what the problems you
> are trying to solve that the current solution does not work for then figure
> out how much we want to explode this.
>
> I'll note that current clone text has lots of "miracles happen here,
> insert supper fluffy hand wave" in it and plenty of weasel room on failure
> to allocate required resources on the clone. It's more or less a sketch of
> an idea at this point. I'm perfectly happy to see people try and sort out
> the details on clone but using it explode the consensus we have come to
> around PRANSWER seems like a really bad idea at this point.
>
> Cullen
>

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 8 Oct 2012 16:00:58 -0700

I would attend such a phone call if it were held.

My immediate reaction is that from an implementor's perspective. PRANSWER
is a lot easier to address than cloning. I feel like cloning pulls in a lot of
difficult lifetime and ownership semantics. By contrast, supporting PRANSWER
is very easy. Before deciding that cloning is the answer I'd like to see two
things:

1. A clear set of use cases that shows what cloning does well that PRANSWER
does not.
2. A fairly complete defn of the clone semantics.

Otherwise I worry that we'll detour to cloning and then only after 6 months
discover it doesn't work.

Best,
-Ekr

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 8 Oct 2012 16:09:29 -0700

Walk me through what the call flow would like it both endpoints were SIP UA's so I understand it better. 

Note - I'm not against folks trying to figure out clone. I'm saying that we should not get rid of PRANSWER.

On Oct 8, 2012, at 15:58 , Roman Shpount <[email-masked]> wrote:

> Cullen,
> 
> I have an existing interop problem with SIP serial forking that I cannot solve with the proposed schema. With PRANSWER, how would I handle SIP UPDATE sith SDP received in early dialog?
> 
> Regards,
> _____________
> Roman Shpount
> 
> 
> On Mon, Oct 8, 2012 at 6:53 PM, Cullen Jennings (fluffy) <[email-masked]> wrote:
>

---

From: Roman Shpount <[email-masked]>
Date: Mon, 8 Oct 2012 19:21:53 -0400

The scenario is:

WebRTC is placing a call through some sort of gateway to a SIP end point.
It sends an offer that gets translated into INVITE with SDP. SIP end point
sends back 183 with SDP that gets delivered to the WebRTC end point as
PRANSWER. Then SIP end point sends an UPDATE with SDP in early dialog. And
then finally SIP end point sends 200 OK with different SDP. I am not sure
how to translate the SDP in UPDATE and the final answer in WebRTC API
calls. I would guess this is not something that can be supported without
cloning.
_____________
Roman Shpount

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Tue, 9 Oct 2012 00:42:48 +0000

Check out text from RFC 3311 that says 

      o  If the UPDATE is being sent before the completion of the INVITE
         transaction, and the initial INVITE contained an offer, the
         UPDATE cannot be sent with an offer unless the callee has
         generated an answer in a reliable provisional response, has
         received a PRACK for that reliable provisional response, has
         not received any requests (PRACK or UPDATE) with offers that it
         has not answered, and has not sent any UPDATE requests
         containing offers that have not been answered.

So the 183 would be need to be sent reliably at which case I would expect the gateways to map it to a final offer in RTCWeb not a provisional one. At that point when the update comes along with an offer, it just mapped to RTCweb offer. 

On Oct 8, 2012, at 16:21 , Roman Shpount <[email-masked]>
 wrote:

> The scenario is:
> 
> WebRTC is placing a call through some sort of gateway to a SIP end point. It sends an offer that gets translated into INVITE with SDP. SIP end point sends back 183 with SDP that gets delivered to the WebRTC end point as PRANSWER. Then SIP end point sends an UPDATE with SDP in early dialog. And then finally SIP end point sends 200 OK with different SDP. I am not sure how to translate the SDP in UPDATE and the final answer in WebRTC API calls. I would guess this is not something that can be supported without cloning.
> _____________
> Roman Shpount
> 
>

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 8 Oct 2012 17:47:37 -0700

One other thought on this. I think this just points out that it would be really nice to have a draft that showed how to build a RTCWeb / SIP gateway.

---

From: Roman Shpount <[email-masked]>
Date: Mon, 8 Oct 2012 21:24:06 -0400

On Mon, Oct 8, 2012 at 8:42 PM, Cullen Jennings (fluffy)
<[email-masked]>wrote:

> So the 183 would be need to be sent reliably at which case I would expect
> the gateways to map it to a final offer in RTCWeb not a provisional one. At
> that point when the update comes along with an offer, it just mapped to
> RTCweb offer.
>
>
And what happens with the next 183 or 200 OK sent reliably in a different
dialog? When we are dealing with serial forking we are dealing with
different sequential dialogs created by the same offer, aren't we?
Otherwise this is not really standard compliant.
_____________
Roman Shpount

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Tue, 9 Oct 2012 01:26:50 +0000

Well, what's the end user experience you're trying to achieve  - lets say we are talking about audio. Do you want to play the first one or the last one? If you want to bridge them into a party line, this is probably not how you want the SIP side to happen. 

On Oct 8, 2012, at 18:24 , Roman Shpount <[email-masked]>
 wrote:

> 
> 
> On Mon, Oct 8, 2012 at 8:42 PM, Cullen Jennings (fluffy) <[email-masked]> wrote:
> 
> And what happens with the next 183 or 200 OK sent reliably in a different dialog? When we are dealing with serial forking we are dealing with different sequential dialogs created by the same offer, aren't we? Otherwise this is not really standard compliant. 
> _____________
> Roman Shpount
> 
>

---

From: Roman Shpount <[email-masked]>
Date: Mon, 8 Oct 2012 21:31:52 -0400

On Mon, Oct 8, 2012 at 9:26 PM, Cullen Jennings (fluffy)
<[email-masked]>wrote:

>
> Well, what's the end user experience you're trying to achieve  - lets say
> we are talking about audio. Do you want to play the first one or the last
> one? If you want to bridge them into a party line, this is probably not how
> you want the SIP side to happen.
>
>
This is still serial forking. Imagine the following scenario: You are
calling a phone number, you dial first provider who starts playing a dial
tone then uses an UPDATE to connect you to a media server to play an
announcement after which your call goes to voice mail (another dialog and
another SDP). This is all fairly legal and not unusual for SIP scenarios.
Nothing to do with party lines.
_____________
Roman Shpount

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 8 Oct 2012 18:41:34 -0700

On Oct 8, 2012, at 18:31 , Roman Shpount <[email-masked]> wrote:

> On Mon, Oct 8, 2012 at 9:26 PM, Cullen Jennings (fluffy) <[email-masked]> wrote:
> 
> This is still serial forking. Imagine the following scenario: You are calling a phone number, you dial first provider who starts playing a dial tone then uses an UPDATE to connect you to a media server to play an announcement after which your call goes to voice mail (another dialog and another SDP). This is all fairly legal and not unusual for SIP scenarios. Nothing to do with party lines.
> _____________
> Roman Shpount
> 

Ok, serial forking with early media seems like it should work. Seems like the browser would make the offer, that gateway turned into SIP invite that then went to sequential forking proxy that send sent the invite to UA A. UA A returns a 180 that gets mapped to PRANSWER, the proxy then forks to UA B that sends a 200 on a different dialog that gets mapped to answer.

---

From: Roman Shpount <[email-masked]>
Date: Mon, 8 Oct 2012 21:56:27 -0400

On Mon, Oct 8, 2012 at 9:41 PM, Cullen Jennings <[email-masked]> wrote:

> > Well, what's the end user experience you're trying to achieve  - lets
> say we are talking about audio. Do you want to play the first one or the
> last one? If you want to bridge them into a party line, this is probably
> not how you want the SIP side to happen.
> >
> >
> Ok, serial forking with early media seems like it should work. Seems like
> the browser would make the offer, that gateway turned into SIP invite that
> then went to sequential forking proxy that send sent the invite to UA A. UA
> A returns a 180 that gets mapped to PRANSWER, the proxy then forks to UA B
> that sends a 200 on a different dialog that gets mapped to answer.

 The only issue is the there is currently no way to map an UPDATE received
in the early dialog to WebRTC API calls. I am probably OK with it not being
handled until the cloning is implemented, but this shows that PRANSWER is
not very useful even for the serial forking.
_____________
Roman Shpount

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 8 Oct 2012 19:30:44 -0700

On Oct 8, 2012, at 18:56 , Roman Shpount <[email-masked]> wrote:

>  The only issue is the there is currently no way to map an UPDATE received in the early dialog to WebRTC API calls. I am probably OK with it not being handled until the cloning is implemented, but this shows that PRANSWER is not very useful even for the serial forking.
> 

How do you think this work in a SIP only system? Lets say A sends the invite with offer to proxy that forks to B. Then B does 180Rel followed by an update. Then the proxy forks to C on a new dialog. Do you think C can send send early media to A and A is actually going to play it? And what if B use still sending media - it that case A will be getting media from B and C at the same time. Do you have devices that do that?  Most people just seem to make voicemail work fine without needing to introduce this type of complexity. If you know what you want A to do in this case, I think we can figure out how to make that happen - there's been a lot of discussion about what a SIP device receiving early media from two places should do and there was never any really great answer other than don't do that.  

The meta issue here is thought this is serial forking at the signalling level in SIP, it is actually parallel forking from a SDP / media  point of view. 

The case that started this all was use UPDATE in awaited RFC says is not allowed. I'm not arguing there are not cases where clone would be useful, but I do think all the voicemail systems I am familiar with would work fine with the the simple PRANSWER.

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 9 Oct 2012 08:28:39 +0200

Hi Ekr,

>My immediate reaction is that from an implementor's perspective. PRANSWER is a lot easier to address than cloning. I feel like cloning pulls in a lot of difficult lifetime and ownership semantics. By contrast, supporting PRANSWER is very easy. Before >deciding that cloning is the answer I'd like to see two
>things:
>
>1. A clear set of use cases that shows what cloning does well that PRANSWER does not.
>Otherwise I worry that we'll detour to cloning and then only after 6 months discover it doesn't work.

Please note that JSEP-02 already supports cloning (the details on how it's done are missing, though).

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 9 Oct 2012 08:41:17 +0200

Hi,

> Seriously? we have discussed this so many times and always come to the same conclusion. I have not seen anything on the list that suggests why we need to remove this or how mapping to SIP 180 with sequential forking is going to work without it.

You CAN do serial forking also with cloning (or, as suggested by Martin, simply setting additional local descriptors).

I am not blindly suggesting to remove PRANSWER (I have been one of the defenders for having it). It's part of the more general "JSEP Offer/Answer Usage" issue, which we DO need to make sure we get right.

> It also has other important uses. There are a bunch of changes that are needed to the JSEP draft to remove some of the inconsistencies in this and clarify some parts but I'd rather wait till we had that updated before we got into a whole discussion about 
> exploding it yet again. 

I have no problem with that. But, again, we do need to get the JSEP O/A sorted out. My suggesting is still that the base should be RFC 3264, and if we need to "relax" things we should very carefully look at those cases.

> Why don't we have a phone call to try and outline what the problems you are trying to solve that the current solution does not work for then figure out how much we want to explode this. 

Sure. I'd attend such call.

Regards,

Christer

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Tue, 9 Oct 2012 14:16:49 +0000

> I am not blindly suggesting to remove PRANSWER (I have been one of the defenders for having it). It's part of the more general "JSEP Offer/Answer Usage" issue, which we DO need to make sure we get…

agree - sounds like we are on same page 

> I have no problem with that. But, again, we do need to get the JSEP O/A sorted out. My suggesting is still that the base should be RFC 3264, and if we need to "relax" things we should very carefull…

I have not seen any reason to relax 3264 yet but if something comes up, agree we should carefully look at the cases. I think we can just do straight up 3264. Arguments that SIP early media in a 180 is not compliant with 3264 are just wrong.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 9 Oct 2012 09:09:38 -0700

On 9 October 2012 07:16, Cullen Jennings (fluffy) <[email-masked]> wrote:
> I have not seen any reason to relax 3264 yet but if something comes up, agree we should carefully look at the cases. I think we can just do straight up 3264.

RFC 3264 doesn't describe PRANSWER.  The concept is entirely absent.

   The offerer MAY immediately cease listening for media formats that
   were listed in the initial offer, but not present in the answer.

"the" answer.

> Arguments that SIP early media in a 180 is not compliant with 3264 are just wrong.

I'd be pleased if you could find something concrete that supports
this, because I just re-read 3264 and I can't find anything supporting
your conclusion.

I have no problem with the idea of a well-established status quo that
does not conform to the documents.  That would be consistent with many
other RFCs.  However, if that is the case, perhaps someone could write
this behavior down so that we can use the same definitions.  Clearly,
that isn't happening right now.

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 9 Oct 2012 12:18:55 -0400

+1 to that idea.

Richard Shockey
Shockey Consulting
Chairman of the Board of Directors SIP Forum
<mailto:richard(at)shockey.us>
skype-linkedin-facebook: rshockey101
http//www.sipforum.org

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Cullen Jennings
Sent: Monday, October 08, 2012 8:48 PM
To: Roman Shpount
Cc: [email-masked]
Subject: Re: [rtcweb] Agenda requests for Atlanta meeting

One other thought on this. I think this just points out that it would be
really nice to have a draft that showed how to build a RTCWeb / SIP gateway.

It sends an offer that gets translated into INVITE with SDP. SIP end point
sends back 183 with SDP that gets delivered to the WebRTC end point as
PRANSWER. Then SIP end point sends an UPDATE with SDP in early dialog. And
then finally SIP end point sends 200 OK with different SDP. I am not sure
how to translate the SDP in UPDATE and the final answer in WebRTC API calls.
I would guess this is not something that can be supported without cloning.
solve with the proposed schema. With PRANSWER, how would I handle SIP UPDATE
sith SDP received in early dialog?
>>>> I would like to discuss the different alternatives in order to support
forking, e.g. whether we use cloning, whether we simply set additional local
descriptor, and whether we can get rid of PRANSWER.

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 9 Oct 2012 21:04:11 +0200

Hi,

>   were listed in the initial offer, but not present in the answer.

I agree with Martin. 3264 O/A is always per dialog, and forking is supported by generating multiple dialogs. JSEP, OTOH, in order to support forking with a single "dialog" (peerConnection local descriptor), now defines O/A as offer+any number of pranswers + answer.

So, we would e.g. have to define what happens if a new offer is received from the remote side while the browser is in pranswer-received state (see my call flow in another reply).

Regards,

Christer

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Tue, 9 Oct 2012 20:05:29 +0000

> So, we would e.g. have to define what happens if a new offer is received from the remote side while the browser is in pranswer-received state (see my call flow in another reply).

3264, SDP, 3261, and related documents are dealing with a bunch of things including what happens at media plane and signaling plane. 

I'll note that though O/A is per dialog, there is only one O shared across multiple legs and when you create the O you don't know how many dialogs there will be. So from the media point of view (covered more in SDP spec than 3264) there is one O with a bunch of A. From signaling point of view there are a bunch of O/A pairs). 

The dialog is SIP signaling concept not a media plane level concept. We moved the signaling part out of the browser and into the JS. But the media part is still in the browser. So as 3264 says, after the offer is constructed, we have to be willing to receive media for all the codec type in the offer. When we get the answer 3264 makes it clear that one MAY stop receiving the codecs that were in the offer but not selected in the answer. However, this can not be done until the signaling layer is sure that no more offers will be honored. Since that signalling part of Offer/Answer is in the JS, the API need to to have a way to signal what the MAY part should do and that is the PRANSWER vs ANSWER. 

People keep trying to make this some complex weird argument invoking the SIP deities of the past and quoting incomprehensible phrases from various RFC caved in stone but the bottom line in the code is very simple to understand. When creating the offer you alloced some resources ( like a port to receive video on ). When you get an answer that does not use that resource, you need to tell the media stack if it should free the resources or not. O/A has situation where you need to keep the resources available (like there are more dialogs coming) and situation where you need to free the resource.  Since we split the signalling out of the browser and left the media in the browser, we need be able to allow the JS that is dealing with signaling to tell the browser when to free the resource.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 9 Oct 2012 15:58:48 -0700

> The dialog is SIP signaling concept not a media plane level concept. We moved the signaling part out of the browser and into the JS. But the media part is still in the browser. So as 3264 says, aft…

That's a consistent and logical view.  It is not what RFC 3264 says.
It may even be the only reasonable solution.

> People keep trying to make this some complex weird argument invoking the SIP deities of the past and quoting incomprehensible phrases from various RFC caved in stone [...]

Quit beating around the bush: it's me you are talking about.

It's not a complex weird argument, it's this:
  PRANSWER is not described in RFC 3264.

draft-*-jsep might say something about it, but I'd have to guess about
what to do if I were to implement the feature and that doesn't help
with interoperation.

If there was text that described the above, plus the implications in
some detail (including what resources can be released as they relate
to the SDP), then we're good.  I don't even think that writing this is
especially hard. As it stands, the definition for cloning is on par
with the definition for PRANSWER.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 10 Oct 2012 10:03:30 +0200

Hi,

>> I agree with Martin. 3264 O/A is always per dialog, and forking is supported by generating multiple dialogs. JSEP, OTOH, in order to support forking with a 
>> single "dialog" (peerConnection local descriptor), now defines O/A as offer+any number of pranswers + answer.
>> 
> I'll note that though O/A is per dialog, there is only one O shared across multiple legs and when you create the O you don't know how many dialogs there will be.

The *initial* O is shared across multiple legs. Once a dialog has been created, O/A transactions on that leg will not affect other legs.

> So from the media point of view (covered more in SDP spec than 3264) there is one O with a bunch of A. From signaling point of view there are a bunch of O/A pairs). 
>
> The dialog is SIP signaling concept not a media plane level concept. We moved the signaling part out of the browser and into the JS. But the media part is still in the 
> browser. So as 3264 says, after the offer is constructed, we have to be willing to receive media for all the codec type in the offer. When we get the answer 3264 makes 
> it clear that one MAY stop receiving the codecs that were in the offer but not selected in the answer. However, this can not be done until the signaling layer is sure that 
> no more offers will be honored. Since that signalling part of Offer/Answer is in the JS, the API need to to have a way to signal what the MAY part should do and that is 
> the PRANSWER vs ANSWER. 
>
> People keep trying to make this some complex weird argument invoking the SIP deities of the past and quoting incomprehensible phrases from various RFC caved in 
> stone but the bottom line in the code is very simple to understand. When creating the offer you alloced some resources ( like a port to receive video on ). When you
> get an answer that does not use that resource, you need to tell the media stack if it should free the resources or not. O/A has situation where you need to keep the 
> resources available (like there are more dialogs coming) and situation where you need to free the resource.  Since we split the signalling out of the browser and left 
> the media in the browser, we need be able to allow the JS that is dealing with signaling to tell the browser when to free the resource. 

I don't know who "people" is, but at least I have only been talking about the O/A *signaling* :) Media is a separate issue.

Regards,

Christer

---

From: "Parthasarathi R" <[email-masked]>
Date: Thu, 11 Oct 2012 01:21:58 +0530

Cullen,

As signaling is moved to JS (application layer), Offer-answer in JSEP has to
be generic enough. The underlying assumption in PRANSWER state is that
webserver knows whether the received SDP from remote is PRANSWER or final
ANSWER. Unfortunately, Webserver may not able to tell whether the receive in
lot of real time deployment which is an open issue now. UPDATE offer after
18x answer from remote is the typical example where PRANSWER state breaks.
The real-time usage of SIP UPDATE offer is to update the existing answer in
18x in the same dialog. Early dialog UPDATE callflow is well deployment
because of PSTN remote ringback (18x) from media server and then UPDATE with
SDP to update the media information of remote endpoing and then, call
connect (200 ok) from actual endpoint. The same PSTN callflow shall be
achieved by serial forking as well. Please note that the final answer or not
is not based on browser or originating SIP UA but it is based on the
intermediate SIP entities. 

>From RTCWeb perspective, The new OFFER is possible to be received in browser
as per RFC 3264 after the first answer is received. PRANSWER is the new
state in JSEP wherein JSEP is the extension of RFC 3264. It will be good in
case you explain how browser in PRANSWER has to handle new OFFER from the
remote side. 

Please include me in case any phone discussion if you are planning.

Thanks
Partha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Cullen Jennings (fluffy)
Sent: Wednesday, October 10, 2012 1:35 AM
To: Christer Holmberg
Cc: [email-masked]
Subject: Re: [rtcweb] Agenda requests for Atlanta meeting

On Oct 9, 2012, at 12:04 , Christer Holmberg
<[email-masked]>
 wrote:

> Hi,
> 
>>> I have not seen any reason to relax 3264 yet but if something comes up,
agree we should carefully look at the cases. I think we can just do straight
up 3264.
> I agree with Martin. 3264 O/A is always per dialog, and forking is
supported by generating multiple dialogs. JSEP, OTOH, in order to support
forking with a single "dialog" (peerConnection local descriptor), now
defines O/A as offer+any number of pranswers + answer.
> 
> So, we would e.g. have to define what happens if a new offer is received
from the remote side while the browser is in pranswer-received state (see my
call flow in another reply).

3264, SDP, 3261, and related documents are dealing with a bunch of things
including what happens at media plane and signaling plane. 

I'll note that though O/A is per dialog, there is only one O shared across
multiple legs and when you create the O you don't know how many dialogs
there will be. So from the media point of view (covered more in SDP spec
than 3264) there is one O with a bunch of A. From signaling point of view
there are a bunch of O/A pairs). 

The dialog is SIP signaling concept not a media plane level concept. We
moved the signaling part out of the browser and into the JS. But the media
part is still in the browser. So as 3264 says, after the offer is
constructed, we have to be willing to receive media for all the codec type
in the offer. When we get the answer 3264 makes it clear that one MAY stop
receiving the codecs that were in the offer but not selected in the answer.
However, this can not be done until the signaling layer is sure that no more
offers will be honored. Since that signalling part of Offer/Answer is in the
JS, the API need to to have a way to signal what the MAY part should do and
that is the PRANSWER vs ANSWER. 

People keep trying to make this some complex weird argument invoking the SIP
deities of the past and quoting incomprehensible phrases from various RFC
caved in stone but the bottom line in the code is very simple to understand.
When creating the offer you alloced some resources ( like a port to receive
video on ). When you get an answer that does not use that resource, you need
to tell the media stack if it should free the resources or not. O/A has
situation where you need to keep the resources available (like there are
more dialogs coming) and situation where you need to free the resource.
Since we split the signalling out of the browser and left the media in the
browser, we need be able to allow the JS that is dealing with signaling to
tell the browser when to free the resource.

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 11 Oct 2012 17:25:01 +0200

> I have not seen any reason to relax 3264 yet but if something comes up, agree we should carefully look at the cases. I think we can just do straight up 3264. Arguments that SIP early media in a 180…
This seems to be true as long as I consider the offer/180 exchange a 
separate SDP exchange from the offer/answer exchange, and abandon the 
concept that the final answer "updates" the 180 answer.

Is that what you are saying, or did I squint the wrong way?

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 11 Oct 2012 17:38:18 +0200

Hi,

> Is that what you are saying, or did I squint the wrong way?

If you receive the SDP answer in a reliable 180 response, that IS an offer/answer exchange :)

That answer CANNOT be "updated" in another reliable 18x response, or in the 200 response. 

(You can receive a "copy" of the previously received SDP answer in the 18x/200 responses, but it will not update the previously received SDP answer)

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 11 Oct 2012 17:44:18 +0200

That answer CANNOT be "updated" in another reliable 18x response, or in the 200 response - on the same SIP early dialog, that is.

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Christer Holmberg [[email-masked]]
Sent: Thursday, October 11, 2012 6:38 PM
To: Harald Alvestrand; [email-masked]
Subject: Re: [rtcweb] Agenda requests for Atlanta meeting

Hi,

Regards,

Christer

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Fri, 12 Oct 2012 15:52:28 +0000

> Quit beating around the bush: it's me you are talking about.

Sorry Martin - I did not mean exactly you. I meant, you, me, Christer, others. I think we just need to get all very pragmatic and specific about what the code needs to do. And I don't mean to imply that you or Christer are not - you both are very pragmatic. But we all need to get this thread to specific examples about real world use cases that people can understand.

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Fri, 12 Oct 2012 15:59:04 +0000

On Oct 9, 2012, at 4:58 PM, Martin Thomson <[email-masked]> wrote:

> especially hard. 

Agree that text has to be a clear. But provision is a term from 3261 which is referenced from 3264 and bunch of this also relies on SDP RFC too. Some of the key information about it is 3262. This is all intertwined but my key point is that I don't think we are trying to do anything that was not part of 3264 offer / answer. This is more or less a SIP 180.

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Fri, 12 Oct 2012 16:04:31 +0000

I fully agree this needs to work early media to PSTN via SIP. I don't see any problem with doing that. I'm happy to work through detail call flows to make sure that early media to PSTN works. 

Update after a 180 is not allowed by the Update RFC as I pointed out in other email exactly because just in SIP with no RTCP web, the UA that caret the invite would not have enough information to be able to process this as you point in the thread below.

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 12 Oct 2012 19:41:29 +0200

Cullen, 

I did send a real world call flow example, which you haven't commented :)

Regards,

Christer

________________________________________
From: Cullen Jennings (fluffy) [[email-masked]]
Sent: Friday, October 12, 2012 6:52 PM
To: Martin Thomson
Cc: Christer Holmberg; [email-masked]
Subject: Re: [rtcweb] Agenda requests for Atlanta meeting

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 12 Oct 2012 19:43:24 +0200

Hi,

> Update after a 180 is not allowed by the Update RFC as I pointed out in other email exactly because just in SIP with no RTCP web, the UA that caret the invite would not have enough information to b…

As far as I know, UPDATE is allowed after a reliable 180. If you don't agree, please show me the text which forbids it :)

Regards,

Christer

---

From: James Polk <[email-masked]>
Date: Fri, 12 Oct 2012 14:21:14 -0500

At 12:43 PM 10/12/2012, Christer Holmberg wrote:
>Hi,
>
> > I fully agree this needs to work early media to PSTN via SIP. I 
> don't see any problem with doing that. I'm happy to work through 
> detail call flows to make sure that early media to PSTN works.
> >
> > Update after a 180 is not allowed by the Update RFC as I pointed 
> out in other email exactly because just in SIP with no RTCP web, 
> the UA that caret the invite would not have enough information to 
> be able to process this as you point in the thread below.
>
>As far as I know, UPDATE is allowed after a reliable 180. If you 
>don't agree, please show me the text which forbids it :)

UPDATE is allowed after a before and after a 180, and allowed after a 
200 OK to the INVITE. RFC 6442 (Geolocation Header) took advantage of 
this function through/with/by/whatever the blessing of Jonathan R.

James

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Sat, 13 Oct 2012 02:21:46 +0000

> As far as I know, UPDATE is allowed after a reliable 180. If you don't agree, please show me the text which forbids it :)

I agree - but it's not ok after a normal 180

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 14 Oct 2012 15:21:08 -0400

> Agree that text has to be a clear. But provision is a term from 3261 which is referenced from 3264 and bunch of this also relies on SDP RFC too. Some of the key information about it is 3262. This i…

I am trying to follow this argument, but am having difficulty, even 
though I agree with much of what has been said by those who seem to be 
on different sides of the "argument".

There is much about what needs to be done in presence of forking that is 
not written, but which is a corollary to what is specified. Most of what 
Christer described falls into this category. Implementations that don't 
do this will fail on some cases.

The problem I have with PRANSWER is that I don't if it ever applies when 
sip is at one end, and if so, how it applies. IMO the simple answer is 
that it is an extension that should not be used when gatewaying to sip. 
But now I think I see people saying it is only there for gatewaying to 
sip. If so, then I want to see a specification for how this maps.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 14 Oct 2012 15:38:31 -0400

> The *initial* O is shared across multiple legs. Once a dialog has been created, O/A transactions on that leg will not affect other legs.

+1

I'll also observe that you can have early dialogs without reliable 
provisionals. E.g.:

- A sends INIVTE offering codecs C1 and C2
- proxy P forks first to B.
- B sends unreliable 180, tag BBB, with answer selecting codec C1,
   and starts sending media.
- P cancels the invite to B and forwards the invite to C
- C sends unreliable 180, tag CCC, with answer selecting codec C2,
   and starts sending media
- C sends 200 with same answer as before.

Note that A must not invalidate the use of C2 when it receives the 180 
from B, unless it first clones the invite. It must leave it eligible for 
use on other dialogs. And of course while it can manage separate O/A 
state machines per dialog, down at the RTP stack it may not be able to 
correlate the incoming media with a particular one of those O/A state 
machines.

(Consider the example above, but the 180 from B is lost - never received 
by A. Since it isn't reliable, nobody knows this. But the media still 
comes.)

Of course things are a bit different when you layer ICE on top of this. 
I won't try to discuss that.

	Thanks,
	Paul

---

From: "Parthasarathi R" <[email-masked]>
Date: Mon, 15 Oct 2012 23:25:12 +0530

Cullen,

As you mentioned in another mail thread, the discussion is about mapping
UPDATE with SDP just after reliable 18x with SDP in JSEP PRANSWER state.
Hope you agree that PRANSWER does not address UPDATE with SDP (OFFER from
remote) in the early dialog scenario.

Thanks
Partha

-----Original Message-----
From: Cullen Jennings (fluffy) [mailto:[email-masked]] 
Sent: Saturday, October 13, 2012 7:52 AM
To: Christer Holmberg
Cc: Parthasarathi R; <[email-masked]>
Subject: Re: [rtcweb] Agenda requests for Atlanta meeting

On Oct 12, 2012, at 11:43 AM, Christer Holmberg
<[email-masked]> wrote:

> Hi,
> 
>> I fully agree this needs to work early media to PSTN via SIP. I don't see
any problem with doing that. I'm happy to work through detail call flows to
make sure that early media to PSTN works.
>> 
>> Update after a 180 is not allowed by the Update RFC as I pointed out in
other email exactly because just in SIP with no RTCP web, the UA that caret
the invite would not have enough information to be able to process this as
you point in the thread below.
> 
> As far as I know, UPDATE is allowed after a reliable 180. If you don't
agree, please show me the text which forbids it :)

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 17 Oct 2012 16:04:05 -0400 (EDT)

> From: "Cullen Jennings (fluffy)" <[email-masked]>
> 
> But we all need to get this thread to specific examples about real
> world use cases that people can understand.

This is an analysis of how SIP/WebRTC gateway design depends upon and
reflects the offer/answer architecture that is chosen for WebRTC.  The
unexpected result is that a SIP/WebRTC gateway can work well with a
*simpler* WebRTC offer/answer architecture than is being discussed,
indeed, an O/A architecture resembling a single caller/callee pair.

* Background

The overall task that must be performed by a SIP/WebRTC-server gateway
combined with the WebRTC-client is the same as what a SIP telephone
does.  A detailed discussion is in my previous message
http://www.ietf.org/mail-archive/web/rtcweb/current/msg05435.html.
The important point for this discussion is:  Quality handing of
outgoing SIP calls requires integrating (mixing) information from both
the signaling and media for all early dialogs to generate the media
stream to be presented to the user.

Let me now outline three architectures and their characteristics.  I
still haven't checked the consequences of requiring ICE, but I believe
that it does not fundamentally change the analysis.

* cloning

In the cloning architecture, the WebRTC protocol reveals the multiple
dialogs of the SIP call.  When the client Javascript initiates the
call, a "call object" is created.  When the SIP signaling reveals to
the gateway the existence of a new early dialog, the gateway uses
WebRTC to tell the client of the new dialog, and a child "dialog
object" is created.  The dialog objects are continually updated by
information from the WebRTC server to tell the Javascript the status
of the early dialogs.

The WebRTC client is the source/target of the media streams.  (If it
is possible for an early dialog's media stream to arrive at the client
before corresponding SIP signaling, the client stack creates
additional dialog objects for those early dialogs.)

The client stack or Javascript must integrate the information in the
signaling and media to produce the audio stream to be presented to the
user.

This architecture is the most complicated form of WebRTC.  It also
requires that the client stack and/or Javascript implement the full
processing required by a SIP phone in all cases, because in general,
the client-side code never knows whether a communication session is
directed to a SIP gateway or not.

* PRANSWER

In the PRANSWER architecture, the WebRTC protocol carries SDP in a
manner that is similar to SDP offer/answer between two endpoints.  The
exception is that the offer provided with call initiation may receive
a sequence of answers, which inform the client of the origins of
successive early dialogs that it should listen to.

The WebRTC client is the source/target of the media streams.

This architecture presupposes that there will be only one early dialog
at a time that is producing media that the user needs to hear, and
that the gateway can determine from the SIP signaling what this
sequence of dialogs is.

The difficulty is that neither of these presuppositions is correct:
Given parallel forking, the call may have reached destinations that
are both producing important feedback at the same time.  Also, the SIP
signaling does not completely inform the SIP caller which destinations
are producing media streams that contain information -- that decision
requires determining if RTP is arriving from each destination and
whether the RTP is non-silent.  In addition, if the signaling shows
that a destination is ringing but is not providing media, synthetic
ringback media should be provided.  This architecture requires that
the gateway make these decisions despite not being the endpoint of the
media streams.

* simple

In the "simple" architecture, the WebRTC protocol models a *single*
offer/answer dialog, and all of the media processing required for a
SIP early dialog is placed in the gateway:  Initially, the gateway
provides an answer giving *itself* as the server end of the media
streams.  During the early phase of the call, the gateway decodes,
synthesizes, and mixes all of the early media according to the
principles for SIP telephones, and sends a single RTP stream to the
WebRTC client that is the audio the user should hear.  This is
relatively easy because the gateway has direct access to both the
signaling and the media from the SIP destinations.

At some point (probably when one dialog becomes established), the
gateway decides to remove itself from the media processing, and does a
"Z operation" to pass a new offer/answer pair between the now-unique
UAS and the WebRTC client.

(A "Z operation" is named for its appearance on protocol diagrams:  An
intermediate device sends a request to the endpoint in one direction
demanding that it produce an offer; the intermediate device passes the
offer through to the other endpoint, which produces an answer; the
intermediate device passes the answer through back to the first
endpoint.)

This architecture has several advantages:

(1) The WebRTC protocol implements only a single offer/answer
sequence.

(2) The gateway is responsible for combining the media and signaling
information of the early dialogs; the multiple early dialogs are not
revealed in WebRTC.  This processing is relatively easy to implement,
as it can be implemented in about the same way that SIP phones now
implement it.

(3) Improving the handling of multiple early dialogs can be done
entirely by updating the gateway; the WebRTC protocol does not
commit the processing to any particular model.

(4) WebRTC client stacks and application Javascript provide no special
support for SIP forking; all connections appear to them to be "a direct
connection to a media server".

Dale

---

From: Lishitao <[email-masked]>
Date: Wed, 24 Oct 2012 06:54:19 +0000

Hi Cullen and all

If time is permitted, I suggest in JSEP part we can discuss the Rehydration scenario.
I have an alternative approach in draft-li-rtcweb-ice-page-reload-02, which suggests 
to re-use the old connection to recovery the session. Also I see that in the JSEP-02, it also 
indicate an open issue for the Rehydration scenario, so I think it is worth to discuss it during 
the meeting. I can provide some slides for it if needed. 

Commends for my approach are also welcomed.

Regards
shitao
> Sent: Thursday, October 04, 2012 11:44 PM
> To: [email-masked]
> Justin and I would like to have some time for JSEP. I think there are a bunch of
> issues, particularly around the use of SDP and timing of various things that
> need discussion.
> 
> Thanks, Cullen
> 
> 
>