Hi, I think that this thread is outdated, I have put my response here based on my interpretation.
ACK for non-2xx must follow the same path as the initial invite. Hence it must pass through the proxy based on the Route in the non-2xx response. However since ACK for non-2xx is the final message for the transaction, it does not make sense to have Route header in this message. ACK for 2xx can by-pass the proxy and be sent directly to the destination based on the Contact header field in the 2xx response. But here too, if there is a Route header in xx response, Route header takes precedence over contact header for identifying the next hop for ACK from the originator. Here I am not sure if this ACK for 2xx requires a Route header. Thanks, Ulrich On Thu, Apr 18, 2024 at 9:30 PM < [email protected]> wrote: > Send Sip-implementors mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Sip-implementors digest..." > > > Today's Topics: > > 1. Transaction ACK route headers (Filippos Vasilakis) > 2. Re: Transaction ACK route headers (Dale R. Worley) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 18 Apr 2024 14:29:10 +0300 > From: Filippos Vasilakis <[email protected]> > To: [email protected] > Subject: [Sip-implementors] Transaction ACK route headers > Message-ID: > < > canj+wffwk-bnfp2rccpfi9k_h0xaj_1rp6dugjgk4gddffa...@mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > Hello folks, > > I have a question related to SIP protocol, if anyone knows cause I am a bit > confused. > > I have an INVITE transaction which contains a Route header as it needs to > go through a proxy. The final downstream responds with a non-2xx (480) > which is routed back to the initial upstream. My question is whether the > ACK (which is a transaction ACK, not a dialog ACK) should contain the > initial INVITE's Route headers. I think it shouldn't as this ACK is hop-by > hop, but RFC3261 (section 17.1.1.3) says otherwise: > > "If the INVITE request whose response is being acknowledged had Route > header fields, those header fields MUST appear in the ACK. This is to > ensure that the ACK can be routed properly through any downstream stateless > proxies.". > > On the other hand, in RFC3665, section 3.11, does not copy the Route > headers to the ACK and this is confusing. Seems like RFC3665 is in error, > but again to me it seems that appending Route headers in a transaction ACK > is pointless, since the final downstream transaction has already been > ACK-ed by the middle proxy (like in 3.11 example in RFC3665). > > So what am I missing here ? > > Filippos > > > ------------------------------ > > Message: 2 > Date: Thu, 18 Apr 2024 11:17:41 -0400 > From: [email protected] (Dale R. Worley) > To: Filippos Vasilakis <[email protected]> > Cc: [email protected] > Subject: Re: [Sip-implementors] Transaction ACK route headers > Message-ID: <[email protected]> > > Filippos Vasilakis <[email protected]> writes: > > On the other hand, in RFC3665, section 3.11, does not copy the Route > > headers to the ACK and this is confusing. Seems like RFC3665 is in error, > > but again to me it seems that appending Route headers in a transaction > ACK > > is pointless, since the final downstream transaction has already been > > ACK-ed by the middle proxy (like in 3.11 example in RFC3665). > > It seems to me almost certain that F14 (the ACK from the client) in RFC > 3665 section 3.11 is mistaken for not having the Route header (as you > point out). It's probably just an oversight when writing the example. > > In particular, F14 as written won't actually reach Proxy 1, since Proxy > 1's address is ss1.atlanta.example.com (the address in the Route header > in the INVITE), not biloxi.example.com (the address in the To header). > > Dale > > > ------------------------------ > > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > End of Sip-implementors Digest, Vol 106, Issue 1 > ************************************************ > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
