Hi Naveen,
But UPDATE can be used as session refresher and Re-INV can be used for
SDP negotiation. In this case there could be overlap.
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!
_____
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 23, 2006 11:50 AM
To: [EMAIL PROTECTED]
Cc: 'Benny Prijono'; 'Paul Kyzivat'; [email protected];
[EMAIL PROTECTED]
Subject: Re: [Sip-implementors] Overlapping requests
Hi manju,
as far as i know the update is used before a dialog is established,
where as a re invite is used to modify parameters after the dialog is
established. so there is no chance of overlap of the two methods.
Thanks & Regards
Naveen Pinto
ARICENT COMMUNICATION SYSTEMS
off: 9180-41069025
mobile: 91-9448481804
Manjunath Warad <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
11/23/2006 11:18 AM
Please respond to
[EMAIL PROTECTED]
To
"'Paul Kyzivat'" <[EMAIL PROTECTED]>, "'Benny Prijono'" <[EMAIL PROTECTED]>
cc
[email protected]
Subject
Re: [Sip-implementors] Overlapping requests
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
*********************** Aricent-Private ***********************
"DISCLAIMER: This message is proprietary to Aricent and is intended solely
for the use of
the individual to whom it is addressed. It may contain privileged or
confidential information and should not be
circulated or used for any purpose other than for what it is intended. If
you have received this message in error,
please notify the originator immediately. If you are not the intended
recipient, you are notified that you are strictly
prohibited from using, copying, altering, or disclosing the contents of this
message. Aricent accepts no responsibility for
loss or damage arising from the use of the information transmitted by this
email including damage from virus."
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
