[asterisk-dev] [Code Review] Properly route responses according to the Via headers in the request

[Alex Hermann]

On Thursday 23 December 2010, Olle E Johansson wrote:
> > On 2010-12-23 02:11:36, Olle E Johansson wrote:
> > > THis is wrong and not according to the RFC. Please re-read the
> > > section I referred you to. A UAC should always respond
UAC's don't respond, they send requests. UAS's respond.

> > > to the sender's IP address and port.
Wrong, only to the address, the port is taken form the Via header unless 
rport is used.

> > > If you make the nat=yes behaviour for
> > > SIP the default, you are right on. Via headers are used for proxies,
> > > since a proxy do not have to keep state and remember the sender. The
> > > proxy handling the response might not even be the same as the one
> > > processing the request.
Wrong, replies always follow the exact same path back along proxies as the 
request has followed on its way to the UAS.

> > > Via headers is not for UA's unless you have
> > > a transport machine that adds  an Via header when receiving the
> > > packet and delivers it up to the the transaction layer. If that's
> > > the case, the transaction layer routes the response to the top via
> > > header, added by the incoming transport. Since we have none of that,
> > > we just respond to the sender. Period.
> 
> I haven't figured out from your e-mails whether or not you had a route
> set. If you had a route set from the initial transaction and get the
> INFO from another address, we need to figure out what to do.
> 
> If there's no route set (no proxy added a record-route header to request
> to stay in the signalling path) then only the initial transaction goes
> through the proxy and we should respond directly to the device.
For replying to a request, it is completely irrelevant if there is a proxy 
in the path or whether is is statefull, stateless, has or has not record-
route headers.


Your last 2 emails only add to the confusion as they contradict the rfc's.

Proper reply behaviour is described in 18.2 of rfc3261 and rfc3581 and is 
certainly no rocket-science. Short versions have already been mailed in this 
thread.

-- 
Alex Hermann