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

[Olle E. Johansson]

7 jul 2010 kl. 17.47 skrev David Vossel:

> 
> 
>> On 2009-11-17 05:02:04, Nick Lewis wrote:
>>> Is there any chance that discussion of this code fix can be decoupled from system architecture discussions over "authentication" "authorization" and "payment"? There is agreement that correct matching of an incoming call to a device specification is distinct from the system architecture concerns.
> 
> 
> This issue has been stagnant for sometime now, but I believe this still needs to be addressed, preferably before 1.8 is branched.
> 
> The compromise here would be to have this new matching become an option that can be turned on and off, but I don't see why that is necessary.  To me the callbackextension option should be the option to turn this on and off.  If a peer definition sets the callbackextension option, then why would they not want to match that peer to that extension?  Having an option to explicitly enable the matching everyone should expect seems cumbersome, and I don't understand the point.
> 
>> From sip.conf
> ;callbackextension=123      ; Register with this server and require calls coming back to this extesion
> 
> Why would we want to register with the server and have the calls come back and match a different peer than the one that registered?  We can talk about architecture changes and what is technically right to do, but eventually it comes down to what people expect.  If people expect one thing but Asterisk does another thing then that is a problem.  This fix is simple and I'm recommending we re-evaluate this change and get it committed.


I am a bit tired of this discussion coming up again and again. I am obviously alone in being ashamed of the lack of architectural thinking in this area, as well as having experimental code for multiple years. So don't let me stop you, just keep on adding layers of patches that will certainly break stuff...  

Just so you know the history: I opposed the callbackextension as well, since that was poorly designed. And I have several times stated that I have alternative code.

If you press this in regardless, I might as well add my matchinpeer stuff that has been in production for a long time, but also will be confusing to the existing peer/user/friend/whatever messy architecture. It's been in a branch for over a year I guess, and I have so far had no feedback from anyone on this list on it - bad or good - except for Klaus that also understands SIP.

I just wish I had time and resources to clean this mess up and create a solution we could be proud of. I have not, you have. Which is why it makes me so sad to see our product treated this way. We just have to accept that we have different views in this area and will end up with different code bases also for 1.8. 

/O