[asterisk-dev] cisco-check-cfg

[Kevin P. Fleming]

On 07/29/2011 10:55 AM, Simon Perreault wrote:

> Now I'm not sure what problem in SIP you're referring to. SIP is
> interface-agnostic. We have IP addresses, hosts, and routing tables, but
> interfaces should not be important.

They are important, because they are the only way you can determine 
which source IP address will be selected by your operating system's IP 
routing table when you send a packet to a given remote IP address. (the 
routing tables choose a next-hop, and then determines which interface 
will be used to reach that next-hop... you know this already of course, 
but i'm elaborating for other readers and the archives)

The only other way to solve this problem is to declare (via some 
configuration mechanism) which bound socket is to be used for 
communication with a given SIP UA. It either has to be declared, or 
discovered... there is no option to not do either one, because the 
Contact header *must* include an address that the target SIP UA can use 
to respond back to Asterisk.

> But most importantly, I don't see the link between this discussion and the
> original problem. The problem was that a Contact header with ::1 was sent on a
> non-loopback interface. Without having investigated, I would guess that this was
> a side effect of a specific bug and does not indicate that we need a generic
> method of ensuring ::1 does not get sent on non-loopback interfaces. As the
> original poster indicated that the bindaddr was not set, maybe all we need is an
> error message in that case.

First, if there is a difference in behavior between bindaddr not being 
set at all, and being explicitly set to "::" (which I believe is the 
default), then that is a bug.

Second, I absolutely do mean that a Contact header (or any other SIP 
header that contains a URI that is supposed to be used to respond back 
to Asterisk) should never contain ::1 (or 127.0.0.1) when it is being 
sent on a non-loopback interface... such an address will not result in 
responses being delivered back to Asterisk. However, I don't mean to 
imply that loopback interfaces should be treated specially; the general 
solution to this problem will naturally cause the proper behavior.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kfleming at digium.com | SIP: kpfleming at digium.com | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org