[asterisk-dev] [Code Review] chan_sip: skip dns lookups when we're not using the result anyway

[Mark Michelson]

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

Ship it!


This is one of those changes that on paper sounds perfectly logical, but absolutely scares the hell out of me to put in for fear that there is some case that has not been thought of. Still, I think this is correct, so I'm going to give a ship it!

- Mark


On Oct. 10, 2012, 10:58 a.m., wdoekes wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2156/
> -----------------------------------------------------------
> 
> (Updated Oct. 10, 2012, 10:58 a.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> Sometimes I get these in my logs:
> 
>   ERROR[xxx] netsock2.c: getaddrinfo("lync.somemachine.local", "5060", ...): Name or service not known
> 
> Turns out these are triggered by Contact hostname lookups when sending the end-to-end requests (like a BYE).
> 
> For whatever reason, certain people have invalid hostnames in the Contact field. But, because they're using TCP, we're not using the result of this Contact lookup at all. We always send to the open TCP socket. And everything works.
> 
> In fact, since we use nat=yes as a default, there are only few cases when we actually *do* use the Contact (or Route).
> 
> And as far as I can tell, if we don't send to the contact (or route) field, we don't need to do those lookups either.
> 
> Right? Or am I missing something crucial here?
> 
> 
> Diffs
> -----
> 
>   /trunk/channels/chan_sip.c 374800 
> 
> Diff: https://reviewboard.asterisk.org/r/2156/diff
> 
> 
> Testing
> -------
> 
> I used a sipp scenario which INVITEd in and waited for Asterisk to BYE. Only when nat=no and transport=udp was the contact (or record-route) header actually used. When using transport=tcp or nat=yes the BYE still arrived on the same place as without the patch.
> 
> 
> Thanks,
> 
> wdoekes
> 
>

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