Subject: [rtcweb] PRANSWER and 3264

From: Paul Kyzivat <[email-masked]>
Date: Wed, 20 Jun 2012 19:00:08 +0200

ISTM that the introduction of JSEP with PRANSWER introduces behavior 
that is not addressed by the existing o/a spec RFC 3264.

3264 assumes that session management consists of a sequence of 
offer/answer pairs. It provides rules for how an answer is to be 
constructed in compliance with the matching offer, and rules for how a 
new offer is to be constructed in compliance with the prior o/a 
exchange. It does *not* define in any way the processing of two or more 
answers for a single offer.

3261 specifies how offers and answers are carried in SIP messages. It 
provides mechanisms that may seem to result in multiple answers to the 
same offer, but it puts rules on how those are constructed so that valid 
uses of SIP won't violate the assumptions of 3264. Specifically:

- when an sdp "answer" is carried in an unreliable response, that
   answer must be identical to one laster sent reliably. So its
   possible to treat the first one received as the answer, and not
   deal with changes in subsequent responses.

- when an INVITE is forked, the responses are identified by a
   unique dialog id for each responding UAS. The entire o/a protocol
   of 3264 is handled independently for each such dialog. Within each
   of the dialogs the assumptions of 3264 apply.

IIUC, PRANSWER is intended to be used in comparable situations to *both* 
of the above:

- a single dialog with a single endpoint, but where information about
   the desired session evolves over time. (E.g. new ICE candidates
   are discovered.)

- serial forking, where one candidate answer is received and processed,
   and then replaced by an alternative that has no relationship to
   the prior one.

(Note that a number of people have wanted such capability in SIP too. 
But so far it has been easier to tell them to use the existing 
facilities. In particular, cases that want an evolving answer can be 
handled by representing as a new dialog.)

So, I think one of two things is needed from rtcweb to resolve this:

1) a way to map a sequence of JSEP OFFER/*PRANSWER/ANSWER (consistent 
with Figure 2 of JSEP) to and from a sequence of offer/answer consistent 
with 3264.

2) a modification of 3264 that defines the rules for a sequence of 
answers to a single offer.

Of these, (1) is simpler. The simplistic way is to say that each 
PRANSWER and ANSWER is treated as *the* answer to the prior OFFER, 
independent of any prior answer.

But it might be useful to recognize there is a difference between 
evolving an answer and switching to a different fork. In the evolving 
case it would be useful to say what sorts of evolution are permitted and 
which are not.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 20 Jun 2012 20:04:17 +0200

Hi,

>case it would be useful to say what sorts of evolution are permitted and

I don't see sending a *PRANSWER/ANSWER sequence to the browser as a big problem.

It's about updating the previous PRANSWER, and I think we already say that any (PR)ANSWER must follow 3264, and be a subset of the OFFER. It is support of serial forking.

In my opinion, a bigger problem is if the browser, after it has received a JSEP OFFER, starts sending a *PRANSWER/ANSWER sequence. In the case of SIP interworking, we can't simply map those to sequential different SDP answers - at least not with using the same To tag value.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 21 Jun 2012 00:45:02 +0200

> It's about updating the previous PRANSWER, and I think we already say that any (PR)ANSWER must follow 3264, and be a subset of the OFFER. It is support of serial forking.

I don't know that it is so clear. At the end of the day, what is legal, 
and what is not, and what it means, must be written down somewhere in a 
normative way.

And I realized that my "simplistic" way above doesn't quite work, 
because of the requirements on o-lines.

> In my opinion, a bigger problem is if the browser, after it has received a JSEP OFFER, starts sending a *PRANSWER/ANSWER sequence. In the case of SIP interworking, we can't simply map those to sequ…

Yes, how to handle things in that direction must also be specified.

	Thanks,
	Paul

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 21 Jun 2012 10:46:17 +0200

On 06/21/2012 12:45 AM, Paul Kyzivat wrote:
>> In my opinion, a bigger problem is if the browser, after it has 
>> received a JSEP OFFER, starts sending a *PRANSWER/ANSWER sequence. In 
>> the case of SIP interworking, we can't simply map those to sequential 
>> different SDP answers - at least not with using the same To tag value.
>

Isn't that up to the application, which presumably knows it's talking to 
a SIP gateway, and can just decide to "not do that", just as it decides 
to take no action on ICE candidate callbacks, since SIP doesn't support 
trickle candidates?

            Harald

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 21 Jun 2012 23:53:41 +0200

> to take no action on ICE candidate callbacks, since SIP doesn't support

Perhaps. I'm still trying to get my head around this.

I suppose, if the application has sip on the other side, it could send 
javascript that doesn't use PRANSWER - that uses only pure 3264 
compliant o/a.

Note that this wasn't my main point. My main point was simply to 
completely define the offer/answer rules for JSEP. AFAICT they aren't 
currently defined, to the level that 3264 does.

I guess again you could say that it doesn't matter - that the javascript 
and the server just have to agree among themselves what is ok. But if 
so, then why use SDP at all?

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 26 Jun 2012 01:53:18 +0200

Hi, 

> Isn't that up to the application, which presumably knows it's talking to a SIP gateway, and can just decide to "not do that", just as 
> it decides to take no action on ICE candidate callbacks, since SIP doesn't support trickle candidates?

I am not sure I understand what you mean by "not do that".

If the browser sends a PRANSWER, which the app mapps to a SIP answer, and then sends another PRANSWER, the app cannot simply ignore it (it of course depends on what information has changed from the previous PRANSWER).

Regards,

Christer

---

From: Martin Thomson <[email-masked]>
Date: Mon, 25 Jun 2012 17:07:07 -0700

> If the browser sends a PRANSWER, which the app mapps to a SIP answer, and then sends another PRANSWER, the app cannot simply ignore it (it of course depends on what information has changed from the…

Does not compute.  The browser doesn't signal anything.  The app
decides what is and is sent.

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 26 Jun 2012 10:51:08 +0200

Hi, 

>> If the browser sends a PRANSWER, which the app mapps to a SIP answer, and then sends another 
>> PRANSWER, the app cannot simply ignore it (it of course depends on what information has changed from the previous PRANSWER).
>
> Does not compute.  The browser doesn't signal anything.  The app decides what is and is sent.

True. There is no here-is-a-new-answer callback method - the app has to request for an answer.

Regards,

Christer