Subject: [rtcweb] PRANSWER is unusable for serial forking

From: Roman Shpount <[email-masked]>
Date: Mon, 8 Oct 2012 22:46:23 -0400

Changing subject

On Mon, Oct 8, 2012 at 10:30 PM, Cullen Jennings <[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.
>
>
This actually works fairly well in the current systems. The fact that
UPDATE is used does not mean there are multiple media streams flowing at
any given time. And, I am familiar with a couple of systems that do exactly
what I have described. Typically some sort of announcement or
color-ring-back system followed by a voice mail. I think the problem is
that this group picked one interop scenario and added something to support
it while arbitrarily deciding that other scenarios should not be supported.
SIP does not have serial forking. Offer/Answer does not describe something
like this. We either need to define it and make it something that describes
some set of existing scenarios or add support for something that is defined.
_____________
Roman Shpount

---

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

Hi,

I THINK Roman is talking about the following flow:

BROWSER		JS APP			FORKING PROXY			SIP UA 1			SIP UA 2

------- OFFER --------------->
                                                  ----- INVITE (OFFER 1) --------->
							----- INVITE (OFFER 1) --------->
							----- INVITE (OFFER 1) ---------------------------------------------------->
							<----180 (ANSWER 1a) ----------
			<----180 (ANSWER 1a) ----------
<----PRANSWER -----------
							<----UPDATE (OFFER 2) --------
			<----UPDATE (OFFER 2) ---------
<----???? --------------------
							<----200 (ANSWER 1b) ------------------------------------------------------
			<----200 (ANSWER 1b) ----------
<----ANSWER ---------------

What is "????"?

Note that this is NOT about parallel forking, and which media is played to the user - the JS APP can make that decision based on whatever policy. The question is how the UPDATE is mapped to the JSEP API.

Regards,

Christer

From: [email-masked] [mailto:[email-masked]] On Behalf Of Roman Shpount
Sent: 9. lokakuuta 2012 5:46
To: Cullen Jennings
Cc: [email-masked]
Subject: [rtcweb] PRANSWER is unusable for serial forking

Changing subject

On Mon, Oct 8, 2012 at 10:30 PM, Cullen Jennings <[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.

This actually works fairly well in the current systems. The fact that UPDATE is used does not mean there are multiple media streams flowing at any given time. And, I am familiar with a couple of systems that do exactly what I have described. Typically some sort of announcement or color-ring-back system followed by a voice mail. I think the problem is that this group picked one interop scenario and added something to support it while arbitrarily deciding that other scenarios should not be supported. SIP does not have serial forking. Offer/Answer does not describe something like this. We either need to define it and make it something that describes some set of existing scenarios or add support for something that is defined.
_____________
Roman Shpount

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 9 Oct 2012 11:24:38 +0200

2012/10/9 Roman Shpount <[email-masked]>:
> SIP does not have serial forking.

SIp has serial forking but just at signaling level, not at media level :)

> Offer/Answer does not describe something
> like this.

+1

> We either need to define it and make it something that describes

IMHO the solution is described in other mail thread (maybe in rtcweb
WG): implement cloning. Example:

- My JS SIP app sends an INVITE with SDP and receives a 183 response
with To-tag "AAAA" and SDP A, so I already have a media stream.

- Later the voicemail system answers the call so replies a 200 with
To-tag "BBBB" and SDP B. Since To-tag is different I do know (as per
RFC 3261/3264) that I should create another media "session" sharing my
local SDP (but cloning it). And I also want to close the previous one.

Of course, for this we need some API method like
"cloneLocalDescription(new_remote_sdp_object)" or whatever.

AFAIR this has been recently discussed in rtcweb WG.

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

---

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

> 			<----UPDATE (OFFER 2) ---------

That's not a call flow that is legal for use of update. From section 5.1 of of RFC 3311 has 

     o  If the UPDATE is being sent before completion of the initial
         INVITE transaction, and the initial INVITE contained an offer,
         the UPDATE can contain an offer if the callee generated an
         answer in a reliable provisional response, and the caller has
         received answers to any other offers it sent in either PRACK or
         UPDATE, and has generated answers for any offers it received in
         an UPDATE from the callee.

If the answer from UA1 is going to do updates before the invite transaction complete, it needs to do that with 100rel / PRACK. Note the diagram should also show an the 200 response to the update is going to cary an answer.

So if you made all these changes, lets talk about how you would solve this problem in the JS App. 

Fundamentally what is happening here is the call signaling is setting up two session - this is parallel media forking and parallel signaling forking. One fork to UA1, and one to UA2. The JS App needs to pick which one it is going to choose to have a media session with. Let's say it choose UA1, then it would map the Answer 1a to an Answer, the Offer2 to an offer. If it was going to choose UA2, it would not pass the answer down to the browser at all and would instead wait till it Answer 1b and pass that down. If you think it should simultaneously have a media session with both UA1 and UA2, then things are more complicated. I realize that at the time it gets ANSWER 1a, it does not know it will later get ANSWR 1b so that make it hard to choose UA2. 

Parallel forking with early media and secure media is a hard problem in SIP as we know from the HERFP discussion. I'm unaware of real world problem that are solved well with SIP and require parallel forking and thus my focus has been on making sure we solve serial forking. I'm perfectly happy if we *also* solve parallel forking but I don't care too much as long a early media serial forking scenarios work because theses do happen all the time. I'm pretty skeptical that are a lot of existing SIP phones that deal well with simultaneously receiving and sending media to two other UAs in a scenario like this (I'm trying to separate this from conferencing - I know lots of SIP UA do 3 way calling and conferencing just fine). 

If you want to do both, one way might be to create a new peer connection for the 2nd call, and map it to and IVNTE with replaces, or send a SIP refer to get the second session mapped to the new PeerConnection object. One could also try and work on some thing that allows one PeerConenction to clone to two places but that's going to be a bunch of work to figure out - and again, perfectly happy if someone goes and does that but it's a hard problem when you have resource allocations.

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 13 Oct 2012 09:21:30 +0200

Hi Cullen,

I'll read your reply more in detail later, but please note that I assume that the 180 is sent *reliably* (I left the PRACK out).

Regards,

Christer

________________________________________
From: Cullen Jennings (fluffy) [[email-masked]]
Sent: Saturday, October 13, 2012 5:24 AM
To: Christer Holmberg
Cc: Roman Shpount; Cullen Jennings; [email-masked]
Subject: Re: [rtcweb] PRANSWER is unusable for serial forking

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 13 Oct 2012 11:51:00 +0200

Hi Cullen,

> If the answer from UA1 is going to do updates before the invite transaction complete, it needs to do that with 100rel / PRACK. Note the diagram should also show an the 200 response to the update is…

I agree. I appologize for making too many assumptions. The 180 IS sent reliably, there IS a PRACK, and there IS a response to the UPDATE.

> Fundamentally what is happening here is the call signaling is setting up two session - this is parallel media forking and parallel signaling forking. 

We could even make it more simply by removing the forking part, ie there is a reliable 180, follwed by an UPDATE. But, for now, let's continue with the flow above...

(I have added some numbering to your text below)

>1. One fork to UA1, and one to UA2.

Yes.

>2. The JS App needs to pick which one it is going to choose to have a media session with.

Yes.

>3. Let's say it choose UA1, then it would map the Answer 1a to an Answer, the Offer2 to an offer.

Here comes the issue:

According to jsep-02, when Offer2 comes the JSEP O/A state machine is in the "pranswer" state, where a new offer is not accepted.

And, yes, we could fix that by accepting a new offer at that point. But, to which state would be then go?

>4. If it was going to choose UA2, it would not pass the answer down to the browser at all and would instead wait till it Answer 1b and pass that down.

Sure.

>5. If you think it should simultaneously have a media session with both UA1 and UA2, then things are more complicated. I realize that at the time it gets ANSWER 1a, it does not know it will later get ANSWR 1b so that make it hard to choose UA2.

I am assuming serial forking. Once the answer from UA2 has been provided to the browser, I don't care if the media session with UA1 goes away.

But, again, my main issue at this point is not about media - it's about how the offers and answers between the JS app and the UAs are mapped to JSEP offer/pranswer/answer.

> Parallel forking with early media and secure media is a hard problem in SIP as we know from the HERFP discussion. I'm unaware of real world problem that are solved well with
> SIP and require parallel forking and thus my focus has been on making sure we solve serial forking.

No disagreement from my side there :) 

> I'm perfectly happy if we *also* solve parallel forking but I don't care too much as long a early media serial forking scenarios work because theses do happen all the time.

At the moment, JSEP-02 does talk about cloning. I don't know whether you suggest that to be removed, but if it stays it would work also for serial forking.

Regards,

Christer

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Sat, 13 Oct 2012 12:44:31 +0000

> I'll read your reply more in detail later, but please note that I assume that the 180 is sent *reliably* (I left the PRACK out).

ok - that was probably part of the confusing was we were reading that differntly