Hi All,
I have query in line with the discussion. As RFC 3261 and RFC 3311
clearly describes the handling of overlap of 2 Re-INVs or 2 UPDATEs
respectively as glare condition, in same way whether overlaping of Re-INV
and UPDATE requests are considered to be glare? Can anybody point to some
specs which speaks about this handling?
Regards,
Manju
****************************************************************************
***********
This e-mail and attachments contain confidential information
from HUAWEI, which is intended only for the person or entity whose address
is listed above. Any use of the information contained herein in any way
(including, but not limited to, total or partial disclosure, reproduction,
or dissemination) by persons other than the intended recipient's) is
prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Paul Kyzivat
Sent: Thursday, November 23, 2006 1:28 AM
To: Benny Prijono
Cc: [email protected]
Subject: Re: [Sip-implementors] Overlapping requests
Benny Prijono wrote:
> Paul Kyzivat wrote:
>> I'm not sure about INFO, but overlap is allowed for NOTIFY.
>> Furthermore, messages belonging to different usages of the same
>> dialog can overlap - e.g. UPDATE and NOTIFY. (Assuming you have
>> multiple usages in the dialog.)
>
> I think UPDATE can never overlap, because there can only be one
> outstanding offer/answer, cmiiw.
While this is true, and UPDATE need not carry an offer or answer.
Paul
> Good point about CSeq below.
>
> -benny
>
>
>> *BUT* overlapping has the potential to get you into trouble except in
>> a few specific cases. The problem is that if the messages get
>> reordered before delivery, then when the second one arrives it will
>> be seen as having a CSeq that is too small, and so will fail. In some
>> limited cases this may be ok. In particular, if you have an event
>> package where each new NOTIFY supercedes the prior one, then all may
>> be well. In all other cases it will be a problem.
>>
>> So in practice it may really be necessary to serialize most messages
>> in a dialog.
>>
>> Paul
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
