[EMAIL PROTECTED] wrote:
Hi,
Sorry for incorrect SIP trapezoid.
Following is the correct SIP trapezoid.
INVITE UAC -----------------------------------------------------> UAS
180 ( early dialog established ) UAC <----------------------------------------------------- UAS
UPDATE or OPTION ( Request within the early dialog ) UAC ------------------------------------------------------> UAS
486 ( BUSY ) negative response for call UAC <------------------------------------------------------ UAS
ACK UAC ------------------------------------------------------> UAS
Now the early Dialog should be terminated. But wherther we have to remove the Request with in the early dialog while terminating the early dialog ??
Since RFC is not talking anything about the request within the early dialog.
12.3 Termination of a Dialog: "if a request outside of a dialog generates a non-2xx final response, any early dialogs created through provisional responses to that request are terminated."
Regards, Thangarajan.
The exact timing of actions within the server is indeterminate. This provides some lattitude for different behavior by the server that must be considered valid.
This is certainly the case with OPTIONS. While the options can be sent within the dialog, it is unrelated to either the dialog or the dialog usage of the INVITE. You could imagine that it might not be processed until after the 486 is determined to be the result of the invite. In that case, it is possible that the early dialog usage and corresponding dialog have been destroyed. In that case, the OPTIONS might be considered to reference an undefined dialog and so fail. Alternately, you can imagine that the OPTIONS was validated before the dialog ends, in which case it might succeed even if the result is sent after the 486. Both seem to be valid results.
The UPDATE case may be slightly different, because UPDATE is dependent on the invite dialog usage. I would hope that if the result is sent after the 486 that it would be a error response. Doing otherwise would be nonsense. But if the UPDATE is answered before the 486 is sent it could certainly succeed.
Paul
Paul Kyzivat <[EMAIL PROTECTED] om> To [EMAIL PROTECTED] 02/22/05 10:03 PM cc [email protected] Subject Re: [Sip-implementors] Request within the early dialogs
[EMAIL PROTECTED] wrote:
Hi,
INVITE UAC -----------------------------------------------------> UAS
180 ( early dialog established ) UAC <----------------------------------------------------- UAS
NOTIFY Request within the early dialog UAC ------------------------------------------------------> UAS
486 ( BUSY ) negative response for call UAC ------------------------------------------------------> UAS
ACK UAC ------------------------------------------------------> UAS
Now the early Dialog should be terminated. But wherther we have to remove the Notify request with in the early
dialog
while terminating the early dialog ??
The above is incorrect. The NOTIFY must not be sent without a previously established subscription. To be valid the UAS would first have to send a SUBSCRIBE within this dialog.
There are other suble issues even in that case. But lets first figure out if you are talking about something that could be legal.
Paul
Since RFC is not talking anything about the request within the early dialog.
12.3 Termination of a Dialog: "if a request outside of a dialog generates a non-2xx final response, any early dialogs created through provisional responses to that request are terminated."
Regards, Thangarajan.
*********************** HSS-Private *********************** "DISCLAIMER: This message is proprietary to Hughes Software Systems
Limited
(HSS) 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. HSS 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] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
*********************** HSS-Private *********************** "DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) 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. HSS 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] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
