Asterisk sip.conf for Spectrum (former Time Warner) SIP 401 Unauthorized


#1

Hi! I hope I’ve found the right home for this question.

We are going to be migrating from POTS to SIP provided by Spectrum (former Time Warner territory) for our connection to the outside world.

We are running Asterisk 13.17.0 (with the Cisco phone patch), and TWC doesn’t seem to have a configuration reference for Asterisk without using a GUI (e.g. Trixbox, etc.) and I haven’t had a ton of luck with support.

Spectrum has provided and installed their demarc as an InnoMedia Enterprise Session Border Controller 9378-4B. It’s sitting on our network at 10.2.1.241 and they’ve confirmed our Asterisk box at 10.2.0.2 is pingable from it, likewise, I can ping the ESBC from the box running Asterisk. I’ve been provided with the authentication username (the first number in the block of numbers we’ve been assigned) and password (a pseudo-random string)

I have register => (username/pilot number):(password)@10.2.1.241 in SIP.conf

I’ve tried every permutation of settings for SIP.conf I can think of (and then some) and the result is the same: When I try calling out, Wireshrk shows an INVITE to sip:(dialed number)@10.2.1.241 from Asterisk, a 100 Trying response followed almost immediately by a 401 Unauthorized back from the ESBC

When I try an inbound call to one of the new (native to Spectrum) numbers I get a “We’re sorry your call did not go through. Please try your call later” (prior to the installation it was the "The number you have dialed has been disconnected or is no longer in service, so I feel like things are moving in the right direction) but running wireshark on a mirrored port for the ESBC I don’t see the ESBC generate any traffic at all.

Thoughts? Ideas? Pointers? Anyone have a working config I can crib from?


#2

The sequence you have described is correct as far as it goes. Asterisk should then retry with the hashed secret. I would guess you have failed to configure a remote secret.

You haven’t said which SIP channel driver you are using but for chan_sip, the parameter is remotesecret.

Incidentally trixbox is abandonware.


#3

Thanks, David.

I am using chan_sip… and I do have remotesecret in there, so it seems like I might be close. Here’s the (sanitized) config I left things on when I decided I needed to put it down for the night:

(Edited to add: note that the pilot number in the 11-digit 1NPANXXYYYY is what Spectrum has provided as the username)

[spectrum]
type=peer
auth=(pilot number in 1NPANXXXXXX format)@10.2.1.241
remotesecret=(spectrum provided password)
canreinvite=no
insecure=port,invite
host=10.2.1.241
disallow=all
allow=ulaw
qualify=yes
nat=no


#4

If you need to use auth=, i.e. because you are getting a proxy authentication challenge, you need to include the secret, but you are not getting a proxy identification challenge, you are getting a UAS one.

The most common requirement is that fromuser is the account name.

You don’t need insecure=invite if you use remotesecret. You probably don’t need insecure=port.

canreinvite is a deprecated equivalent of directmedia.


#5

Ok, so problem solved… and it doesn’t look like It was any of the things I was poking at.

Apparently I had the register => directive in the wrong section of sip.conf… moved it to [general] and all is happy now. Confusingly when I called tech support to confirm the username and password they said the password on file matched but there was no username defined. Despite this I used the username provided by the TWC “Configuration Team”. Without insecure= I was experiencing failuures on inbound calls

For anyone who stumbles across this in the future:

register=>1NPANXXYYYY:{Password}@{ESBC LAN IP}

[spectrum]
type=peer
username= {yes, really blank}
remotesecret={spectrum provided pw}
dtmfmode=rfc2833
host={ESBC LAN IP}
insecure=port,invite
context=outsideSIP
disallow=all
allow=ulaw
trustrpid=yes