inline... Markus Hofmann <[EMAIL PROTECTED]> wrote: Hi Rama,
now I'm understanding what you mean but that's not what I want to know This is the scenario: ------ INVITE -----> <------ 180 ------- ---- CANCEL -----> <--200 OK for INVITE --- <-- 200 OK for CANCEL --- --- ACK --> xxx ------ BYE ------> <----- 200 OK --- >>> I can see that you have a over-the-wire problem, which is when CANCEL is >>> being sent, a final response for INVITE is already sent. But i dont >>> understand the 200 for CANCEL, b'cos if 200 for INVITE is sent, then CANCEL >>> should not be OK'd.. is should be some other reject cause (4xx or >>> something).. A CANCEL request was failed. I have a conncetion but I don't want this connection. So after the ACK I send immediatly a BYE. But the ACK is lost. What should I do now on the UAS side? >>> OK.. CANCEL failed... fine... and ACK dint reach for some reason on the >>> other side. I guess my previous explanation still holds good for the UAS >>> side when a BYE comes in. Greeting Markus ----Urspr�ngliche Nachricht (HTML) wurde als Anlage beigef�gt.----- Von: Ramachandran Iyer Gesendet: 31.05.05 07:02:55 An: "Markus Hofmann" Betreff: Re: [Sip-implementors] loosing ACK but sending immediatly a BYE __________________________________________________________ Mit WEB.DE FreePhone mit hoechster Qualitaet ab 0 Ct./Min. weltweit telefonieren! http://freephone.web.de/?mc=021201 -----Urspr�ngliche Nachricht wurde als Attachment angeh�ngt.----- Von:Ramachandran Iyer Gesendet:31.05.05 07:02:55An:"Markus Hofmann" <[EMAIL PROTECTED]>Betreff:Re: [Sip-implementors] loosing ACK but sending immediatly a BYEIts a nice question acatually.. Let me try to explain it... practically.... what should happen is..in a typical session ---INVITE ----> <---200-------- ------ACK------> This will establsih the session and then a BYE would take it down (wiht a 200 response for it).. Now lets take ACK, its been sent by the UAC,for the 7 time max re-tried,which it will do to quench the 200 re-trans,,, but for some reason the ACK is never reching the term side. So all 200's will be exhausted,, and finally teh 200's will also stop.. So now from UAC's stand point it has tried sending ACK how much ever time it could.. but to no avail,now it wants to take down the connection with a BYE.. and thats what it will send.. for the UAS,, it would actually be expecting an ACK,, which never came,, so it has to only assume that it must have been lost or something.. bcos there was answer's for its 200 re-trans.. hence has to accomodate the BYE with a 200 and take down the connection. hope it explains,, this are practical issues which crop up,, Rama Markus Hofmann <[EMAIL PROTECTED]> wrote: -----Urspr�ngliche Nachricht (HTML) wurde als Anlage beigef�gt.----- Von: Ramachandran Iyer Gesendet: 30.05.05 13:04:52 An: "Markus Hofmann" Betreff: Re: [Sip-implementors] loosing ACK but sending immediatly a BYE Sorry Rama, I can't understand your answer. You mean that it is ok to send a 200 OK for the BYE and you will stop the retransmission of the ACK Timer. The UAS will not send more 200 OK for the INVITE and will never receive an ACK for the INVITE Server transaction. Is this right? Greeting Markus __________________________________________________________ Mit WEB.DE FreePhone mit hoechster Qualitaet ab 0 Ct./Min. weltweit telefonieren! http://freephone.web.de/?mc=021201 -----Urspr�ngliche Nachricht wurde als Attachment angeh�ngt.----- Von:Ramachandran Iyer Gesendet:30.05.05 13:04:52An:"Markus Hofmann" <[EMAIL PROTECTED]>Betreff:Re: [Sip-implementors] loosing ACK but sending immediatly a BYEinline.. Markus Hofmann <[EMAIL PROTECTED]> wrote: Hello, I have following scenario: UAC UAS | | | ----------- INVITE ---------> | | <---------- 200 OK ---------- | | ------- ACK --> xxx | | ----------- BYE ------------> | | <-----------200 OK (?)------ | | | The ACK will be lost but the BYE will be send immediately after the ACK (for example a CANCEL fails). The UAS receives the BYE, what should the UAS do now? [Rama] I think since BYE and ACK are from teh same party(Orig) and when is Orig explicit in its taking down the connection, so the Term should take it , b'cos there can always be the case of N/W down/congestion b'cos of which ACK could never make it. 200 for Bye is fine. Is a 200 OK for the BYE all right, because a dialog is found and should destroy its dialog and not send further 200 OK for the INVITE to get an ACK. Or should the UAS wait until it receives an ACK and than responds the BYE? Or should the UAS answers with a error code? In my opinion the RFC says nothing about the scenario. Thank you in advance. Markus ______________________________________________________________ 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 __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Sip-implementors mailing list [email protected] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
