[asterisk-dev] [Code Review] 2851: chan_sip: Remove requirement for resolving host when outbound proxy in use

[Joshua Colp]

> On Sept. 17, 2013, 4:39 p.m., Paul Belanger wrote:
> > So, had a chance to play more with this last night.  FWIW, this patch broke my configuration, specifically if outboundproxy was setup, any SIP context with type=peer would break.  IMO, this is the wrong functionality, what use case would setting a global outboundproxy be used?  Additionally, I believe the patch should only affect outbound calls, since the name of the setting is outboundproxy.
> > 
> > Either way, after updating my configuration to work with the patch (create a peer specific outboundproxy), I actually didn't need to apply to patch at all.  Either way, I believe there needs to be some more discussion about this scenario before 'ship it' can be applied.
> 
> Joshua Colp wrote:
>     Just so other people understand why this broke his configuration:
>     
>     Host based matching was being used, and as this change makes it so chan_sip does not do resolution when a global outbound proxy is specified chan_sip did not know the IP address and thus did not match it.
> 
> Matt Jordan wrote:
>     So, using Olle's example + 1 other peer:
>     
>     [mypeer]
>     type=peer
>     host=oej.digium.com
>     outboundproxy=edvina.net
>     
>     [otherpeer]
>     type=peer
>     host=oej.digium.com
>     
>     Asterisk would resolve "oej.digium.com" for otherpeer, but would not for mypeer. That seems correct to me.
>     
>     To Paul's point that a global outboundproxy would be used for all SIP peers, that seems intuitive, as it is in line with all other global settings. I think there is a valid use case for defining a global outboundproxy: all SIP traffic going out of your Asterisk system is relayed through a proxy.
>     
>     Paul's other point is potentially a concern: I'm not sure how this should affect the inbound message traffic either. There are some times that an inbound request will attempt to look up a peer by address (inbound authentication for requests other than REGISTER/SUBSCRIBE, MWI NOTIFY requests). Since the host is now unresolvable, I'm not sure what this patch will do to that functionality.

With the patch the peer will not be found in that scenario, since it is unresolved. We can't really have it both ways at the same time...


- Joshua


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


On Sept. 14, 2013, 7:30 p.m., Joshua Colp wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2851/
> -----------------------------------------------------------
> 
> (Updated Sept. 14, 2013, 7:30 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-21231 and ASTERISK-21694
>     https://issues.asterisk.org/jira/browse/ASTERISK-21231
>     https://issues.asterisk.org/jira/browse/ASTERISK-21694
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> During the development of 1.8 chan_sip was moved to using dnsmgr for host resolution. These changes introduced a regression where all hosts were looked up in DNS, including when an outbound proxy is in use. This is incorrect. The attached change removes this requirement.
> 
> 
> Diffs
> -----
> 
>   /branches/1.8/channels/chan_sip.c 398742 
> 
> Diff: https://reviewboard.asterisk.org/r/2851/diff/
> 
> 
> Testing
> -------
> 
> Configured an outbound proxy at global and peer level, confirmed that no resolution occurs for the host and also that traffic goes to where it should. Removed outbound proxy and confirmed things returned to normal.
> 
> 
> Thanks,
> 
> Joshua Colp
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130917/972b176b/attachment-0001.htm>