Subject: Re: [sipcore] Precondition and swap of 200 (OK) for INVITE and 200 (OK) for UPDATE

From: Andrew Allen <[email-masked]>
Date: Thu, 5 Feb 2015 14:28:54 +0000

There hasn't been any response to this for over 2 months (yes I know it arrived just before the holidays).

In 3GPP we are now seeing proposals to address this along the lines that Ivo proposed. This problem is being seen in actual deployments with different implementations and needs addressing urgently.

In my view this should be addressed by sipcore  (not by 3GPP). If people believe that the action is clear based on RFC 3261 or RFC 3312 text please indicate that or if it is ambiguous should we include errata on RFC 3312 or produce a draft that updates RFC 3312.

Can people please look at Ivo's email problem description and proposed solution/understanding and provide opinions as to what should happen and if they believe it is already documented and where or if not how this should be resolved>

thanks
Andrew

From: sipcore [mailto:[email-masked]] On Behalf Of Ivo Sedlacek
Sent: Tuesday, November 25, 2014 6:20 AM
To: [email-masked]
Subject: [sipcore] Precondition and swap of 200 (OK) for INVITE and 200 (OK) for UPDATE

Hello,

can anyone please give advice on the following problem related to precondition usage in SIP session?

Use case:

- Alice is a mobile phone

- AS is an network based announcement service. AS accepts any received INVITE request, sends audio with 24 hour weather forecast, and hangs up.

- Alice and AS use precondition with segmented status type to indicate state of their resources, Alice needs to reserve resources for the call, AS always have resources available when call setup

- the normal flow for the call is:

               Alice                                        AS

               |                                            |

               |-------------(1) INVITE SDP1--------------->|

               |                                            |

               |<------(2) 183 Session Progress SDP2--------|

               |  ***                                       |

               |--*R*-----------(3) PRACK------------------>|

               |  *E*                                       |

               |<-*S*-------(4) 200 OK (PRACK)--------------|

               |  *E*                                       |

               |  *R*                                       |

               |  *V*                                       |

               |  *A*                                       |

               |  *T*                                       |

               |  *I*                                       |

               |  *O*                                       |

               |  *N*                                       |

               |  ***                                       |

               |  ***                                       |

               |  ***                                       |

               |-------------(5) UPDATE SDP3--------------->|

               |                                            |

               |<--------(6) 200 OK (UPDATE) SDP4-----------|

               |                                            |

               |<-----------(7) 200 OK (INVITE)-------------|

               |                                            |

               |------------------(8) ACK------------------>|

               |                                            |

QUESTION: What is expected Alice's behavior if message (6) and message (7) happened to be swapped during transport from AS to Alice, as shown below?

               Alice                                        AS

               |                                            |

               |-------------(1) INVITE SDP1--------------->|

               |                                            |

               |<------(2) 183 Session Progress SDP2--------|

               |  ***                                       |

               |--*R*-----------(3) PRACK------------------>|

               |  *E*                                       |

               |<-*S*-------(4) 200 OK (PRACK)--------------|

               |  *E*                                       |

               |  *R*                                       |

               |  *V*                                       |

               |  *A*                                       |

               |  *T*                                       |

               |  *I*                                       |

               |  *O*                                       |

               |  *N*                                       |

               |  ***                                       |

               |  ***                                       |

               |  ***                                       |

               |-------------(5) UPDATE SDP3--------------->|

               |                                            |

               |       +-(6) 200 OK (UPDATE) SDP4-----------|

               |       |                                    |

               |<-----------(7) 200 OK (INVITE)-------------|

               |       |                                    |

               |<------+                                    |

In my opinion:

- when receiving message (7), Alice should consider the call as established since 200 (OK) response is received for INVITE request. Alice should send media according to SDP2 as SDP answer to SDP3 has not been received yet.

- when receiving message (6), Alice should start sending media according to SDP4.

Any views?

Kind regards

Ivo Sedlacek

---

From: Adam Roach <[email-masked]>
Date: Thu, 05 Feb 2015 09:44:19 -0600

I think it's a bit more nuanced than you propose below. The behavior has 
to depend on whether there were mandatory preconditions in play.

If all the preconditions were optional, then I think your analysis below 
is correct. This simply falls out of a normal interpretation of 3261, 
3264, and 3311.

But if there are mandatory preconditions in an auto-answer case, then 
the session can't start until those conditions have been met. Here's 
relevant text from RFC 3312, section 6:

>    For an initial INVITE, suspending and resuming session establishment
>    is very intuitive.  The callee will not be alerted until all the
>    mandatory preconditions are met.  However, offers containing
>    preconditions sent in the middle of an ongoing session need further
>    explanation.  Both user agents SHOULD continue using the old session
>    parameters until all the mandatory preconditions are met.  At that
>    moment, the user agents can begin using the new session parameters.

The problem is that the text didn't consider the auto-answer case you 
describe, in which alerting doesn't occur. I see two ways we could 
address this.

One approach would be avoiding the entire problem by formalizing the 
"the callee will not be alerted until all the mandatory preconditions 
are met" to a protocol mechanism: "the callee MUST send a reliable 
provisional response after the conditions are met and MUST receive 
acknowledgement of that response before sending a 200-class response to 
the INVITE."

The other approach would be to treat this the same as "preconditions 
sent in the middle of an ongoing session," in which case the UAs use the 
"old session" (which, in this case, is no session at all) until the 
mandatory preconditions are met. In other words, for your call flow, the 
session wouldn't take effect on receipt of the INVITE 200, but only on 
receipt of the UPDATE 200.

(Thinking about it another way, I suppose you could consider SDP2 in 
your example to be active on receipt of the INVITE 200, but since 
mandatory conditions don't match current conditions, you can't use it.)

Regardless, I think a clarification to 3312 is in order to deal with 
this "auto-answer with mandatory preconditions" case.

/a

On 2/5/15 08:28, Andrew Allen wrote:
>
> There hasn’t been any response to this for over 2 months (yes I know 
> it arrived just before the holidays).
>
> In 3GPP we are now seeing proposals to address this along the lines 
> that Ivo proposed. This problem is being seen in actual deployments 
> with different implementations and needs addressing urgently.
>
> In my view this should be addressed by sipcore  (not by 3GPP). If 
> people believe that the action is clear based on RFC 3261 or RFC 3312 
> text please indicate that or if it is ambiguous should we include 
> errata on RFC 3312 or produce a draft that updates RFC 3312.
>
> Can people please look at Ivo’s email problem description and proposed 
> solution/understanding and provide opinions as to what should happen 
> and if they believe it is already documented and where or if not how 
> this should be resolved>
>
> thanks
>
> Andrew
>
> *From:*sipcore [mailto:[email-masked]] *On Behalf Of *Ivo 
> Sedlacek
> *Sent:* Tuesday, November 25, 2014 6:20 AM
> *To:* [email-masked]
> *Subject:* [sipcore] Precondition and swap of 200 (OK) for INVITE and 
> 200 (OK) for UPDATE
>
> Hello,
>
> - AS is an network based announcement service. AS accepts any received 
> INVITE request, sends audio with 24 hour weather forecast, and hangs up.
>
> - Alice and AS use precondition with segmented status type to indicate 
> state of their resources, Alice needs to reserve resources for the 
> call, AS always have resources available when call setup
>
> QUESTION: What is expected Alice's behavior if message (6) and message 
> (7) happened to be swapped during transport from AS to Alice, as shown 
> below?
>
> Alice                                        AS
>
> |                                            |
>
> - when receiving message (7), Alice should consider the call as 
> established since 200 (OK) response is received for INVITE request. 
> Alice should send media according to SDP2 as SDP answer to SDP3 has 
> not been received yet.
>
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: "VAN GEEL Jan (SPC/CSP)" <[email-masked]>
Date: Thu, 5 Feb 2015 14:56:39 +0000

Looking at the description of this "service", I believe it is not so important what Alice is sending but it is more important what Alice is receiving (and what is sent by he "Announcement Server").
The problem probably remains the same: Alice will receive the weather forecast according to SDP1 till message 6 is received and then receive the weather forecast according to SDP3.

Kind regards

Jan Van Geel
IT and Network Specialist
Belgacom CIS/SCC/FVC
Tel: +32 2 202 1035
Tel: +32 2 207 9032
Email : [email-masked]<mailto:[email-masked]>

From: sipcore [mailto:[email-masked]] On Behalf Of Andrew Allen
Sent: Thursday 5 February 2015 15:29
To: Ivo Sedlacek; [email-masked]
Subject: Re: [sipcore] Precondition and swap of 200 (OK) for INVITE and 200 (OK) for UPDATE
Importance: High

thanks
Andrew

From: sipcore [mailto:[email-masked]] On Behalf Of Ivo Sedlacek
Sent: Tuesday, November 25, 2014 6:20 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [sipcore] Precondition and swap of 200 (OK) for INVITE and 200 (OK) for UPDATE

Hello,

Use case:

               Alice                                        AS

               |                                            |

               |                                            |

               |  ***                                       |

               |  *E*                                       |

               |  *E*                                       |

               |  *R*                                       |

               |  *V*                                       |

               |  *A*                                       |

               |  *T*                                       |

               |  *I*                                       |

               |  *O*                                       |

               |  *N*                                       |

               |  ***                                       |

               |  ***                                       |

               |  ***                                       |

               |                                            |

               |                                            |

               |                                            |

               |                                            |

               Alice                                        AS

               |                                            |

               |                                            |

               |  ***                                       |

               |  *E*                                       |

               |  *E*                                       |

               |  *R*                                       |

               |  *V*                                       |

               |  *A*                                       |

               |  *T*                                       |

               |  *I*                                       |

               |  *O*                                       |

               |  *N*                                       |

               |  ***                                       |

               |  ***                                       |

               |  ***                                       |

               |                                            |

               |       |                                    |

               |       |                                    |

               |<------+                                    |

In my opinion:

Any views?

Kind regards

Ivo Sedlacek

________________________________

***** Disclaimer *****
http://www.proximus.be/maildisclaimer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 05 Feb 2015 11:07:58 -0500

I think Adam's response makes sense.

But I'll also note that the relationship of preconditions to alerting 
affect the callee, not the caller. If the callee chooses to answer 
before alerting would have been enabled, that is its decision, and we 
probably shouldn't second guess that.

Also, for the use case described the audio is all expected to be from 
the AS to Alice. That can occur as soon as the media has been reserved 
in that direction, whether it has been established in the other direction.

In Ivo's original post he only mentioned one possible outcome. What 
other possible outcomes were considered? You must ACK the 200. ISTM that 
Alice's only choices are:
- process the incoming media (if it arrives)
- discard the incoming media if it arrives
- immediately send a BYE (but still do one of the above.)

The AS did have an alternative that could circumvent this: it could 
await the response to the UPDATE before sending the 200 to the invite.

	Thanks,
	Paul

---

From: Ivo Sedlacek <[email-masked]>
Date: Thu, 5 Feb 2015 17:05:27 +0000

Hello,

> The problem probably remains the same: Alice will receive the weather forecast according to SDP1 till message 6 is received and then receive the weather forecast according to SDP3.

Alice will receive the weather forecast according to SDP3 since AS starts sending the weather forecast upon being informed that resources are reserved at originating side  which is in SDP3 (AS already has its own resources).

However, Alice will send any media towards AS (assuming a=sendrecv is negotiated) according to SDP2 between reception of message 7 and reception of message 6, and upon reception of message 6, Alice will start sending any media towards the AS according to SDP4.

Kind regards

Ivo

This Communication is Confidential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer<http://www.ericsson.com/email_disclaimer>
From: VAN GEEL Jan (SPC/CSP) [mailto:[email-masked]]
Sent: 5. února 2015 15:57
To: Andrew Allen; Ivo Sedlacek; [email-masked]
Subject: RE: [sipcore] Precondition and swap of 200 (OK) for INVITE and 200 (OK) for UPDATE

Kind regards

Jan Van Geel

thanks
Andrew

Hello,

Use case:

               Alice                                        AS

               |                                            |

               |                                            |

               |  ***                                       |

               |  *E*                                       |

               |  *E*                                       |

               |  *R*                                       |

               |  *V*                                       |

               |  *A*                                       |

               |  *T*                                       |

               |  *I*                                       |

               |  *O*                                       |

               |  *N*                                       |

               |  ***                                       |

               |  ***                                       |

               |  ***                                       |

               |                                            |

               |                                            |

               |                                            |

               |                                            |

               Alice                                        AS

               |                                            |

               |                                            |

               |  ***                                       |

               |  *E*                                       |

               |  *E*                                       |

               |  *R*                                       |

               |  *V*                                       |

               |  *A*                                       |

               |  *T*                                       |

               |  *I*                                       |

               |  *O*                                       |

               |  *N*                                       |

               |  ***                                       |

               |  ***                                       |

               |  ***                                       |

               |                                            |

               |       |                                    |

               |       |                                    |

               |<------+                                    |

In my opinion:

Any views?

Kind regards

Ivo Sedlacek

***** Disclaimer *****

---

From: Ivo Sedlacek <[email-masked]>
Date: Thu, 5 Feb 2015 17:28:27 +0000

Hello,

in the case below, mandatory preconditions are used.

> One approach would be avoiding the entire problem by formalizing the "the
> callee will not be alerted until all the mandatory preconditions are met" to
> a protocol mechanism: "the callee MUST send a reliable provisional response
> after the conditions are met and MUST receive acknowledgement of that
> response before sending a 200-class response to the INVITE."

There is a theoretical chance of Alice receiving 200 response for INVITE BEFORE 200 response for UPDATE.

And there is also a realistic chance of Alice receiving the reliable provisional response for INVITE BEFORE 200 response for UPDATE.

> The other approach would be to treat this the same as "preconditions sent in
> the middle of an ongoing session," in which case the UAs use the "old
> session" (which, in this case, is no session at all) until the mandatory
> preconditions are met. In other words, for your call flow, the session
> wouldn't take effect on receipt of the INVITE 200, but only on receipt of the
> UPDATE 200.

Not sure I understand.

From my point of view, regular offer/answer and regular UAC INVITE state machine and UAC non-INVITE state machine apply.

I.e. in Alice:

- 200 for INVITE causes session establishment (media is sent accord to last completed SDP offer/asnwer round).

- 200 for UPDATE causes switch of media sending from SDP2 to SDP4

Kind regards

Ivo Sedlacek

---

From: Adam Roach <[email-masked]>
Date: Tue, 10 Feb 2015 10:59:28 -0600

> in the case below, mandatory preconditions are used. 
....
>
> From my point of view, regular offer/answer and regular UAC INVITE 
> state machine and UAC non-INVITE state machine apply.
>
> I.e. in Alice:
>

If you want to think of it that way, then you need to keep in mind that 
SDP2 in your example contains unmet mandatory preconditions. This means 
that it cannot be used for media. This might technically be a 
distinction, but it's not a difference: the session still isn't usable 
until SDP4 arrives.

/a

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 11 Feb 2015 06:58:35 +0000

Hi,

I agree with Ivo and Adam, and I don't think there is a disagreement on what has been discussed.

However, as far as I know, what brought this issue up was the fact that some UAs, if they receive the 200 (INVITE) before 200 (UPDATE), don't accept it and *RELEASE* the session establishment. In my opinion that is wrong (and shows that someone probably has implemented call flows rather than specs :)

Or, does someone actually think that releasing the session establishment in this case is correct behavior?

Regards,

Christer

From: sipcore [mailto:[email-masked]] On Behalf Of Adam Roach
Sent: 10. helmikuuta 2015 18:59
To: Ivo Sedlacek; Andrew Allen; [email-masked]
Subject: Re: [sipcore] Precondition and swap of 200 (OK) for INVITE and 200 (OK) for UPDATE

I.e. in Alice:

If you want to think of it that way, then you need to keep in mind that SDP2 in your example contains unmet mandatory preconditions. This means that it cannot be used for media. This might technically be a distinction, but it's not a difference: the session still isn't usable until SDP4 arrives.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 11 Feb 2015 09:40:01 -0500

On 2/11/15 1:58 AM, Christer Holmberg wrote:
> However, as far as I know, what brought this issue up was the fact that
> some UAs, if they receive the 200 (INVITE) before 200 (UPDATE), don't
> accept it and *RELEASE* the session establishment. In my opinion that is
> wrong (and shows that someone probably has implemented call flows rather
> than specs :)
>

IMO that is certainly a *poor* implementation - one I would reject in a 
product I was buying. But is it a violation of the specification? 
Probably not - AFAIK it is never *wrong* to end a session because that 
is a policy decision.

(This assumes that the session is ended properly: every transaction must 
complete, and a BYE needs to be sent.)

	Thanks,
	Paul

> Regards,
>
> Christer
>
> *From:*sipcore [mailto:[email-masked]] *On Behalf Of *Adam Roach
> *Sent:* 10. helmikuuta 2015 18:59
> *To:* Ivo Sedlacek; Andrew Allen; [email-masked]
> *Subject:* Re: [sipcore] Precondition and swap of 200 (OK) for INVITE
> and 200 (OK) for UPDATE
>
>     - 200 for INVITE causes session establishment (media is sent accord
>     to last completed SDP offer/asnwer round).
>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 11 Feb 2015 19:52:39 +0000

Hi,

>> However, as far as I know, what brought this issue up was the fact 
>> that some UAs, if they receive the 200 (INVITE) before 200 (UPDATE), 
>> don't accept it and *RELEASE* the session establishment. In my opinion 
>> that is wrong (and shows that someone probably has implemented call 
>> flows rather than specs :)
>>
>> Or, does someone actually think that releasing the session 
>> establishment in this case is correct behavior?
>
> IMO that is certainly a *poor* implementation - one I would reject in a product 
>I was buying. But is it a violation of the specification? 
>
> Probably not - AFAIK it is never *wrong* to end a session because that is a policy decision.

Of course - implementations can end a session due to whatever policies.

But, ending a session just because the 200 (INVITE) comes before the 200 (UPDATE) is in my opinion a bad implementation - and eventhough it's not a violation of any spec, there for sure is no spec justifying such behaviour :)

Regards,

Christer

> SDP2 in your example contains unmet mandatory preconditions. This 
> means that it cannot be used for media. This might technically be a

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 12 Feb 2015 23:40:05 -0500

> established since 200 (OK) response is received for INVITE
> request. Alice should send media according to SDP2 as SDP answer to
> SDP3 has not been received yet.
>

It seems to me that you're correct.  Although I would phrase it:  After
receiving message (7), Alice should consider the *dialog* as
establsihed.  At that point, Alice's participation in the *session* is
still governed by SDP1 and SDP2, as the UPDATE has not completed.  After
receiving message (6), Alice's participation in the session is governed
by SDP3 and SDP4.

I don't know preconditions, but I suppose if SDP3/SDP4 contains
preconditions, their going-into-effect may be delayed by the
preconditions.  If SDP1/SDP2 contains preconditions, their
going-into-effect may be delayed, even to the point that they don't go
into effect before SDP3/SDP4 go into effect.

Of course, there are complexities, but they are the usual ones that come
from time-skew between the offer/answer messages and the media packets
-- once Alice has sent SDP3, she needs to be prepared to receive media
according to its specifications, while still expecting to receive media
according to SDP1/SDP2.  But that is the lot of a UA that sends an offer
within a dialog.

And AS doesn't know when Alice will start receiving according to
SDP3/SDP4 alone, because it has no way of knowing when Alice receives
message (6).  But it assumes that Alice is already listening based on
SDP3 as well as SDP1.  But that is the lot of a UA that accepts an offer
within a dialog.

What is not clear to me is what you consider to be a problem.  What
alternative behaviors do people think are possible?

From: Christer Holmberg <[email-masked]>
> wrong (and shows that someone probably has implemented call flows rather

Yuck!

Some implementer has forgotten that messages can be reordered.

Their punishment is that their devices have unstable behavior and buyers
avoid them.

Worse, Alice will observe the same messages in the following case, which
is a simple and quite predictable race condition.

>                |-------------(5) UPDATE SDP3-----------+    |
>                |                                       |    |
>                |                                       +--->|

If Alice wants to avoid situations like that, obviously she has to avoid
sending UPDATE on an early dialog.

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Sun, 15 Feb 2015 22:10:32 -0500

> wrong (and shows that someone probably has implemented call flows rather

And this is really bizarre -- if a UA sends a second request while a
first request is outstanding, obviously the UA can't predict which
request will be completed first.

Dale