Warning message

  • Cisco Support Forums is in Read Only mode while the site is being migrated.
  • Cisco Support Forums is in Read Only mode while the site is being migrated.

CME with ITSP that wont use digest authentication

Unanswered Question
Sep 1st, 2009
User Badges:

I am having issues registering a CME (2811 with 12.4.24.T) with an ITSP. When I use the configuration below, I see CME send a Register request to them but they then send back a "404 not found".

When I asked the ITSP why they are not sending back a 401 authentication challenge in response to my register request they said that they do not want me to register with them but instead send them an "authenticated call" with the ITSP provided username and password. I have no idea what that means.

Can CME send authentication on a call-by-call bases or an "authenticated call"? What would that configuration look like?


voice service voip

allow-connections h323 to h323

allow-connections h323 to sip

allow-connections sip to h323

allow-connections sip to sip

no supplementary-service sip moved-temporarily

no supplementary-service sip refer

redirect ip2ip



registrar server

voice class codec 1

codec preference 1 g711alaw

codec preference 2 g711ulaw

voice class h323 1

call start slow

no call preserve

dial-peer voice 200 voip

description Inbound / Outbound to ITSP

redirect ip2ip

voice-class h323 1

voice-class sip early-offer forced

session protocol sipv2

session target ipv4:<IP address>

session transport udp

incoming called-number .

dtmf-relay rtp-nte


credentials username <username> password <password> realm <realm>

authentication username <username> password <password>

registrar ipv4:<IP> expires 3600

sip-server ipv4:<IP>

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4.5 (2 ratings)
paolo bevilacqua Tue, 09/01/2009 - 08:36
User Badges:
  • Super Gold, 25000 points or more
  • Hall of Fame,

    Founding Member

What they mean, is that after you make a call, they will then sending calls for your number to the IP where the call has originated.

So, you don't need registrar config, just credentials.

You also don't need the "allow" commands and some more neither.

robert-knapp Tue, 09/01/2009 - 09:00
User Badges:

Just to clearify, incoming from them is working fine. With my current configuration, when I send a call to them I get a "407 proxy authentication required" message. They are expecting me to somehow send the username and password with the call.

So if my authnitication should not be placed under the SIP-UA, how would I send it? They also said that they do not want be to register my SIP DIDs with them either (for example using a ephone-dn).

Do you have an IOS config example?

Nicholas Matthews Tue, 09/01/2009 - 14:47
User Badges:
  • Red, 2250 points or more

Hi Robert,

I looked at the configuration guide for these commands to clarify a bit, and this is what it sounds like:

authenication .....

This will allow the digest authentication that your SIP provider is looking for. (Sure on this one).

credentials ....

This should send a register message. It's not clear from the command reference whether or not this sends a register message without a DN configured or not, but it doesn't sound like the configuration that you need.

Registrar ..

Unnecessary. Only for registration.


This is just a shortcut for being able to type 'session target sip-server' on your dial peers. You can just as easily type 'session target ipv4:x.x.x.x'.

Hope this clarifies.


robert-knapp Tue, 09/01/2009 - 17:42
User Badges:

Thanks. Thats very usefull info.

The problem I'm having is that the provider does not support digest authenication. If they did I think my config would work. When I debug CME I see that it wants to use RFC3261 but the provider does not.

All the provider can tell me is that they don't want me to register using sip-ua and they want the username/password sent with every call. I don't see how that's possible with CME. The provider claims that they have other CME customers using this method without a problem. I'm starting to question them on this...


This Discussion