[asterisk-dev] Asterisk 1.6 peer matching working differently

Kaloyan Kovachev kkovachev at varna.net
Mon May 5 08:42:50 CDT 2008


On Wed, 30 Apr 2008 22:05:51 +0200, Johansson Olle E wrote
> Friends, co-developers and users,
> 
> We had a discussion here in Huntsville (yes, the vikings are invading  
> the dev team over here again) yesterday about the changes done to  
> chan_sip device matching. Steve Murphy's code means a HUGE improvement  
> over the old linked lists that bogged down large installations and is  
> a huge step forward, but...
> 
> During last week, in the Asterisk SIP Masterclass, I realized that  
> there was one area I hadn't discussed with Steve and we want to  
> consult the rest of the community to see how important this is for  
> you. Please try to follow this logic.
> 
> Today, we match on peers on IP address and port for incoming calls by  
> traversing the list of SIP peers from top to bottom. In the top of the  
> list, we have the last defined peer in sip.conf. So we match sip.conf  
> [peers] from bottom up. This is something I've covered in multiple bug  
> reports, multiple e-mails on mailing lists and in my trainings -  
> instructing users to use the last peer, because that's the context  
> where the call will end up.
> 
> This really affects you if you have multiple registrations with one  
> service provider. Even if you have multiple peer definitions that you  
> use for outbound calls, only the last one will be used for inbound  
> calls. We have code in the works to fix this issue, but that's how it  
> works today.
> 
> With the new code in svn trunk (not 1.6.0) we will match any peer by  
> using hatches. We can't really say which one.
> 
> The big question here is:
> - Will this break your configurations?

+1 Yes, there are some settings (not only context), for some of the 'outgoing
accounts', which i wouldn't want for the 'inbound' ones (and the opposite).
Having them chosen in random is the real problem - the first or last one
doesn't matter, just be it a specific (documented) one

> - Is this breaking backwards compatibility or is it non-important? Do  
> we need to find a way to restore this functionality, or can we just  
> ask users to add the right context for each peer while we're waiting  
> for the final solution to this problem?
> 
> Looking forward to your insightful feedback as always!
> 
> Greetings from Huntsville!
> 
> /Olle
> 
> _______________________________________________
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
> 
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev




More information about the asterisk-dev mailing list