[asterisk-dev] [Code Review] SIP: peer matching by callbackextension

[Olle E Johansson]

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



/trunk/channels/chan_sip.c
<https://reviewboard.asterisk.org/r/344/#comment5205>

    Why not integrate this into find_peer instead of first running find_peer then running another similar function after. Why not find the proper peer directly?



/trunk/channels/chan_sip.c
<https://reviewboard.asterisk.org/r/344/#comment5206>

    So if we had a callback, then reload and not have a callback, what do we do? We should really unregister the callback in that case.



/trunk/channels/chan_sip.c
<https://reviewboard.asterisk.org/r/344/#comment5207>

    Should we accept exten at domain too? How do we handle that?



/trunk/channels/chan_sip.c
<https://reviewboard.asterisk.org/r/344/#comment5208>

    I think this is a poor name for the setting, but can't really come up with a better one... It has to be something that includes "peer" because it changes peer matching.
    
    callbackpeermatching=yes/no ?



/trunk/configs/sip.conf.sample
<https://reviewboard.asterisk.org/r/344/#comment5209>

    THe explanation here should be changed:
    
    "When you make asterisk register for a service and configure the contact URI using the "callbackextension" option in the device configuration, Asterisk can match the peer by IP/port AND request URI instead of only matching on IP/port, which may match another device object with the same address." 
    
    "callbackextension" is a bad name from start, so we need to explain it with some SIP terms to make it understandable for SIP people too.


- Olle E


On 2009-10-08 16:39:29, David Vossel wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/344/
> -----------------------------------------------------------
> 
> (Updated 2009-10-08 16:39:29)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> If there are a number of peers with different callbackextension parameters and the same host address.  The first peer found matching the address is used regardless if that peer's callbackextension matches the incoming extension or not.
> 
> Now, to better match peers with incoming calls, if an incoming call's address can match multiple peers by address, we check each of those peer's callbackextension against the incoming extension for the best possible match.
> 
> It is possible that my implementation may be too expensive and only serve to address a minor edge case in the usage of chan_sip.  I do not fully understand the impact my changes may have upon performance when a large number of peers are present.  This patch assumes the new parse_uri() change has been made.
> 
> -------------------------------------------
> for example with two peers as follows
> [trunk1]
> host=sip.myitsp.com
> callbackextension=9991
> ...
> [trunk2]
> host=sip.myitsp.com
> callbackextension=9992
> ...
> 
> incoming calls to 9991 and to 9992 are both matched to the peer trunk1
> --------------------------------------------
> 
> 
> This addresses bug 14340.
>     https://issues.asterisk.org/view.php?id=14340
> 
> 
> Diffs
> -----
> 
>   /trunk/channels/chan_sip.c 222947 
>   /trunk/configs/sip.conf.sample 222883 
> 
> Diff: https://reviewboard.asterisk.org/r/344/diff
> 
> 
> Testing
> -------
> 
> Tested multiple peers with the same address containing different callbackextensions. Verified the correct peers were matched with incoming calls.
> 
> 
> Thanks,
> 
> David
> 
>