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

[Mark Michelson]

On 12/22/2010 07:57 AM, Kevin P. Fleming wrote:
> On 12/22/2010 05:32 AM, Klaus Darilion wrote:
>>
>>
>> Am 16.12.2010 18:29, schrieb Matthew Nicholson:
>>> This is an automatically generated e-mail. To reply, visit:
>>> https://reviewboard.asterisk.org/r/1059/
>>>
>>>
>>> Review request for Asterisk Developers. By Matthew Nicholson.
>>>
>>>
>>> Description
>>>
>>> This patch makes asterisk respect the Via headers in a request when
>>> responding to it. This is necessary in the even that a stateless
>>> proxy is in between asterisk and the requester.
>>
>> Sorry for jumping in that late. It would be good if the description
>> would be useful - thus, describing what the current (broken?) behavior
>> is and how the new (fixed) behavior work.
>>
>> I really wonder what is the problem with the current behavior.
>>
>> > Without this patch,
>> > the response is simply routed back to the address we received the
>> > initial request from.
>>
>> Really? I often use proxies between Asterisk and the SIP clients and
>> never had any issues - responses were always routed correctly
>>
>> Please describe in more detail the problem with the old and new 
>> behavior.
>
> The problem report that caused Matt to be working on this is a 
> scenario where an INVITE is received from a UAC through a proxy; 
> Asterisk properly responds to the INVITE through the proxy. However, 
> later the same UAC sends in-dialog INFO requests directly to Asterisk, 
> bypassing the proxy, and Asterisk replies to the proxy instead of to 
> the UAC.
>
> Based on my not-quite-complete understanding of SIP, my impression is 
> that this UAC is behaving improperly; since it sent the 
> dialog-creating request through the proxy, all subsequent requests 
> should be sent through the proxy as well. However, that could be 
> completely wrong, and Matt's analysis up to this point determined that 
> it may have been wrong, and that we should be able to respond to the 
> UAC directly for subsequent in-dialog requests.
The UAC would send in-dialog requests through the proxy only if the 
proxy had added a Record-Route header during the INVITE transaction.

 From the introductory section in RFC 3261:

    In some cases, it may be useful for proxies in the SIP signaling path
    to see all the messaging between the endpoints for the duration of
    the session.  For example, if the biloxi.com proxy server wished to
    remain in the SIP messaging path beyond the initial INVITE, it would
    add to the INVITE a required routing header field known as Record-
    Route that contained a URI resolving to the hostname or IP address of
    the proxy.  This information would be received by both Bob's SIP
    phone and (due to the Record-Route header field being passed back in
    the 200 (OK)) Alice's softphone and stored for the duration of the
    dialog.  The biloxi.com proxy server would then receive and proxy the
    ACK, BYE, and 200 (OK) to the BYE.

Mark Michelson