Subject: [Sipping] interworking(1/2) of INVITE and UPDATE

From: OKUMURA Shinji <[email-masked]>
Date: Thu, 22 Apr 2010 17:23:12 +0900

Hi all,

At this chance, I want to hear your opinion about the
interworking of INVITE and UPDATE.

This is related to chapter 4 in a offeranswer draft,

Regarding "5.1 Sending an UPDATE" of RFC3311, Paul said that
"this language itself is non-normative and is justified as
a corollary of 3261."

I think so, but these descriptions are also very messy.
About the timing when UA can send an UPDATE request,
at last I think as the following,

       A                               B
      *|                               |*
      *|ini/re-INVITE(offer)           |*
       |------------------------------>|
       |                1xx-rel(answer)|
       |<------------------------------|
       |PRACK                          |
       |------------------------------>|
       |                     200(PRACK)|
       |<------------------------------|
      *|                               |*<-- after this pont, UA may
      *|                               |*    send UPDATE with offer
      *|                               |*

       A                               B
      *|                               |*
      *|ini/re-INVITE(no offer)        |*
       |------------------------------>|
       |                 1xx-rel(offer)|
       |<------------------------------|
       |PRACK(answer)                  |
       |------------------------------>|
       |                     200(PRACK)|
       |<------------------------------|
      *|                               |*<-- after this pont, UA may
      *|                               |*    send UPDATE with offer
      *|                               |*

Do you have any questions or comments?

Regards,
Shinji

---

From: [email-masked]
Date: Thu, 22 Apr 2010 17:04:43 +0800

Hi Shinji,

I feel your charts seems the same as RFC3311 and O/A draft.

Could you tell us more about your problem?

Thanks,

Gao

===================================
 Zip    : 210012
 Tel    : 87211
 Tel2   :(+86)-025-52877211
 e_mail : [email-masked]
===================================

[email-masked] 写于 2010-04-22 16:23:12:

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

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: OKUMURA Shinji <[email-masked]>
Date: Thu, 22 Apr 2010 18:42:10 +0900

Hi Gao,

I have two concerns.

1. Section 5.1 seems to describe different rules for each of
   initial INVITE and reINVITE. But I think there is no reason
   why the rules is separated.

2. Section 5.1 seems to say that the timing UA may send UPDATE
   is "after sending or receiving PRACK request". But I think it
   should be "PRACK transaction is completed".
   Because "after-PRACK-request" cause a glare case.

Do you agree?

My proposals regarding section 4 of the draft is based on these.

Thanks,
Shinji

[email-masked]
Thu, 22 Apr 2010 17:04:43 +0800

---

From: [email-masked]
Date: Thu, 22 Apr 2010 18:04:42 +0800

Hi,

>    why the rules is separated.

Yes. Rules for Ini-INVITE and Re-INVITE is in different parts.

But I feel that there's no conflict.

>    Because "after-PRACK-request" cause a glare case.

I think timing of "PRACK transaction is completed" is better.

But it seams that there's no problem for UAS sending UPDATE just after 
receiving PRACK(with out SDP).
If PRACK has SDP, then UAS should not send the UPDATE by O/A rules.

Thanks,

Gao

---

From: OKUMURA Shinji <[email-masked]>
Date: Thu, 22 Apr 2010 19:32:32 +0900

Gao,

[email-masked]
Thu, 22 Apr 2010 18:04:42 +0800
>But I feel that there's no conflict.

Yes, there's no conflict.
But the restrictions for reINVITE is too little.

This is one of the figures in my proposals.

       A                               B
       |                               |
       |                re-INV (offer0)|
       |<------------------------------|
       |1xx-rel (answer0)              |
       |------------------------------>| --+
       |offer1(UPD)         offer2(PRA)| M2| Acknowledge
    M1 |============\  /===============| <-+
       |             \/                |
       |             /\                |
       |<===========/  \==============>|
       |                      491 (UPD)|
       |<------------------------------|
       |                               |

If the INVITE is an intial INVITE, UA A can not send this UPDATE.

>If PRACK has SDP, then UAS should not send the UPDATE by O/A rules.

This is another one of the figures in my proposals.

                   A                               B
                   |                               |
                   |              re-INV (no offer)|
   1st reliable+-- |<------------------------------|
   response    | M1|1xx-rel (offer1)               |
               +-> |==============================>| --+
                   |                   answer1(PRA)| M3| Acknowledge
                   |<===========\  /===============| <-+
                   |             \/                |
                   |             /\     offer2(UPD)|
                   |<===========/  \===============| M2
                   |500 (UPD)                      |
                   |------------------------------>|
                   |2xx-PRA                        |
                   |------------------------------>|
                   |                               |

This is a message crossing case.

Regards,
Shinji

---

From: [email-masked]
Date: Thu, 22 Apr 2010 19:32:43 +0800

Hi,

> This is one of the figures in my proposals.

Yes. There's no such consistency for Ini-INVITE and Re-INVITE. 

>    response    | M1|1xx-rel (offer1)               |

The 500 is always with retry. So, B could re-send the UPDATE later.

But, I am not oppose to the clarification or fixing you suggested.

Thanks,

Gao