[asterisk-dev] [Code Review] 2851: chan_sip: Remove requirement for resolving host when outbound proxy in use
Joshua Colp
reviewboard at asterisk.org
Wed Oct 23 09:44:44 CDT 2013
> 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.
>
> Joshua Colp wrote:
> 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...
>
> Olle E Johansson wrote:
> Darn Peer to prove me fatally wrong here. I need to reconsider how we should solve this. Thank you Paul for finding the bug and everyone else involved in this mess. I need some time to go back and think about the architecture we need to solve this and it won't be tomorrow. I don't want to have one peer for the outbound proxy and another for if we receive calls from the peer. If we have peer in the general section - we might want to be able to disable it in a peer to enable bidirectional comm.
>
> What a mess.
>
> Matt Jordan wrote:
> Thinking about this some more.
>
> When an outbound proxy is in use, the host is for informational purposes only, and the requests/responses from Asterisk to the proxy are sent directly to the address of the outbound proxy. I think we're all in agreement that this is a "good thing".
>
> Requests from the outbound proxy are still relayed from a known endpoint to Asterisk. The problem is just that peers typically look things up by IP address, and we do not (and probably never will know) the actual address of the peer. It seems like we have a few options:
>
> * If we receive something from something we don't know (proxy!), and we fail to look up the source by address, then:
> * Look up by username. If we get a username match, and the address that sent the request matches the proxy, and the peer with that username has an outbound proxy, associate the request with that peer
> * Otherwise, subject the request to the 'normal' rules
>
> Josh/Olle: what do you guys think?
>
>
I've circled around this a few times now because I don't have an answer either way. I think what we really need to do is try to elicit feedback from people who have tried to deploy Asterisk with outbound proxies and see how they expect/want things to behave. Unless you have any objections I'll send an email out and see if anyone has anything to say. I'd hate to spend the time getting outbound proxy support going again only to have it blow up in our faces.
- 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/20131023/e701b306/attachment-0001.html>
More information about the asterisk-dev
mailing list