[asterisk-dev] Fwd: [JIRA] Commented: (ASTERISK-19846) sip users/peers not matched on incoming invite when there are multiple A records in DNS

[Olle E. Johansson]

7 maj 2012 kl. 11:26 skrev John Fawcett:

> Olle
> thanks for the quick response.
> 
> 
> On 07/05/12 11:00, Olle E. Johansson wrote:
>> 7 maj 2012 kl. 10:53 skrev John Fawcett:
>> [....]
>>> If it does not make sense to change it, is there a way of configuring that would avoid the pitfalls of the workarounds I mentioned above. 
>>> 
>>> If it would make sense to change it, and assuming that someone would volunteer to make a patch, any thoughts on were that change could be made? Would it make sense that the structure of sip users and peers could store multiple ip addresses to be read from dns at configuration reload or periodically refreshed, then on an incoming call each ip would be checked?
>> The right match would be to match on the domain in the From: header from the provider. 
>> Matching on IP is not a good way here.
>> 
>> Another way would be to have a dynamic ACL for matching in combination with the From: header.
>> 
>> This all comes back to how bad the peer/user concept matches SIP. 
>> 
>> Been trying to get resources to fix this for years... :-)
>> 
>> We need a device called type=trunk that behaves better.
>> /O
>> 
>> 
> That sounds like a big investment on the code!
> 
> In the specific case I have analyzed, matching on the "From" header for
> the domain would not have helped since they used the ip in the domain part.
Ouch. Then the acl matching would work.

peermatchpermit 
peermatchdeny

If a provider sends you data from multiple servers with multiple SIP domains in the From, I would kindly suggest them to clean up their network. :-)
From an asterisk point of view, we have to figure out how to support these providers regardless if they do things right or wrong...


> So basically:
>    incoming I have only an ip (source ip and From header)
> 
>    in sip user/peers hostname configured, but asterisk stores only 1 ip
> that in my case happens to be frequently different (since provider has 4
> ips)
> 
> So a couple of ways to do it (logically)
> 
> A)
> 
> sip user/peers should store all the ips of the hostname and the
> hostname, then can match against ip from INVITE (source ip or in "From"
> header) or hostname
Forget user, we're talking about peers. Users only do name matching.

> 
> B)
> 
> sip user/peers stores hostname, then can match against ip from INVITE
> (source ip or in "From" header) or hostname. In the case of matching ip
> address, it would mean a dns lookup on each invite which could not be
> matched on hostname alone.

A dynamic ACL that builds from DNS would work. 

/O