Re: [Sip-implementors] Sending BYE before ACK (not discussed yet!!!)

Tue, 23 Sep 2003 07:00:41 -0700



Oleksandr Sakada <[EMAIL PROTECTED]> wrote:
 
----- Original Message -----
Sent: Tuesday, September 23, 2003 2:26 PM
Subject: Re: [Sip-implementors] Sending BYE before ACK (not discussed yet!!!)



"Nataraju A.B." <[EMAIL PROTECTED]> wrote:
 
----- Original Message -----
Sent: Tuesday, September 23, 2003 4:13 PM
Subject: RE: [Sip-implementors] Sending BYE before ACK (not discussed yet!!!)

franz,
  This is in context with the forking proxy, so yes, when here proxy is receiving multiple 200's for multiple parties. Now it accepts the first 200 which comes its way. Now for other forked request it should be sending a CANCEL, but that is only if it has not got any final response.
  So now while the proxy is trying to generate CANCEL's for the other request, you already 200's coming in (so the sender's r expecting an ACK back for this). If during this time you send out a CANCEL, then you might get a bad response back (not expecting this request at this point).
  So i guess you stil have to ACK those fork's and send immediately BYE' all of them..
 
[Nataraju A.B.] You can't generate a cancel on the transaction where you did not receive any provisional responses.
[Rama] That is a given that a CANCEL is always after a provisional response.
 
Also in the case where you receive a 200(INV) after u have sent the CANCEL 200 will be forwarded towards UAC. Then UAC will decide whether to keep all teh dialogs or terminate some of them.
[Rama] Why would 200's be sent to UAC. When its the proxy which is forking to find out which UAS can serve this request and thus from whereever its gets the first favourable (200 class) response it will accept that (fwd the 200 to the UAC). Others it will cancel on its own, why does it have to send that to UAC? Now UAC you are saying will have multiple 200 responses.. which would be confusing,, that should not be the case. The other legs should be taken care by the proxy itself..
[Oleksandr] Multiple 200 responces will be confusing? What about 16.7 Step 5 (spec 3261): "This step combined with the next, ensures that a statefull proxy will forward ... or one or more 2xx responces to an INVITE request"
[rama] Stateful proxy does seem to fwd all the 2xx response back to the UAC (as in spec), which i still believe should not be the case and the other final responses should be shot down at the proxy.
 
also note : from (16.7 /10 pt)...
         The requirement to CANCEL pending client transactions upon forwarding a final response does not guarantee that an endpoint will not receive multiple 200 (OK) responses to an INVITE.  200 (OK) responses on more than one branch may be generated before the CANCEL requests can be sent and processed.  Further, it is reasonable to expect that a future extension may override this requirement to issue CANCEL requests.
 
rama


Franz Edler <[EMAIL PROTECTED]> wrote:

Hello,

 

I am at the moment working through RFC 3261, and therefore I am interested in taking part in discussing your question. I hope you don�t mind that.

My view is the following:

 

According to RFC 3261 16.7  (Response Processing of a Proxy) step 10 requires the proxy to immediately generate CANCEL requests for all pending client transactions.

These CANCEL requests will terminate the transactions to C and D. So it is very unlikely, that other 200 OK will be forwarded to the A.

But if this is the case (more than one 200 OK received by A in case of a race condition at the proxy), than the proxy will also to CANCEL the pending client transaction.

If A sends ACK and BYE it might generate a 481 Transaction Does not Exist.

 

This is my view. Please tell me, if I am wrong.

 

Franz

 

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ramachandran Iyer
Sent: Dienstag, 23. September 2003 10:55
To: Oleksandr Sakada; [EMAIL PROTECTED]
Subject: Re: [Sip-implementors] Sending BYE before ACK (not discussed yet!!!)

 

Once you have accepted the the transaction from B (200 OK), you will have to cancel the other forked request.

As you say, what if one gets 200 from others as well (C, D in your case). To comply with the spec, the other side would expect ACK for a final response (200 ok). So you will have to send ACK (as it is late to send a CANCEL at this point..) . After having done that, you can immediately send out BYE's to the other legs (C, D) to take down those connections.

 

Rama



Oleksandr Sakada <[EMAIL PROTECTED]> wrote:

Hi!

I saw a lot of discussions regarding sending of BYE request in the archive of this discussion list, but my question is different.
Assume the following scenario:

INVITE
A -------------> B, C, D (forking)

200 OK
A <------------- B, C, D

At this point A has to acknowledge the first received 200 OK (let it be from B) responce and terminate others dialogs:

ACK
A --------------> B

Here is the question. Should A send ACK requests also to the C and D and after that immediately send a BYE request to C and D, or
just send BYE request to C and D after received second and third 200 OK response? In the first case if ACK will not be delivered to
the C and D, the situation will look like the second scenario...

Thank you in advance.

_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software

Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software

_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Reply via email to