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
