Subject: [rtcweb] JSEP: Relaxing SDP O/A rules?

From: Christer Holmberg <[email-masked]>
Date: Tue, 2 Oct 2012 20:00:15 +0200

Hi,

One of the arguments for the Microsoft API proposal was regarding the JSEP usage of SDP Offer/Answer.

There has also been ideas about JSEP "relaxing" the SDP O/A rules.

What is the current status of that? Is the intention to "relax" something?

Regards,

Christer

---

From: Kaiduan Xie <[email-masked]>
Date: Tue, 2 Oct 2012 14:56:51 -0400

I also have this concern particularly on how to inter-operate with the
in-service SIP world which follows the SDP O/A rules?

/Kaiduan

On Tue, Oct 2, 2012 at 2:00 PM, Christer Holmberg
<[email-masked]> wrote:
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Martin Thomson <[email-masked]>
Date: Tue, 2 Oct 2012 11:59:54 -0700

> There has also been ideas about JSEP "relaxing" the SDP O/A rules.

JSEP already does that.

PRANSWER is probably the most obvious diversion, but it goes deeper.

There's a simple view of what JSEP is and it goes a little like this:

 - SDP provides a description of the session that you are going to create [1]

 - You need two SDP blobs so that you can get all the non-negotiated
parameters like crypto and candidate attributes

 - setLocalDescription and setRemoteDescription provide a way of
matching up two SDP blobs into a complete session description

 - negotiation is performed outside this machine, and the browser can
help you with that in two ways: providing createOffer and createAnswer
to build the SDP; and by nudging you with a negotiatedneeded event
when it learns of things that necessitate changes.

Obviously, it's a little more nuanced than that, but if you take this
view, you are more likely to get something to work.

--Martin

[1] Caveat: PRANSWER adds a layer of complexity to this by shifting
part of the session description to the offer rather than the answer

---

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

Hi,

I've been looking at the O/A state machine, and the associated procedure text, in section 4.2 of draft-jsep, and a couple of issues.

First, the text says:

        "As in [RFC3264], an offerer can send an offer, and update it as long as it has not been answered."

That is not true. In order to update an offer (before it has been answered), one needs to cancel the previous offer.

Second, the text says:

        "A description used as a "pranswer" may be applied as a response to an "offer", or an update to a previously sent "answer"."

I don't understand the update-to-a-previously-sent-answer thing. I don't understand why one would update an "answer" with a "preanswer".

And, the state machine doesn't seem to support it either. So, if done,  what state will I be in after such action? Can I then also send a new "answer", to update the "preanswer" that updated the "answer"?

Third, is there a reason why a new "offer" can't be sent once in the "Preanswer" state?

Regards,

Christer

-----Original Message-----
From: Martin Thomson [mailto:[email-masked]]
Sent: 2. lokakuuta 2012 22:00
To: Christer Holmberg
Cc: [email-masked]
Subject: Re: [rtcweb] JSEP: Relaxing SDP O/A rules?

JSEP already does that.

 - You need two SDP blobs so that you can get all the non-negotiated parameters like crypto and candidate attributes

 - setLocalDescription and setRemoteDescription provide a way of matching up two SDP blobs into a complete session description

 - negotiation is performed outside this machine, and the browser can help you with that in two ways: providing createOffer and createAnswer to build the SDP; and by nudging you with a negotiatedneeded event when it learns of things that necessitate changes.

Obviously, it's a little more nuanced than that, but if you take this view, you are more likely to get something to work.

--Martin

[1] Caveat: PRANSWER adds a layer of complexity to this by shifting part of the session description to the offer rather than the answer

---

From: Kaiduan Xie <[email-masked]>
Date: Wed, 3 Oct 2012 09:42:51 -0400

There was a discussion on this,

http://www.ietf.org/mail-archive/web/rtcweb/current/msg05141.html

However I have not seen how the IETF webrtc work group address this issue.

/Kaiduan

On Wed, Oct 3, 2012 at 9:03 AM, Christer Holmberg
<[email-masked]> wrote:
> Hi,
>
> I've been looking at the O/A state machine, and the associated procedure
> text, in section 4.2 of draft-jsep, and a couple of issues.
>
> First, the text says:
>
>         "A description used as a "pranswer" may be applied as a response to
> an "offer", or an update to a previously sent "answer"."
>
> I don't understand the update-to-a-previously-sent-answer thing. I don't
> understand why one would update an "answer" with a "preanswer".
>
> And, the state machine doesn't seem to support it either. So, if done,  what
> state will I be in after such action? Can I then also send a new "answer",
> to update the "preanswer" that updated the "answer"?
>
>
> On 2 October 2012 11:00, Christer Holmberg <[email-masked]>
> wrote:
> - setLocalDescription and setRemoteDescription provide a way of matching up
> two SDP blobs into a complete session description
>
> - negotiation is performed outside this machine, and the browser can help
> you with that in two ways: providing createOffer and createAnswer to build
> the SDP; and by nudging you with a negotiatedneeded event when it learns of
> things that necessitate changes.
>
> Obviously, it's a little more nuanced than that, but if you take this view,
> you are more likely to get something to work.
>
> --Martin
>
> [1] Caveat: PRANSWER adds a layer of complexity to this by shifting part of
> the session description to the offer rather than the answer
>
>

---

From: Martin Thomson <[email-masked]>
Date: Wed, 3 Oct 2012 08:26:36 -0700

These are just a few of the problems with the provisional answer.

> one needs to cancel the previous offer.

This might be OK if it were to include the fact that any outstanding
offer is implicitly cancelled.

Note that it is not clear how the current API could be used to cancel
an offer.  Various suggestions include passing a null offer or by
setting the local (or remote?) description to a previous offer.

> understand why one would update an "answer" with a "preanswer".

This doesn't make sense to me either.  I could understand if it was an
update to a previously sent *pranswer*, but since an answer is final,
any further answers are illegal.

> to update the "preanswer" that updated the "answer"?

That's why I think that this is in error.

> Third, is there a reason why a new "offer" can't be sent once in the

Yes.  If you send an offer out to multiple people and one gives a
provisional answer, the new offer you create would have to be cleverly
crafted to permit all sessions described by the previous offer as well
as any new stuff, such that an answer to the old offer could be
applied to the new offer.  That really complicates things.

In the assumed model, all answers and pranswers are made in respect to
a specific offer.  answers and pranswers only be applied to a session
that has applied their specific offer.  pranswers and answers can
replace pranswers that reference the same offer.

This is an expansion on 3264.  This is what draft-*-jsep needs to
describe clearly, if that is appropriate.  I am slowly reaching the
conclusion that pranswer is a complication that we don't need,
especially since - for those who care about the functionality - it can
be replicated by editing offers and answers.

--Martin

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 04 Oct 2012 10:57:30 +0200

> be replicated by editing offers and answers.

I would be very happy to lose PRANSWER if the SIP guys tell us they can 
successfully gateway to systems using provisional SIP answers (which I 
think is the same thing as the one called "serial forking") without them.

For the Web use case, I think PRANSWER is an unnecessary distraction; if 
we're writing both initiator and responder, multiple O/A rounds, or use 
of multiple PeerConnections, is a much cleaner solution for the use 
cases I can wrap my head around.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 4 Oct 2012 11:52:55 +0200

Hi,

> think is the same thing as the one called "serial forking") without them.

I guess serial forking could be handled using cloning, in the same way as parallel forking.

(Assuming we are going to support cloning, that is - currently it IS described in JSEP)

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 4 Oct 2012 11:56:22 +0200

Hi,

>> That is not true. In order to update an offer (before it has been 
>> answered), one needs to cancel the previous offer.
>
> This might be OK if it were to include the fact that any outstanding offer is implicitly cancelled.

Sure. My issue was about the RFC 3264 claim. It's one of the "relaxes" we would have to specify ourselves.

> Note that it is not clear how the current API could be used to cancel an offer.  Various suggestions include passing a null offer or by setting the local (or remote?) description to a previous offer.

I assume that setting the description to a previous offer, from an API perspective, is the same as updating the offer with something new.

Regards,

Christer

---

From: Martin Thomson <[email-masked]>
Date: Thu, 4 Oct 2012 11:00:53 -0700

On 4 October 2012 09:57, Harald Alvestrand <[email-masked]> wrote:
> we're writing both initiator and responder, multiple O/A rounds, or use of
> multiple PeerConnections, is a much cleaner solution for the use cases I can
> wrap my head around.

I'd remove that qualifier.  We currently have a draft that describes
both cloning AND PRANSWER, both of which are more cleanly addressed by
either multiple O/A rounds or multiple independent sessions.

The two things that these provide is

PRANSWER:
The ability to describe a session that includes receipt capabilities
that are a superset of send capabilities.  SDP O/A doesn't really
provide a way for me to describe this because the default assumption
is that items not appearing in the answer are no longer needed.
With something like bundle involved, we could split m= lines into
sendonly and recvonly portions to allow for this case to be provided.

CLONING:
The ability to use the same transport primitives to interact with
multiple peers.  Ostensibly, this is to prepare for a session, with
only one continuing to completion, mainly to reduce clipping.
By adding candidates from all serial offenders to the same answer, you
can get ICE setup, though I doubt that DTLS handshakes will be able to
complete unless we permit multiple a=fingerprint lines and a few other
things.  I'm still disinclined to support this feature.  Let the
forkers have clipping.

Both of these complicate the API significantly.  I'd rather see the
complexity pushed to the applications that need this complexity.

That is, unless you are willing to consider a better API that makes
these issues SEP.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 4 Oct 2012 20:21:22 +0200

Hi,

>sendonly and recvonly portions to allow for this case to be provided.

I don't think the reason for PRANSWER comes from SDP O/A as such. It's more about supporting serial forking.

>things.  I'm still disinclined to support this feature.  Let the

If you want to support parallel forking, you need to be able to simultanously perform ICE etc with all remote peers.

>complexity pushed to the applications that need this complexity.

I want to be able to support forking. Exactly HOW it's done can be discussed.

Also, I can live without support of parallel forking, and I don't really care if serial forking support is provided using cloning or being able to update the remote descriptor (using PRANSWER, or something else).

>That is, unless you are willing to consider a better API that makes

You have one in mind? ;)

Regards,

Christer

---

From: Martin Thomson <[email-masked]>
Date: Thu, 4 Oct 2012 11:43:55 -0700

> I don't think the reason for PRANSWER comes from SDP O/A as such. It's more about supporting serial forking.

Not my point.  My point is that the desired functionality (apply the
answer without invalidating the offer) cannot be easily provided using
SDP O/A.  Most scenarios leave the possibility that the offerer sends
the (provisional) answerer stuff that the answerer doesn't want.

> If you want to support parallel forking, you need to be able to simultanously perform ICE etc with all remote peers.

Right.  You can almost get that by pretending that it's just one
remote peer with lots of candidates.  You can at least get to the
consent point by doing that.  But you aren't going to nominate more
than one pair.  Similarly, this will only generate a single DTLS
session.

Media is a complete mess if you manage to get that far.  Unless you
like scenarios were A and hear B and C, but B and C can't hear each
other and other such joys (there's a consent issue too, but it's a
minor issue of scale).

> I want to be able to support forking. Exactly HOW it's done can be discussed.

One approach is to create as many RTCPeerConnection objects as you
feel might be needed.  Then it becomes YOUR problem, not our problem.
And those are the sorts of problem I like ;)  (I might be interested
in forking too, but I'm happy to keep my problems private.)

> Also, I can live without support of parallel forking, and I don't really care if serial forking support is provided using cloning or being able to update the remote descriptor (using PRANSWER, or s…

Serial forking is potentially far easier to support by doing a series
of O/A exchanges:
10: setLocal(offer)
20: get next answer
30: setRemote(answer)
40: goto 10
There's the small matter of having no guarantee that the offer will
set successfully, but I'd consider that an unlikely scenario in
practice.

>>That is, unless you are willing to consider a better API that makes

I am not at liberty to disclose that information.

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Thu, 4 Oct 2012 23:16:03 +0000

I'm going to get back to this thread at some point but as we pointed out before, some of the text on this in the draft is just wrong. I'm trying to sort out some of the key things on what basic SDP looks like for rtcweb before getting back to the PRANSWER stuff.

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 5 Oct 2012 09:39:16 +0200

Hi,

> than one pair.  Similarly, this will only generate a single DTLS

I was thinking about the same once, but I think I found some issues (unfortunately they don't come to my mind at the moment).

But, it's for sure an alternative we could look into.

That would allow ICE to take place during the early session, but media might be more tricky - unless you also add the m- lines of each remote peer to the "pretended" single peer.

> set successfully, but I'd consider that an unlikely scenario in

Can I use the same local descriptor for every setLocal() call?

> I am not at liberty to disclose that information.

Can you then at least tell me when I'll be able to buy the Microsoft Surface? :)

Regards,

Christer

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 05 Oct 2012 19:13:10 +0200

> I don't think the reason for PRANSWER comes from SDP O/A as such. It's more about supporting serial forking.
I've asked that question before, but I don't remember seeing an answer 
from people who know what they're talking about:

Does serial forking, as practiced by SIP UAs, violate the SDP O/A model, 
or does it not violate the SDP O/A model?

I don't understand how it, in the form that has been described as "what 
we have to support", can be SDP O/A compatible, but then there are many 
things about SIP that I don't understand, so I may understand it when 
it's explained to me.

               Harald

---

From: Martin Thomson <[email-masked]>
Date: Fri, 5 Oct 2012 10:14:16 -0700

> I was thinking about the same once, but I think I found some issues (unfortunately they don't come to my mind at the moment).

It's probably not going to be flawless, true.  As you say, media would
be a little crazy.  You might be able to get one media stream out of
it - not multiple.

> Can I use the same local descriptor for every setLocal() call?

My experience suggests that you can.  However, that's not stipulated
in the API specification, so it's not an ironclad guarantee.

> Can you then at least tell me when I'll be able to buy the Microsoft Surface? :)

Yes.  When they release it.  October 25 apparently.

---

From: Roman Shpount <[email-masked]>
Date: Fri, 5 Oct 2012 13:46:23 -0400

On Fri, Oct 5, 2012 at 1:13 PM, Harald Alvestrand <[email-masked]>wrote:

> I don't understand how it, in the form that has been described as "what we
> have to support", can be SDP O/A compatible, but then there are many things
> about SIP that I don't understand, so I may understand it when it's
> explained to me.
>
>
O/A does not describe multiple answers to a single offer. Nothing
explicitly prohibits it there but I would argue this is not part of this
specification. No standard document that I am aware of describes how serial
O/A is supposed to work. Serial forking as practiced by SIP UA does violate
SIP RFC 3261 which states that each dialog can only have one answer to each
offer. If answer is sent in both provisional and final response, it should
be the same. You can, however, create multiple dialogs with the same offer.
This normally implies parallel forking, but the most common use case is
with early media, where you end up with multiple early dialogs. For
instance you call a phone number, phone network sends you SDP in early
media and plays a dial tone, then the called number does not answer, and
you get connected to a voice mail which uses a completely different SDP in
final answer. According to SIP these answers should come with different
to-tags and technically would be parts of two different dialogs. What makes
this a bit tricky is when the phone network and the voice mail are behind
SBC (or some other sort of B2BUA) you only see one dialog which send you
multiple answers to the same offer. This scenario is so common that it is
more likely to be implemented then parallel forking. This is why PRANSWER
was suggested.

If cloning can be implemented in WebRTC it would be more standard compliant
then PRANSWER and would allow for a lot more use cases. Typical difficulty
in parallel forking implementation in SIP is due to RTP from multiple
sources coming to the same IP and port with no consent or notification to
the receiving side. This makes it very difficult to present this media to
the user. There is no way to tie media to actual dialogs since RTP can come
from different IP and ports then specified in answer SDPs. This is not an
issue with WebRTC where consent to receive media is required. I would argue
let's implement cloning and not waste any more time on PRANSWER which in my
opinion will always stay a half working hack.
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 5 Oct 2012 23:26:38 +0200

Hi,

Roman is correct.

The SDP O/A doesn't consider forking, because each forked SIP leg creates a unique early dialog, and each early dialog has its own O/A state machine.

Regards,

Christer

________________________________
From: Roman Shpount [[email-masked]]
Sent: Friday, October 05, 2012 8:46 PM
To: Harald Alvestrand
Cc: Christer Holmberg; [email-masked]
Subject: Re: [rtcweb] JSEP: Relaxing SDP O/A rules?

On Fri, Oct 5, 2012 at 1:13 PM, Harald Alvestrand <[email-masked]<mailto:[email-masked]>> wrote:
I've asked that question before, but I don't remember seeing an answer from people who know what they're talking about:

Does serial forking, as practiced by SIP UAs, violate the SDP O/A model, or does it not violate the SDP O/A model?

I don't understand how it, in the form that has been described as "what we have to support", can be SDP O/A compatible, but then there are many things about SIP that I don't understand, so I may understand it when it's explained to me.

O/A does not describe multiple answers to a single offer. Nothing explicitly prohibits it there but I would argue this is not part of this specification. No standard document that I am aware of describes how serial O/A is supposed to work. Serial forking as practiced by SIP UA does violate SIP RFC 3261 which states that each dialog can only have one answer to each offer. If answer is sent in both provisional and final response, it should be the same. You can, however, create multiple dialogs with the same offer. This normally implies parallel forking, but the most common use case is with early media, where you end up with multiple early dialogs. For instance you call a phone number, phone network sends you SDP in early media and plays a dial tone, then the called number does not answer, and you get connected to a voice mail which uses a completely different SDP in final answer. According to SIP these answers should come with different to-tags and technically would be parts of two different dialogs. What makes this a bit tricky is when the phone network and the voice mail are behind SBC (or some other sort of B2BUA) you only see one dialog which send you multiple answers to the same offer. This scenario is so common that it is more likely to be implemented then parallel forking. This is why PRANSWER was suggested.

If cloning can be implemented in WebRTC it would be more standard compliant then PRANSWER and would allow for a lot more use cases. Typical difficulty in parallel forking implementation in SIP is due to RTP from multiple sources coming to the same IP and port with no consent or notification to the receiving side. This makes it very difficult to present this media to the user. There is no way to tie media to actual dialogs since RTP can come from different IP and ports then specified in answer SDPs. This is not an issue with WebRTC where consent to receive media is required. I would argue let's implement cloning and not waste any more time on PRANSWER which in my opinion will always stay a half working hack.
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 5 Oct 2012 23:26:59 +0200

Hi,

> be a little crazy.  You might be able to get one media stream out of

And, I guess it would still require to be able to update the answer, as additional early dialogs (with associated remote ICE candidates) may be created.

> in the API specification, so it's not an ironclad guarantee.

If it doesn't, and a new local descripor is created, you would need to send that one to the remote endpoint.

Regards,

Christer

---

From: Martin Thomson <[email-masked]>
Date: Fri, 5 Oct 2012 16:19:57 -0700

> If it doesn't, and a new local descripor is created, you would need to send that one to the remote endpoint.

You don't create a new description, you just set one.  The only
problem arises when you can't set the local description because
something broke since you last set it.  (Maybe setting the answer
caused the browser to release something that you need to set the
offer.)

If that happens, you are hosed.  You could try to make a new
PeerConnection, but you'll have to resend your INVITE because you will
get a new set of candidates, ufrag, pwd, etc...

---

From: "Parthasarathi R" <[email-masked]>
Date: Sat, 6 Oct 2012 11:26:06 +0530

We discussed earlier that PRANSWER states complicates SIP offer/answer
mechanism as the mapping with SIP offer/answer is not well defined. For
Example: "UPDATE with SDP from SIP UAS after sending 18x with SDP has to be
considered as PRANSWER or OFFER or ANSWER in originating JSEP side" ?

I agree with Roman that Cloning is the solution for serial forking as well.

Thanks
Partha  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Christer Holmberg
Sent: Saturday, October 06, 2012 2:57 AM
To: Roman Shpount; Harald Alvestrand
Cc: [email-masked]
Subject: Re: [rtcweb] JSEP: Relaxing SDP O/A rules?

Hi,

Roman is correct.

The SDP O/A doesn't consider forking, because each forked SIP leg creates a
unique early dialog, and each early dialog has its own O/A state machine.

Regards,

Christer

On Fri, Oct 5, 2012 at 1:13 PM, Harald Alvestrand
<[email-masked]<mailto:[email-masked]>> wrote:
I've asked that question before, but I don't remember seeing an answer from
people who know what they're talking about:

Does serial forking, as practiced by SIP UAs, violate the SDP O/A model, or
does it not violate the SDP O/A model?

O/A does not describe multiple answers to a single offer. Nothing explicitly
prohibits it there but I would argue this is not part of this specification.
No standard document that I am aware of describes how serial O/A is supposed
to work. Serial forking as practiced by SIP UA does violate SIP RFC 3261
which states that each dialog can only have one answer to each offer. If
answer is sent in both provisional and final response, it should be the
same. You can, however, create multiple dialogs with the same offer. This
normally implies parallel forking, but the most common use case is with
early media, where you end up with multiple early dialogs. For instance you
call a phone number, phone network sends you SDP in early media and plays a
dial tone, then the called number does not answer, and you get connected to
a voice mail which uses a completely different SDP in final answer.
According to SIP these answers should come with different to-tags and
technically would be parts of
  two different dialogs. What makes this a bit tricky is when the phone
network and the voice mail are behind SBC (or some other sort of B2BUA) you
only see one dialog which send you multiple answers to the same offer. This
scenario is so common that it is more likely to be implemented then parallel
forking. This is why PRANSWER was suggested.

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 6 Oct 2012 20:24:40 +0200

Hi,

>I agree with Roman that Cloning is the solution for serial forking as well.

If we support cloning (no matter whether it's a separate function call, or simply creating a new session with the same local descriptor), I agree that PRANSWER probably could be removed.

At least I have never thought of any other use of it than to support serial forking.

Regards,

Christer

-----Original Message-----

Hi,

Roman is correct.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 6 Oct 2012 20:38:49 +0200

Hi,

> You don't create a new description, you just set one.

Correct.

> The only problem arises when you can't set the local description because

That is the main difference between PRANSWER and ANSWER: PRANSWER does not release local resources based on the answer.

> If that happens, you are hosed.  You could try to make a new PeerConnection, but you'll have to resend your INVITE because you will

Or, you could set the new local descriptor BEFORE you apply the answer to the previous one. I think that is how the cloning is currently described in JSEP: the cloning happens first (eventhough it may never be used, if no additional remote peers are contacted).

Regards,

Christer

---

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

> At least I have never thought of any other use of it than to support serial forking.

Other use cases were raised when connecting to a conference bridge where the initial contact point wanted to keep the options for video codecs open until after the actually MCU was connected. I think there were other uses cases when gatewaying to H.323.

---

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

Uh, sort of  - if you send an offer that says you could get early media, you may get early media from two places even thought you have not received any answer. Yes, I realize you can't do ICE till you get the answer but I think the above is still the case in non ICE case an with ICE case you may end up with two dialogs formed but dialogs are really a Sip level concept not an RTP concept. 

On Oct 5, 2012, at 14:26 , Christer Holmberg <[email-masked]> wrote:

> O/A does not describe multiple answers to a single offer. Nothing explicitly prohibits it there but I would argue this is not part of this specification. No standard document that I am aware of describes how serial O/A is supposed to work. Serial forking as practiced by SIP UA does violate SIP RFC 3261 which states that each dialog can only have one answer to each offer. If answer is sent in both provisional and final response, it should be the same. You can, however, create multiple dialogs with the same offer. This normally implies parallel forking, but the most common use case is with early media, where you end up with multiple early dialogs. For instance you call a phone number, phone network sends you SDP in early media and plays a dial tone, then the called number does not answer, and you get connected to a voice mail which uses a completely different SDP in final answer. According to SIP these answers should come with different to-tags and technically would be parts of
>  two different dialogs. What makes this a bit tricky is when the phone network and the voice mail are behind SBC (or some other sort of B2BUA) you only see one dialog which send you multiple answers to the same offer. This scenario is so common that it is more likely to be implemented then parallel forking. This is why PRANSWER was suggested.
>

---

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

>> caused the browser to release something that you need to set the

If you send an answer that has not relation to the offer, you are equally hosed. We are keeping the pairing of the offers and answers in the JS state so there are ways that the JS can mess things up if it is buggy but that not really a PRANSWER problem - it's just as much a issue with offers and answers. 

> That is the main difference between PRANSWER and ANSWER: PRANSWER does not release local resources based on the answer.

Exactly - and the important implication of this is that the far end can keep using the resources that were in the  Offer. Sequential forking is a poster child for one of the cases where you need to do this but there are others.

---

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

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

>
> Uh, sort of  - if you send an offer that says you could get early media,
> you may get early media from two places even thought you have not received
> any answer. Yes, I realize you can't do ICE till you get the answer but I
> think the above is still the case in non ICE case an with ICE case you may
> end up with two dialogs formed but dialogs are really a Sip level concept
> not an RTP concept.
>
>
Dialogs are entirely SIP level concept, but what I am arguing is that with
ICE and WebRTC you can associate RTP streams with a particular answer. This
means you can clone connection, provide it with the answer and each
connection would be able to filter out only the media that is intended for
it. If I am missing something and ICE is not enough then msid should be.
_____________
Roman Shpount

---

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

Hi,

> Uh, sort of  - if you send an offer that says you could get early media, you may get early media from two places even thought you have not received any answer. 

Sure, but that's separate from the O/A state machine, which is still per dialog.

Regards,

Christer

On Oct 5, 2012, at 14:26 , Christer Holmberg <[email-masked]> wrote:

> explicitly prohibits it there but I would argue this is not part of this specification. No standard document that I am aware of describes how serial O/A is supposed to work. Serial forking as practiced by SIP UA does violate SIP RFC 3261 which states that each dialog can only have one answer to each offer. If answer is sent in both provisional and final response, it should be the same. You can, however, create multiple dialogs with the same offer. This normally implies parallel forking, but the most common use case is with early media, where you end up with multiple early dialogs. For instance you call a phone number, phone network sends you SDP in early media and plays a dial tone, then the called number does not answer, and you get connected to a voice mail which uses a completely different SDP in final answer. According to SIP these answers should come with different to-tags and technically would be parts of  two different dialogs. What makes this a bit tricky is when the phone network and the voice mail are behind SBC (or some other sort of B2BUA) you only see one dialog which send you multiple answers to the same offer. This scenario is so common that it is more likely to be implemented then parallel forking. This is why PRANSWER was suggested.
>

---

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

Hi,

>>>>> My experience suggests that you can.  However, that's not 
>>>>> stipulated in the API specification, so it's not an ironclad guarantee.
>>>> 
>> The only problem arises when you can't set the local description 
>> because something broke since you last set it.  (Maybe setting the 
>> answer caused the browser to release something that you need to set 
>> the
>
> If you send an answer that has not relation to the offer, you are equally hosed. We are keeping the pairing of the offers and answers in the JS state so there are ways that the JS can mess things up if it is buggy but that not really a PRANSWER problem - 
> it's just as much a issue with offers and answers. 

I am not sure what you mean by "an answer that has not relation to the offer". Answers are always related to the Offers.

Regards,

Christer

---

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

> I am not sure what you mean by "an answer that has not relation to the offer". Answers are always related to the Offers.

Sorry - that was poorly written. Lets say you had two PeerConnection call them A and B and they both create an offer and far sides sends answers to both offers. Now if you take the answer from offer B and use it as the answer for A, all bets are off and bad things will happen. That is what I meant by if you use an answer that had no relation to offer it needed to be associated with.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 10 Oct 2012 14:37:42 -0400

On 10/5/12 1:46 PM, Roman Shpount wrote:
>     I've asked that question before, but I don't remember seeing an
>     answer from people who know what they're talking about:
>
>     Does serial forking, as practiced by SIP UAs, violate the SDP O/A
>     model, or does it not violate the SDP O/A model?
>
>     I don't understand how it, in the form that has been described as
>     "what we have to support", can be SDP O/A compatible, but then there
>     are many things about SIP that I don't understand, so I may
>     understand it when it's explained to me.
>
>
> specification. No standard document that I am aware of describes how
> serial O/A is supposed to work. Serial forking as practiced by SIP UA
> does violate SIP RFC 3261 which states that each dialog can only have
> one answer to each offer. If answer is sent in both provisional and
> final response, it should be the same. You can, however, create multiple
> dialogs with the same offer. This normally implies parallel forking, but
> the most common use case is with early media, where you end up with
> multiple early dialogs. For instance you call a phone number, phone
> network sends you SDP in early media and plays a dial tone, then the
> called number does not answer, and you get connected to a voice mail
> which uses a completely different SDP in final answer. According to SIP
> these answers should come with different to-tags and technically would
> be parts of two different dialogs.

Good summary. That is indeed the compliant way to handle this case.

> What makes this a bit tricky is when
> the phone network and the voice mail are behind SBC (or some other sort
> of B2BUA) you only see one dialog which send you multiple answers to the
> same offer. This scenario is so common that it is more likely to be
> implemented then parallel forking.

If you see this then you should complain to the vendor of the SBC/B2BUA 
that they are broken. There is nothing to prevent the SBC from 
generating multiple dialogs in order to do this case correctly.

> This is why PRANSWER was suggested.
>
> If cloning can be implemented in WebRTC it would be more standard
> compliant then PRANSWER and would allow for a lot more use cases.
> Typical difficulty in parallel forking implementation in SIP is due to
> RTP from multiple sources coming to the same IP and port with no consent
> or notification to the receiving side. This makes it very difficult to
> present this media to the user.

Yep.

> There is no way to tie media to actual
> dialogs since RTP can come from different IP and ports then specified in
> answer SDPs.

Known problem. There was a proposal *long* ago to solve this by the 
caller generating new O/As (with distinct addr/port) as soon as possible 
after discovering that forking has occurred. But that didn't go 
anywhere. And it would still leave a window where the association of 
address to dialog isn't known.

> This is not an issue with WebRTC where consent to receive
> media is required.

Yes. ICE helps a lot.

> I would argue let's implement cloning and not waste
> any more time on PRANSWER which in my opinion will always stay a half
> working hack.

Sounds good to me.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 10 Oct 2012 14:50:14 -0400

> or does it not violate the SDP O/A model?

In addition to what Roman already said, I'll add:

SIP (3261 & friends) doesn't say much about how to *do* forking. It sets 
down a bunch of rules, and developing algorithms that adhere to the 
rules is left as an exercise for the reader. There are also many things 
that are implicit but that must be inferred via long chains of 
reasoning. Much of this has become folklore. (RFC 6337 attempts to 
explain a lot of O/A, but doesn't directly address forking.)

The use of a separate dialog per fork falls out for free, by the nature 
of how to-tags (part of dialog id) are assigned.

But this is still a point of confusion among new (and some not so new) 
sip implementers. Questions about this come up regularly on the 
sip-implementers list. I think the frequency of them has been maintained 
for as long as I can remember.

So indeed there are ongoing violations, and some implementations are 
built to tolerate those violations.

	Thanks,
	Paul