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? 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. 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? This BYE makes no sense for me. It is the task of the proxy to destroy its CT and the ST of the UAS which did not build up an conncetion. But thank you for your answering. Markus "Jeroen van Bemmel" schrieb am 04.05.05 13:42:25: > > Markus, > > > Do I understand it right, that it is allowed to send a BYE for an early > > dialog from the UAC side? > > > > Imagine following scenario: > > > > UAS sends an INVITE to a proxy. The proxy forks the INVITE and two > > provisional response with different to tags are coming back. One UAS sends > > a 200 OK and the proxy cancels successfuly the INVITE request to the other > > UAS. > > > > The UAC has now a confirmed dialog and an early dialog. MAY the UAC send a > > BYE the the successful canceled UAS? When can the UAC clean up the early > > dialog? > > Shouldn't the proxy send back an error response for the second dialog (to > the UAC), i.e. 487 Request Canceled? This would trigger the UAC to clean > things up > > If the UAC does not get any response, the INVITE clienttransaction will > remain in PROCEEDING state. For robustness the UAC application should > probably define a maximum response time after receiving the first > provisional response, and BYE the dialog if no more responses are received > withini this time > > Regards, > > Jeroen > > _______________________________________________ > Sip-implementors mailing list > [email protected] > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors ______________________________________________________________ Verschicken Sie romantische, coole und witzige Bilder per SMS! Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193 _______________________________________________ Sip-implementors mailing list [email protected] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
