SIP (Session Initiation Protocol), used for VoIP, has a slight problem, in my opinion.
If I am lucky, someone will post a reply to this blog and tell me I have missed the bleeding obvious here, but somehow I doubt it.
When you send an INVITE (to make a call), or indeed any message, the receiving end has the option to challenge you. The challenge allows you to send your identity and respond to the challenge with a signed response confirming your identity based on a password. The challenge/response system is pretty common in many protocols.
The problem with SIP is that the initial INVITE does not have any way to tell the recipient "I have some authentication details for you". This means the recipient has to work that out from the From/To headers. It does not know the username the sender may use if challenged, and the local part of the From header is likely to be a calling number.
The issue is that some times you are trusting the far end based on IP address and not generating a challenge, and some times you want to generate a challenge to confirm the identity. You may have a mixture of the two on the same box. A fixed config that trusts the far end is not that uncommon and avoids an extra exchange of messages.
This causes a lot of problems for things like asterisk. It is quite complicated to configure asterisk to work out if it should challenge the INVITE or not. What is worse is that asterisk does a DNS lookup of the configured host name when it checks and expects one IP address against which to check. This is a really pain when you have a group of call servers you want to trust, and makes the config quite large.
We are hitting a snag with our SIP2SIM. We have a set of call servers which can send REGISTER and INVITE messages to the customer's server. People using us for VoIP have their asterisk servers set up to understand that calls can come from that same set of servers for normal calls. But that means asterisk does not think it is sensible to challenge us for the SIP2SIM calls where we are acting like a SIP device, and hence have a username and password to use. We are working out the best way around this at the moment. We don't really want to have to set up a second set of call servers (or additional IP addresses) just for sending the SIP2SIM calls and registrations.
If SIP had a way to tell the recipient that it has credentials, and force the challenge, that would solve this. We would send the username when we have it, and the recipient can consider it in that context.