[asterisk-dev] [Code Review] Properly route responses according to the Via headers in the request
Olle E. Johansson
oej at edvina.net
Thu Dec 23 12:40:34 UTC 2010
23 dec 2010 kl. 09.59 skrev Alex Hermann:
> On Thursday 23 December 2010, Olle E. Johansson wrote:
>> The confusing part here is that the RFC is talking about the additions to
>> the via header added by the internal transport layer before sending the
>> message up to the transaction layer in the stack described in RFC 3261.
>> We have none of that. That via header addition does NOT exist in our
>> implementation, so we should just follow the reason why it's added.
> Via header additions do exist, even in Asterisk. The received parameter must
> still be added, in Asterisk it is only done at a later stage than when
> receiving the request.
DO you at all understand Asterisk? We NEVER add via headers to requests,
since we do not forward them.
>> The second paragraph in section 18.2.1 clearly says that the reason for
>> this internal header is "to assist the server transport layer in sending
>> the response, since it must be sent to the source IP address from which
>> the request came."
>> That we have by saving the sender's IP and port in the sip_pvt.
> Lacking a transaction layer/object, that is a reasonable place to store it.
> Just keep in mind you can only use it for replying to the last received
> request, nothing else.
>> Section 18.2.2 that talks about parsing this internal via header also
>> adds that we should send to the same port we received from.
> I read this:
> Otherwise (for unreliable unicast transports), if the top Via
> has a "received" parameter, the response MUST be sent to the
> address in the "received" parameter, using the port indicated
> in the "sent-by" value, or using port 5060 if none is specified
> Where does it state to send to the same port we received from?
Alex, please read my whole message. This is again about the received parameter
that the transport layer added to the INCOMING request before sending it
up the stack. You are very misleading, sir.
More information about the asterisk-dev