From: Nina Garaca <[EMAIL PROTECTED]>
A B
INVITE
|<--------------------------------------|
180 (with To tag)
|-------------------------------------->| /Early dialog established/
UPDATE
|-------------------------------------->|
408/481
|<--------------------------------------|
???
|-------------------------------------->|
/RFC 3261/15 says:/
/ The caller's UA MAY send a BYE for either/
/ confirmed or early dialogs, *and the callee's UA MAY send a BYE on*/
/* confirmed dialogs, but MUST NOT send a BYE on early dialogs.*/
/* However, the callee's UA MUST NOT send a BYE on a confirmed dialog*/
/* until it has received an ACK for its 2xx response or until the server*/
/* transaction times out. */
/RFC 3311/5.3 //says:/
/If a UA receives a non-2xx final response to a UPDATE, the session/
/ parameters MUST remain unchanged, as if no UPDATE had been issued./
/ Note that, as stated in Section 12.2.1 of RFC 3261
<http://tools.ietf.org/html/rfc3261#section-12.2.1> [1
<http://tools.ietf.org/html/rfc3311#ref-1>], *if the non-*/
/* 2xx final response is a 481 (Call/Transaction Does Not Exist), or a*/
/* 408 (Request Timeout), or no response at all is received for the*/
/* UPDATE (that is, a timeout is returned by the UPDATE client*/
/* transaction), the UAC will terminate the dialog.*/
Q1: The question is, how can UA (that is callee/hasn't initiated dialog)
that has sent the UPDATE, terminate the dialog, when that /*UA MUST NOT
send a BYE*/?
Q2: What is the solution of this situation?
Clearly, A cannot send a BYE, but it can otherwise discard its
knowledge (and user interfact presentation) of the dialog.
If A receives 481, it knows that B has lost knowledge of the (early)
dialog (perhaps because some other fork has returned 2xx), or that the
180 was lost. As far as I can tell from RFC 3311, section 4, para. 3,
if B did not receive the 180, it is required to reject the UPDATE with
481. RFC 3311 prescribes that A terminate the dialog, but it seems to
me that it could resend the 180 and try the UPDATE again. In
practice, A should use 100rel, and only send UPDATE when it has
received a PRACK showing that B has established the early dialog.
If A receives 408, RFC 3311 says that it must terminate the dialog,
but that seems overly strict, and I think that it should retry the
UPDATE a couple of times.
Dale
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
