Hi Markus,
I think you understand so far and I can follow. I was thinking that the
Hello,
thank you for the discussion.
I think there is a misunderstanding. The UAC has only one Client Transaction (sending one INVITE) after sending the INVITE, but the proxy has after forking one Server Transaction (receiving one INVITE) and two Client Transaction (forking the INVITE, sending two INVITE).
After the 200 OK is received by the UAC this CT goes from PROCEEDING into the state TERMINATED. In my understanding there is no way to cancel the early dialog, because the CT is destroyed. The situation is now no CT, an early dialog and a confirmed dialog, which is handled by the core.
The proxy has now one CT with an early dialog, which the proxy can cancel by itself (CT and ST are destroyed throught the 200 OK and the further handling is in the proxy core). If the CANCEL request was succesful or a not succesful response is received there is no reason to forward the response. The 487 will not forwarded to the UAC because the CT is destroyed. Did I understand this right so far and can you follow me? Or did I understand something wrong?
proxy would forward the 487 response to the UAC, but I now see that it
shouldn't. Not because the CT is destroyed, but because the ST is now
destroyed (plus one of the CTs, the other still remains). Section 16.7 says
to forward any responses for which no clienttransaction is found
statelessly, which was confusing me. The CT still exists to catch the 487
and prevent it from going to the UAC, since RFC section 15 states that
If an initial INVITE generates a non-2xx final response, that terminates
all sessions (if any) and all dialogs (if any) that were created
through responses to the request.In other words, when the UAC would
receive the 487 for the second dialog according to this it should also
terminate the first one, which is probably not what you want. So the proxy
should prevent this 487 from propagating to the UAC, in which case the timer
remains to terminate the early dialogs at the UAC side.
You're right, with emphasis on ~all~ here. For the remaining early dialogs I
Somebody wrote that 13.2.2.4 is the right place to clean up an early dialog and I found what I am looking for:
The UAC core considers the INVITE transaction completed 64*T1 seconds after the reception of the first 2xx response. At this point all the early dialogs that have not transitioned to established dialogs are terminated. Once the INVITE transaction is considered completed by the UAC core, no more new 2xx responses are expected to arrive.
can see 3 options:
1) UAC does not send any request (i.e. it relies on the proxy that was
forking)
2) UAC sends CANCEL (with INVITE branch-id and no to-tag, UAS of existing
call will return 'transaction does not exist')
3) UAC sends BYEs (each one as a new client transaction, with proper to
tags)
CANCEL is probably not a good idea, the UAC would be indicating that it's
abandoning the existing call alltogether. Moreover, since at the proxy the
ST has terminated a (hop-by-hop) CANCEL would not have much use (and trigger
a 481).
My vote would go to sending BYEs, which the proxy - if it record-routed the INVITE - will treat as new, unrelated requests (it may create a new ServerTransaction for each, or it could forward them statelessly). The BYE would be sent on the routeset from the dialog. Only condition is that the UAC must have received a contact URI to send the BYE to, else how would the request be routed to the right UAS?
On the other side I would be interested what would be the right behaviour if a BYE will received by the UAS which has created an early dialog. If the proxy was succesful with its CANCEL, no dialog will established and a 481 Call/Transaction does not exist will be the answer. But if the BYE receives in the CT state PROCEEDING, what will the UAS answering? 491 Pending Call because an early dialog is found but will this BYE destroy the server transaction of the UAS and the appropreate client transaction by the proxy?
No, I think it should reply 200 OK to the BYE and 487 to the pending INVITE (RFC3261 section 15.1.2) The UAS MUST still respond to any pending requests received for that dialog. It is RECOMMENDED that a 487 (Request Terminated) response be generated to those pending requests.
_______________________________________________ Sip-implementors mailing list [email protected] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
