Subject: [Sipping] UPDATE with offer

From: OKUMURA Shinji <[email-masked]>
Date: Wed, 10 Sep 2008 19:03:35 +0900

Hi,

I have any questions about sending offer by UPDATE request.

RFC3311/5.1 Sending an UPDATE says,

   The rules for inclusion of offers and answers in SIP messages as
   defined in Section 13.2.1 of RFC 3261 still apply.  These rules exist
   to guarantee a consistent view of the session state.  This means
   that, for the caller:

      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.

      o  If the UPDATE is being sent before completion of the initial
         INVITE transaction, and the initial INVITE did not contain an
         offer, the UPDATE can contain an offer if the callee generated
         an offer in a reliable provisional response, and the UAC
         generated an answer in the corresponding PRACK.  Of course, it
         can't send an UPDATE if it has not received answers to any
         other offers it sent in either PRACK or UPDATE, or has not
         generated answers for any other offers it received in an UPDATE
         from the callee.

      o  If the UPDATE is being sent after the completion of the initial
         INVITE transaction, it cannot contain an offer if the caller
         has generated or received offers in a re-INVITE or UPDATE which
         have not been answered.

According to the description above, The following scenarios seem
to be allowed.(before sending PRACK)

    A                               B
    |                               |
    |ini-INVITE (offer0)            |
    |------------------------------>|
    |                               |
    |              1xx-rel (answer0)|
    |<------------------------------|
    |                               |
    |UPDATE (offer1)                |
    |==============================>|
    |                               |

    A                               B
    |                               |
    |re-INVITE (offer0)             |
    |------------------------------>|
    |                               |
    |              1xx-rel (answer0)|
    |<------------------------------|
    |                               |
    |UPDATE (offer1)                |
    |==============================>|
    |                               |

    A                               B
    |                               |
    |re-INVITE (no offer)           |
    |------------------------------>|
    |                               |
    |UPDATE (offer1)                |
    |==============================>|
    |                               |

   and for the callee:

      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.

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

      o  If the UPDATE is being sent after the completion of the initial
         INVITE transaction, it cannot be sent with an offer if the
         callee has generated or received offers in a re-INVITE or
         UPDATE which have not been answered.

According to the description above, The following scenarios seem
to be allowed.(before receiving PRACK)

    A                               B
    |                               |
    |             re-INVITE (offer0)|
    |<------------------------------|
    |                               |
    |1xx-rel (answer0)              |
    |------------------------------>|
    |                               |
    |UPDATE (offer1)                |
    |==============================>|
    |                               |

    A                               B
    |                               |
    |              re-INV (no offer)|
    |<------------------------------|
    |                               |
    |UPDATE (offer1)                |
    |==============================>|
    |                               |

Is my understanding correct?
Some scenarios seem to be allowed only for re-INVITE.
is this what the author intended?
If not, which is not intended scenario?

Regards,
Shinji
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 10 Sep 2008 10:08:11 -0400

Shinji,

I realize I haven't responded to your earlier o/a question.
You have obviously been looking deeply into this subject, and I haven't 
had time to give a studied answer.

The collection of RFCs that touch on offer/answer don't fit together 
perfectly. It takes a lot of "reading tea leaves" to put it all together 
and make sense of it. For the most part it has been concluded that only 
certain usages are valid, because the others lead to inconsistent 
results or violate some aspect of one or more of the RFCs. There was an 
extended discussion of all this on the mailing list some years ago, 
which then faded into folklore. We later realized that such folklore 
needed to be formally recorded, which is what led to the offeranswer draft.

The end result is that if you simply look at one RFC, such as 3311, and 
construct flows that are consistent with it, then you are likely to come 
up with some that aren't workable for some reason not stated in 3311.

> to be allowed.(before sending PRACK)

Your point in the above is that the UPDATE is being sent prior to the 
PRACK, right?

Would you then expect to be able to send yet another offer in the PRACK???

 From B's perspective there is the possibility that there was a PRACK 
and it was lost or delayed. This then gets very complex to interpret. 
IMO this is at least a very bad idea.

>     |re-INVITE (no offer)           |

This clearly can't work. B will be working on generating an offer, so 
this is just inviting a complex glare condition.

So this is certainly a bad practice, if not illegal.

I don't have time right now to dig into all your other cases. But let me 
wrap up for now this way:

The best way we found to resolve all of these alternatives in the o/a 
draft was to reformulate by giving just the patterns that are known to 
be valid. Others, that might seem to be valid according to one of the 
RFCs, are to be avoided.

In retrospect, it would have been better for the RFCs to have been much 
more explicit and constraining.

	Thanks,
	Paul

---

From: "Rockson Li (zhengyli)" <[email-masked]>
Date: Wed, 10 Sep 2008 22:49:09 +0800

Comments in line.

-Rockson

-----Original Message-----
From: [email-masked] [mailto:[email-masked]
<mailto:[email-masked]> ] On Behalf Of OKUMURA Shinji
Sent: Wednesday, September 10, 2008 6:04 PM
To: [email-masked]; [email-masked]
Subject: [Sipping] UPDATE with offer

Hi,

According to the description above, The following scenarios seem to be
allowed.(before sending PRACK)

    A                               B
    |                               |
    |ini-INVITE (offer0)            |

[RL] IMO, this is intended scenario, UPDATE here is used to update
caller's ip address if caller is mobile.

    A                               B
    |                               |
    |re-INVITE (offer0)             |

[RL] this is allowed, however, I seldom see any reliable response used
for re-INVITE.

    A                               B
    |                               |
    |re-INVITE (no offer)           |

[RL] this is subject to race condition. B is probably sending its 200
with its own offer simultaneously,

     so this two offers cross over causing overlapping offer.

   and for the callee:

According to the description above, The following scenarios seem to be
allowed.(before receiving PRACK)

    A                               B
    |                               |
    |             re-INVITE (offer0)|

    A                               B
    |                               |
    |              re-INV (no offer)|

[RL] you can send 200 with offer here instead more naturally, why bother
with UPDATE??

Regards,
Shinji
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
<https://www.ietf.org/mailman/listinfo/sipping> 
This list is for NEW development of the application of SIP Use
[email-masked] for questions on current sip Use
[email-masked] for new developments of core SIP

---

From: "Ian Elz" <[email-masked]>
Date: Wed, 10 Sep 2008 17:42:20 +0200

Shinji,

I have added my comments to those from Rockson - inline.

I am unsure why you are proposing these sequences. If you implement them
you may have interworking issues.

Ian Elz 

System Manager 
DUCI LDC UK 
(Lucid Duck) 

Office: + 44 24 764 35256 
gsm: +44 7801723668 
[email-masked] 

________________________________

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Rockson Li (zhengyli)
Sent: 10 September 2008 15:49
To: OKUMURA Shinji; [email-masked]; [email-masked]
Subject: Re: [Sipping] UPDATE with offer

Comments in line.

-Rockson

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

Hi,

    A                               B
    |                               |
    |ini-INVITE (offer0)            |

[Ian Elz ] In this scenario it would be usual to send the PRACK before
the UPDATE. As you can send a new sdp offer in the PRACK and you have to
send the PRACK why bother with the UPDATE.

    A                               B
    |                               |
    |re-INVITE (offer0)             |

[Ian Elz ] Again this is possible but you could use the PRACK.

    A                               B
    |                               |
    |re-INVITE (no offer)           |

[Ian Elz ] As Rockson says, this would create a race condition for the
sdp. This should not be allowed. The offer answer draft should cover
this. If it doesn't then it should.

   and for the callee:

    A                               B
    |                               |
    |             re-INVITE (offer0)|

[Ian Elz ] In this case you would normally wait for the PRACK as you
don't know that B has received the sdp answer until the PRACK has been
returned. It would be normal to send the 200 OK to the PRACK before the
UPDATE.

    A                               B
    |                               |
    |              re-INV (no offer)|

[Ian Elz ] Technically this is valid but it will appear as a cross over
to B. In this scenario B may send a CANCEL to the re-INVITE as he has
now received the offer he required.   

Regards,
Shinji

---

From: OKUMURA Shinji <[email-masked]>
Date: Thu, 11 Sep 2008 12:18:34 +0900

Hi,

If I implement UA, I would not send the UPDATE request with an offer
unless PRACK transaction is completed.
but other ua may send these UPDATE request. Then my ua should do something.
I think that offer-answer draft would discribe it.

I want to confirm which scenario is appropriate, and which one is illegal.

my comment inline.

Regards,
Shinji

Paul Kyzivat <[email-masked]>
>Your point in the above is that the UPDATE is being sent prior to the 

Yes.

>Would you then expect to be able to send yet another offer in the PRACK???

No, I think following PRACK must not include offer.

>IMO this is at least a very bad idea.

I agree. B may send 4xx(maybe 491) for UPDATE. But is following
sequences illegal ? 

    A                               B
    |                               |
    |ini-INVITE (offer0)            |
    |------------------------------>|
    |                               |
    |              1xx-rel (answer0)|
    |<------------------------------|
    |                               |
    |UPDATE (offer1)                |
    |==============================>|
    |                               |
    |PRACK(no offer)                |
    |------------------------------>|
    |                               |
    |              answer1 (2xx-UPD)|
    |<==============================|
    |                               |

or crossing case

    A                               B
    |                               |
    |ini-INVITE (offer0)            |
    |------------------------------>|
    |                               |
    |              1xx-rel (answer0)|
    |<------------------------------|
    |                               |
    |PRACK(no offer)                |
    |--------------\  /============>|
    |               \/              |
    |offer1(UPD)    /\              |
    |==============/  \------------>|
    |                               |
    |              answer1 (2xx-UPD)|
    |<==============================|
    |                               |
    |                     500(PRACK)|
    |<------------------------------|
    |                               |
    |PRACK(no offer)                |
    |------------------------------>| incremented CSeq
    |                               |
    |                               |

>So this is certainly a bad practice, if not illegal.

Yes, I agree. A should not send this UPDATE, but if B receive it,
B must do something. BCP I think is following,

    A                               B
    |                               |
    |re-INV (no offer)              |
    |------------------------------>| --+
    |                               |   |
    |offer1(UPD)                    |   |
    |==============================>|   | The 1st reliable response
    |                               |   |
    |              answer1 (2xx-UPD)|   |
    |<==============================|   |
    |                               |   |
    |                         offer2|   |
    |                  (1xx-rel/2xx)|   |
    |<------------------------------| <-+ Wait until answer1
    |                               |
    | answer2 (PRACK/ACK)           |
    |------------------------------>|
    |                               |

or crossing case

                A                               B
                |                               |
                |re-INV (no offer)              |
                |------------------------------>| --+
                |                        offer2 |   |
                |offer1(UPD)       (1xx-rel/2xx)|   |
                |============\  /===============| <-+ The 1st reliable response
                |             \/                |
                |             /\                |
                |<===========/  \==============>|
                |                               |
                |                       491(UPD)|
                |<------------------------------|
                |                               |
                | answer2 (PRACK/ACK)           |
 Wait until 491 |------------------------------>|
                |                               |