<html>
<body>
<div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
<table bgcolor="#f9f3c9" width="100%" cellpadding="8" style="border: 1px #c9c399 solid;">
<tr>
<td>
This is an automatically generated e-mail. To reply, visit:
<a href="https://reviewboard.asterisk.org/r/344/">https://reviewboard.asterisk.org/r/344/</a>
</td>
</tr>
</table>
<br />
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<p style="margin-top: 0;">On November 4th, 2011, 4:10 a.m., <b>wdoekes</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">I haven't had the need for this. Having the peer set its username in the From: or using match_auth_username has worked fine for my purposes. Is this really needed?</pre>
</blockquote>
</blockquote>
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Here is the use case I can think of for this.
If you:
1. Have multiple accounts with a particular provider and each requires registration
2. The provider sends you calls based on the Contact header you registered with (which callbackextension sets)
3. You don't authenticate inbound calls from this provider, but rely on the host/ip of the INVITE request
4. You need to match inbound calls from this provider to the specific peer that registered for "some purpose" (billing, whatever)
then I can see where this would be useful. You could just set all of the peers so that it doesn't matter which one matches and then do lots of dialplan magic to determine what to do with the call, but this would make things a bit easier.
My initial reaction was "Matching by callbackextension seems crazy. Why would you create multiple peers that all point to the same host?" But, I thought that callbackextension was where Asterisk would send the call after matching the peer. This is not the case as callbackextension sets the Contact header so that that particular extension will be the one the other side uses for calling us back. The *only* way we determine what extension to hit is via the Request URI. So really, the peers with matching hosts and different callbackextensions are different entities with different contact addresses. After giving it some more thought, I think this feature makes sense. I plan on doing code review for it tomorrow, so if anyone has any comments...I suggest they hurry. ;-)</pre>
<br />
<p>- Terry</p>
<br />
<p>On December 9th, 2010, 12:16 p.m., David Vossel wrote:</p>
<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" style="background-image: url('https://reviewboard.asterisk.org/media/rb/images/review_request_box_top_bg.png'); background-position: left top; background-repeat: repeat-x; border: 1px black solid;">
<tr>
<td>
<div>Review request for Asterisk Developers.</div>
<div>By David Vossel.</div>
<p style="color: grey;"><i>Updated Dec. 9, 2010, 12:16 p.m.</i></p>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
<tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">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
--------------------------------------------
</pre>
</td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Testing </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
<tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Tested multiple peers with the same address containing different callbackextensions. Verified the correct peers were matched with incoming calls.</pre>
</td>
</tr>
</table>
<div style="margin-top: 1.5em;">
<b style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Bugs: </b>
<a href="https://issues.asterisk.org/jira/browse/14340">14340</a>
</div>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">
<li>/trunk/channels/chan_sip.c <span style="color: grey">(297950)</span></li>
<li>/trunk/channels/sip/include/sip.h <span style="color: grey">(297950)</span></li>
<li>/trunk/configs/sip.conf.sample <span style="color: grey">(297950)</span></li>
</ul>
<p><a href="https://reviewboard.asterisk.org/r/344/diff/" style="margin-left: 3em;">View Diff</a></p>
</td>
</tr>
</table>
</div>
</body>
</html>