Had an issue today where we had to migrate a client as our ITSP migrated the client to a different SBC platforms.  After re-pointing, the SIP Trunk was failing to register.

The sip-ua configuration needed is pretty simple:

!
sip-ua
credentials username <myusername> password 7 <myencryptedpassword> realm myrealm.com
authentication username <myusername> password 7 <myencryptedpassword> realm myrealm.com
nat symmetric check-media-src
nat symmetric role active
registrar dns:myrealm.com expires 3600
sip-server dns:myrealm.com
!

So… what do we see?

Firstly, our SIP trunk is down:

So, we made some calls and tried to pick up an error.  The following SIP Ladder showed us a problem:

So, the issue?  CUBE is not re-INVITEing to the ITSP, based on the supplied in the WWW-Authenticate header:

000611: Mar 17 17:11:09.936: //460/3CBC3A000000/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 44.55.66.77:5060;branch=z9hG4bK12A75C
From: “End User 1” <sip:+27456478349@myrealm.com>;tag=464B7C-1D14
To: <sip:+272347897120@myrealm.com>;tag=gK08bac03c
Call-ID: 14005099-EB9A11E5-81CCED66-DEC6DF88@192.168.1.1
CSeq: 101 INVITE
WWW-Authenticate: Digest realm=”sip-2.ITSP_1″,nonce=”f3582aaf8sdf876b596d4f56a”
Content-Length: 0

Oops!  Looks like our ITSP is still busy developing their new platform?  We’re expecting Digest realm=”myrealm.com” but are getting something else!

So, what’s our solution?

Well…  to answer that, we actually need to look at the realm usage, which is well-defined in the appropriate SIP-UA RFC:

https://tools.ietf.org/html/rfc6011#section-3.1.2

 

On the CUBE, our realm configuration is is actually needed for accommodating Multiple Registrars:

http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/sip/configuration/15-mt/sip-config-15-mt-book/voi-sip-multi-trunks.html

Most specifically, the login applied for Authorization/Authentication is well summed up here:

Determination of Authentication Details
When a SIP INVITE or SIP REGISTER request is challenged, the username and password details for authentication are determined in the following order:

1. If the realm specified in the challenge matches the realm in the authentication configuration for a POTS dial peer, the system uses the corresponding username and password
2. If the realm specified in the challenge doesn’t match the configured authentication for the POTS dial peer, then it will check for credentials configured for SIP UA.
3. If the realm specified in the challenge does not match the realm configured for credentials, then it will check for authentication configurations for SIP UA.
4. If the system does not find a matching authentication or credential for the received realm, then the request is terminated.
5. If there is no realm specified for the authentication configuration, then the system uses the username received from the challenge to build the response message

So, in our case, we had a realm mismatch, and since only one realm was applied, and the ITSP didn’t prompt for a username in the challenge, CUBE failed the call.  This is working as designed.

The fix (besides raising this with the ITSP of course!) was to remove the realm config from the SIP User Agent configuration for authentication.  This allowed the CUBE to respond to requests successfully, as it searched the authentication configurations:

!
sip-ua
credentials username <myusername> password 7 <myencryptedpassword> realm myrealm.com
authentication username <myusername> password 7 <myencryptedpassword>
nat symmetric check-media-src
nat symmetric role active
registrar dns:myrealm.com expires 60
sip-server dns:myrealm.com
!

After being applied, the trunk immediately registered, and calls were successful.

#dontcalltac