[asterisk-dev] [Code Review] SIP: peer matching bycallbackextension

[Olle E. Johansson]

28 aug 2009 kl. 12.40 skrev Nick Lewis:

> oej
>
>> I think we have to solve this differently. When we register, we don't
>> register the extension as a contact, we generate a unique random
>> string. When the call comes back, the random string will be the
>> request URI and we can match on that. I actually have code for that
>> somewhere.
>
> 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.

>
>> What messes that up is that you know frequently have registrations  
>> for
>
>> SIP trunks where you won't get the contact back in the request URI,
>> which messes things up.
>
> 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 suggest we keep this code, but put it on hold until we have decided
>> what to do. Yet another hack in the already messy device matching
>> algorithm doesn't help and the callbackextension hack is ugly enough
>> as it is.
>
> 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.

It might prove that all I say here is totally wrong :-) and then I  
rest my case...

Have a nice weekend!

/O