HI Venkatesh, I was wrong in telling that it is NOT a proxy functionality to send CANCEL requests according to your scenario.
But, Proxy can send CANCEL in two cases 1. When final response is forwarded, and there are client transactions pending for this response context, then CANCEL has to be sent to all client transactions. /* I considered only this and said like that */ 2. From Section 16.10 of RFC 3261. /* I missed this point */ A stateful proxy MAY generate CANCEL requests for pending INVITE client transactions based on the period specified in the INVITE's Expires header field elapsing. However, this is generally unnecessary since the endpoints involved will take care of signaling the end of the transaction. As one could see, the second case applies to your case. But, what I meant by B2BUA functionality was like your "proxy" should be acting like a UAS and UAC for your scenario. And also, by seeing the scenario it is evident that the "proxy" is "STATEFUL". "Stateless" proxy ONLY forwards the requests/responses. As any non-2xx response is handled per transaction as pointed out by Bob and Dale, so the proxy MUST send the ACK. (since it is Stateful, i.e., it is maintaining transactions. I would assume "487" from B would travel till A, if the proxy still maintains the "server-side context" for this "response". Else it would be eaten up by the proxy itself. (as Dale pointed out) Best Regards, Vasu -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Manjunath Vasudeva (IFIN SW WL) Sent: Thursday, May 04, 2006 4:00 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [email protected] Subject: Re: [Sip-implementors] question on the behavior of 487 message. Hi Venkatesh, By the functionality of what you have described for your "Proxy", it is apparent that it is NOT a proxy functionality. Rather it is a B2BUA logic. So, the problem is with the B2BUA logic in the Ondo SIP server. At least that holds good for the case for Sending CANCEL. Cross-check to see whether the Ondo SIP server is really a B2BUA or proxy. In case of creating a call, if it is 1. B2BUA then, new INVITE would be sent out. 2. Proxy then, the old INVITE is forwarded. (with some header addition, as Via, Record-Route, etc.,) Proxy's responsibility is just to "forward" the requests/responses to the next "closer" party. Also it can enforce policies (e.g. Authentication and Authorization). Please refer below from 3261. Proxy, Proxy Server: An intermediary entity that acts as both a server and a client for the purpose of making requests on behalf of other clients. A proxy server primarily plays the role of routing, which means its job is to ensure that a request is sent to another entity "closer" to the targeted user. Proxies are also useful for enforcing policy (for example, making sure a user is allowed to make a call). A proxy interprets, and, if necessary, rewrites specific parts of a request message before forwarding it. Best Regards, Vasu -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, May 04, 2006 12:59 PM To: Venkatesh Joshi Cc: [email protected] Subject: Re: [Sip-implementors] question on the behavior of 487 message. Hi Venkatesh, Proxy should "generate" an ACK on receiving the 487 from B (and send it to B) and it should forward 487 to its next hop ( Which may be the final recepeint i.e in your case its A, or another proxy).And whichever recieves 487 should send ACK to sender. Thanks and Regards, Santosh Venkatesh Joshi <[EMAIL PROTECTED]> 05/04/2006 12:43 PM To Santosh Yatnatti/BLR/[EMAIL PROTECTED] cc [email protected] Subject Re: [Sip-implementors] question on the behavior of 487 message. Hi Santosh, Thanks a ton! A follow-up question - Does the sip proxy "generate" an ACK on receiving the 487 from B ? Or does it "forward" the ACK sent by A (which sends the ACK on receiving the 487) ? The issue is that in the the product on which I am working, the requirement is that we should intercept the 487 that comes from the proxy to A. We should not let the 487 reach A. Hence, I am wondering if we should also send an ACK on behalf of A after receiving (and dropping) the 487 destined to A. thanks, Venkatesh [EMAIL PROTECTED] wrote: > > Hi Venkatesh, > > Ideally proxy should send ACK for 487 Request Terminated. > It seems like Ondo Sip server is misbehaving. > > > > Thanks and Regards, > Santosh > > > > > > > *Venkatesh Joshi <[EMAIL PROTECTED]>* Sent by: > [EMAIL PROTECTED] > > 05/04/2006 11:11 AM > > > To > [email protected] cc > Venkatesh Joshi <[EMAIL PROTECTED]> Subject > [Sip-implementors] question on the behavior of 487 message. > > > > > > > > > Hi, > > I have the following requirement: > > A calls B. If B doesn't answer the call within a configurable period of > time, we should > disconnect the call. > > For this, we send a 480 message to A and a CANCEL message to B. The flow > sequence of > messages is like: > > A Proxy > <---------------- (480 not available) > (ACK) ----------------> > > > Proxy B > (CANCEL) --------------------> > <-------------------- (200 OK) > <-------------------- (487 Terminated) > (ACK) ---------------------> [NOT BEING SENT] > > However, the problem is that multiple "487 Request Terminated" messages > are coming from B. > > I think this is because the proxy doesn't send the ACK for the 487 > message at all. Is this the normal behavior ? I am using the Ondo Sip > server. > > thanks, > Venkatesh > > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > > *********************** FSS-Unclassified *********************** *********************** FSS-Unclassified *********************** _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
