Re: [Sip] [Sipping] UPDATE with offer

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
ian.elz at ericsson.com

From: sipping-bounces at ietf.org [mailto:sipping-bounces at ietf.org] On Behalf Of Rockson Li (zhengyli)
Sent: 10 September 2008 15:49
To: OKUMURA Shinji; sip at ietf.org; sipping at ietf.org
Subject: Re: [Sipping] UPDATE with offer

Comments in line.

-Rockson

-----Original Message-----
From: sipping-bounces at ietf.org [mailto:sipping-bounces at ietf.org] On Behalf Of OKUMURA Shinji
Sent: Wednesday, September 10, 2008 6:04 PM
To: sip at ietf.org; sipping at ietf.org
Subject: [Sipping] UPDATE with offer

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
pan>

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

[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)             |
    |------------------------------>|
    |                               |
    |              1xx-rel (answer0)|
    |<------------------------------|
    |                               |
  nbsp;       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)                |
    |==============================>|
    |                               |

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

[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)             |
    |------------------------------>|
    |                               |
    |              1xx-rel (answer0)|
    |<------------------------------|
    |                               |
    | |UPDATE (offer1)                |
    |==============================>|
    |                               |

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

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

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

[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.

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

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

[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:

      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
    p;      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)                |
    |==============================>|
    |                               |

[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.

         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)                |
    |==============================>|
    |                               |

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

[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.

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 sip-implementors at cs.columbia.edu for questions on current sip Use sip at ietf.org for new developments of core SIP