Dale, You mentioned:
"In practice, I can imagine two implementation scenarios: - The UAS for the original address (or a proxy acting on its behalf) decides that the call should be forwarded. It sends a 181 response (with a new to-tag), and then (acting like a proxy) forwards a copy of the INVITE to the forwarding destination. - The UAS/proxy decides that the call should be forwarded. It sends a 181 response (with a new to-tag), and then sends a 3xx response (probably with the same to-tag as the 181). The next proxy upstream (or the UAC, if there is no intervening proxy) acts on the 3xx to send a copy of the INVITE to the forwarding destination." GK >> Going by what you mentioned, after sending the 181 response, the UAS can either chose to send a 3xx back or it can forward a copy of the original INVITE to the forwarding destination. How does the UAS decide what to do out of the above 2 options? Also, you mentioned "I assume that the reason for this response is that a forwarded call might have a longer set-up time (until a 180 is returned to the UAC) than usual, so the UAS wishes to reassure the UAC that the call is making progress." GK>> I'm not sure the logic of sending a 3xx after a 181 goes too well based on the above statement. If a UAC receives a 181, it already knows that the call is being forwarded. In that case, it would not be expecting a response from the original destination anyway so what value would a 3xx response add? Thanks in advance for your clarification. Regards, Gaurav -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, December 21, 2006 9:16 PM To: [email protected] Subject: Re: [Sip-implementors] Use of 181--Call is being forwarded From: [EMAIL PROTECTED] I don't understand the use of SIP response 181 "Call is being forwarded". 181 is a end-to-end response. And rfc 3261 also says all provisional messages except 100 trying must have "To" tag in the section 8.2.6.2. 181 is used to inform the UAC that the call is being forwarded (by the UAS or some intermediate proxy, I suppose). I assume that the reason for this response is that a forwarded call might have a longer set-up time (until a 180 is returned to the UAC) than usual, so the UAS wishes to reassure the UAC that the call is making progress. The 181 response must have a to-tag. But the UAC can choose its own to-tag for the 181, as (in principal) the 181 is a response to a separate fork of the INVITE than the fork that is being forwarded to its ultimate destination. In practice, I can imagine two implementation scenarios: - The UAS for the original address (or a proxy acting on its behalf) decides that the call should be forwarded. It sends a 181 response (with a new to-tag), and then (acting like a proxy) forwards a copy of the INVITE to the forwarding destination. - The UAS/proxy decides that the call should be forwarded. It sends a 181 response (with a new to-tag), and then sends a 3xx response (probably with the same to-tag as the 181). The next proxy upstream (or the UAC, if there is no intervening proxy) acts on the 3xx to send a copy of the INVITE to the forwarding destination. Either of these achieves the forwarding, and is fully compliant with RFC 3261. Dale _______________________________________________ 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
