Non-success final responses (3-6xx) and the ACK to those responses are
hop-by-hop. Regardless of whether or not the proxy forwards the non-success
final response upstream toward the UAC, it MUST always send an ACK.
RFC 3261, section 16.7 (page 111) says:
3-6xx responses are delivered hop-by-hop. When
issuing a 3-6xx response, the element is effectively
acting as a UAS, issuing its own response, usually
based on the responses received from downstream
elements.
and section 17.1.1.2 says:
When in either the "Calling" or "Proceeding" states,
reception of a response with status code from 300-699
MUST cause the client transaction to transition to
"Completed". The client transaction MUST pass the
received response up to the TU, and the client
transaction MUST generate an ACK request ...
This applies to proxies as well as UAs.
cheers,
(-:bob
Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
71 Third Avenue
Burlington, MA 01803
[EMAIL PROTECTED]
----- Original Message -----
From: "Dale R. Worley" <[EMAIL PROTECTED]>
To: "Sip-Implementors" <[email protected]>
Sent: Thursday, May 04, 2006 9:30 AM
Subject: Re: [Sip-implementors] question on the behavior of 487 message.
> On Thu, 2006-05-04 at 11:11 +0530, Venkatesh Joshi wrote:
>> 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.
>
> All final responses to INVITEs must receive an ACK, and if the callee
> does not receive the ACK, it is supposed to re-send the final response.
> In this case, your proxy is misbehaving.
>
> In regard to who sends the ACK to the 487, a good rule is to ask "Who
> eats the 487?" (The official rules are stricter that all the behaviors
> people implement, but the "Who eats the resonse?" rule works in a broad
> range of cases.)
>
> In your case, the 487 is "eaten" by the proxy, which itself sends a 480
> upstream. So the proxy should generate the ACK for the 487. If the
> proxy only passed the 487 upstream, the proxy could depend on the
> upstream agents to generate the ACK for the 487.
>
> Dale
>
> ---
> interop.pingtel.com -- the public SIP phone interoperability test server
>
> _______________________________________________
> 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
