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

[OKUMURA Shinji <shinji.okumura@xxxxxxxxxxxx>]

Gao,

gao.yang2@xxxxxxxxxx
Thu, 22 Apr 2010 18:04:42 +0800
>Hi,
>
>> 
>> 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.
>
>Yes. Rules for Ini-INVITE and Re-INVITE is in different parts.
>
>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.

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

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

>Thanks,
>
>Gao
>
>> 
>> My proposals regarding section 4 of the draft is based on these.
>> 
>> Thanks,
>> 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@xxxxxxxxxxxxxxx for questions on current sip
Use sip@xxxxxxxx for new developments of core SIP