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

[Olle E Johansson]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/1059/#review3099
-----------------------------------------------------------


Repeating the kind request of moving the address assignment for responses out of process_via() and a note about the addr_is_multicast for trunk. Thanks for your work. ALmost done. :-)

/Olle


/branches/1.4/channels/chan_sip.c
<https://reviewboard.asterisk.org/r/1059/#comment6355>

    Cool code - in trunk it might not belong in chan_sip though. It's a test that shoud be an ast_ function in the new code. Add it on row 6768, before calling process_via. I will use process_via for peer matching in new code, so assigning the address would also be wrong there. (pinetree does this already)



/branches/1.4/channels/chan_sip.c
<https://reviewboard.asterisk.org/r/1059/#comment6356>

    I still don't think this belongs in process_via. Process_via might override this assignment - but having it in process_via indicates that the via header has anything to do with response address by default, which is a bad assumption and thus bad code...


- Olle E


On 2011-01-17 15:19:03, Matthew Nicholson wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1059/
> -----------------------------------------------------------
> 
> (Updated 2011-01-17 15:19:03)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> This patch makes asterisk respect the Via headers in a request when responding to the request. Without this patch, the request is always routed back to the address the initial request was received from (unless nat=yes).  This can cause problems if the initial request comes through a proxy and additional requests (such as INFO dtmf tones) come from a different proxy.
> 
> 
> Diffs
> -----
> 
>   /branches/1.4/channels/chan_sip.c 302160 
> 
> Diff: https://reviewboard.asterisk.org/r/1059/diff
> 
> 
> Testing
> -------
> 
> Briefly tested using openser as a proxy and another asterisk machine as the requester.  I sent and invite, then some INFO DTMF messages.  Without the patch, our asterisk machine sends all responses to the INFO requests to the proxy, with the patch they are properly routed to the requesting asterisk machine.
> 
> 
> Thanks,
> 
> Matthew
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20110117/cd5c1cfd/attachment.htm>