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

[Olle E. Johansson]

Vossel,
A "user" is by definition used for inbound calls, a peer for outbound. This is the generic rule. A peer registers with Asterisk because we need the address of the peer to reach it for the outbound call.

Now, this doesn't match any thinking in the SIP protocol at all, but it's what we have in Asterisk voip channels and what we teach in the trainings.

Because of the mismatch with the SIP protocol design, we use a "peer" also for incoming because we want to match on IP. It's the first exception that confuses people. 

With callbackexten, someone added a function for a peer to register to receive inbound calls, which is weird. Now the peer both accepts registrations for outbound calls and it registers for incoming calls. Please explain this. It should - if anywhere, have been in the "user" type from start. And we should have fixed proper matching from start.

Now, if you fix this issue, it will be almost impossible to explain this. In combination with the mess we have with the register= line where we can refer to a peer, but not have automatic matching, it's even more messy. 

I have written several proposals on a new architecture that we should spend our time on instead of making the current architecture even harder to teach or understand. The type=device or phone, type=service and type=trunk have been up for discussion many times and I think it fits much better into a SIP architecture.

I've said that we should move the callbackexten code to a new type, type=service. This will be much easier to explain for users. I also have pointed to code where we register a random string and use that string to match the registration on the incoming call.  That way, we'll always match and send the call to the proper extension in the dialplan.

I'm doing training this week and the peers/users stuff keep coming up every day, advanced engineers just have a very hard time understanding this - and that's no good for our product. If you did training for a while, you would also scream for these kind of issues. You would understand how important it is to have a design that has some sort of logic and thinking behind it, because it's no fun having to spend hours trying to explain the same thing over and over again. The callbackexten should be deleted and we should try to make a proper solution for registrations with services as a UA. That is what people expect us to do, support the registrations properly. If we do it within a peer and fix the existing stuff will lead to more confusion than deprecating this config option that was wrong from start and delivering a proper solution.

Yes, I've said this many times. Yes, I'm a stubborn old type. Just go ahead with the fix. And please spend time looking at my branch to see if you understand/agree with that architecture change before we discuss code details.
/O