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

[Matthew Nicholson]

> On 2011-01-17 15:42:53, Olle E Johansson wrote:
> > /branches/1.4/channels/chan_sip.c, line 5099
> > <https://reviewboard.asterisk.org/r/1059/diff/9/?file=14877#file14877line5099>
> >
> >     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...

I suppose this makes sense.  I have moved that assignment in my code.


> On 2011-01-17 15:42:53, Olle E Johansson wrote:
> > /branches/1.4/channels/chan_sip.c, line 5087
> > <https://reviewboard.asterisk.org/r/1059/diff/9/?file=14877#file14877line5087>
> >
> >     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)

I don't understand what you are suggesting here.


- Matthew


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


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/20110118/fbdca964/attachment-0001.htm>