[asterisk-dev] [Code Review] SIP: peer matchingbycallbackextension

[Nick Lewis]

>> I do not see the advantage of a unique random string. I suggest a
>> different unique string - the peername.
>Well, not all registrations is based on a peer. And you can have  
>multiple registrations for a peer.

I think the peername can be used for multiple registrations e.g.
register=me at myself.com@registrar1.somewhere.net/peername
register=peername?registrar2.otherwhere.net

>> I have also experienced some trunk providers that make this mistake.
>> They tend to send the username back instead. In these cases I simply
>> name the peer after the username. This does not clash with other
>> peernames on the system because client peers have shorter names e.g.
>> [101] and trunk peers typically have usernames that are PSTN numbers
>> e.g. [442920500718] and hence unique.
>Well, you should not have phone numbers as device identifiers. That's
>a topic you can read ton of mails about in asterisk-users if you need
an
>explanation.
>Check the draft by Hadriel Kaplan about this kind of registration,  
>something that's connected with the work for the new SIPconnect spec.

I am not recommending the mistakes made by trunk providers but only 
highlighting that in practice I have found them to be satisfactorily
overcome 

>> I agree that the "callbackextension=" and
"register=.../extension~..."
>> hack is ugly (I do not use it in my implementations) but as asterisk
>> currently contains this unusual concept, I think it needs to be
>Well, "to work" means different things. A patch that solves your issue

>may not be a good patch for other setups and cause a lot of secondary  
>issues, like the poor design of callbackextension have done. I don't  
>want us to integrate more short time patches that we already can see  
>will cause a lot of future issues since they're not generic enough.  
>The code is there and you're free to use it if it solves your problem  
>- you should use it if it solves your problem. I think that patches  
>that we integrate into Asterisk has to be a bit more generic and  
>follow our architecture. And in this case, my personal opinion is the  
>architecture is broken and we need to fix that before we mess it up  
>even more with new patches. That's why I suggested that we collect the

>issues at hand in a document and work on the design before we make  
>decisions about these patches.

A part of me agrees with your perspective but the project manager part 
is concerned that the best may become the enemy of the good.

>It might prove that all I say here is totally wrong :-) and then I  
>rest my case...
You may have the same type of modesty as I :-)


_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--

AstriCon 2009 - October 13 - 15 Phoenix, Arizona
Register Now: http://www.astricon.net

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

______________________________________________________________________
This e-mail has been scanned for all viruses by Star. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk
______________________________________________________________________

_____________________________________________________________________
This message has been checked for all known viruses by Star Internet delivered through the MessageLabs Virus Control Centre.
_____________________________________________________________________
Disclaimer of Liability
ATL Telecom Ltd shall not be held liable for any improper or incorrect use of the  information described and/or contained herein and assumes no responsibility for anyones use  of the information. In no event shall ATL Telecom Ltd be liable for any direct, indirect,  incidental, special, exemplary, or consequential damages (including, but not limited to,  procurement or substitute goods or services; loss of use, data, or profits; or business  interruption) however caused and on any theory of liability, whether in contract, strict  liability, or tort (including negligence or otherwise) arising in any way out of the use of  this system, even if advised of the possibility of such damage.

Registered Office: ATL Telecom Ltd, Fountain Lane, St. Mellons Cardiff, CF3 0FB
Registered in Wales Number 4335781

All goods and services supplied by ATL Telecom Ltd are supplied subject to ATL Telecom Ltd standard terms and conditions, available upon request.