Hello all,
I am having issues getting a fax machine to register over a SIP trunk and I was hoping that you could shed some light for me. Here is a little background of my setup. I have a punch down block connected to fax machine connected to an Adtran 908e via an amphenol cable (dial tone is present). The Adtran is on my lan and routed outside through my ASA 5505. Here is the basic config of my Adtran:
hostname "fax.test.ta908e"
enable password encrypted xxxxxxxxxxxxxx
!
!
!
ip subnet-zero
ip classless
ip routing
ipv6 unicast-routing
!
!
domain-proxy
name-server 4.2.2.2 8.8.8.8
!
!
no auto-config
auto-config authname adtran encrypted password xxxxxxxxxxxxxxxxxxx
!
no event-history
no logging forwarding
no logging email
!
service password-encryption
!
username "admin" password encrypted xxxxxxxxxxxxxxxxxxxxx
username "teccom" password encrypted xxxxxxxxxxxxxxxxxxxx
username "bnelson" password encrypted xxxxxxxxxxxxxxxxxxx
!
!
ip firewall
no ip firewall alg msn
no ip firewall alg mszone
no ip firewall alg h323
!
!
!
!
!
!
!
!
no dot11ap access-point-control
!
packet-capture sip-fax standard
export flash
limit size 3M
match list sip-fax-acl
shutdown
!
!
!
!
qos map VoIP 10
match dscp 46
priority unlimited
!
!
!
!
interface eth 0/1
ip address 192.168.0.248 255.255.255.0
ip packet-capture sip-fax
media-gateway ip primary
traffic-shape rate 1544000
qos-policy out VoIP
no shutdown
!
!
interface eth 0/2
no ip address
shutdown
!
!
!
!
interface t1 0/1
no shutdown
!
interface t1 0/2
no shutdown
!
interface t1 0/3
no shutdown
!
interface t1 0/4
no shutdown
!
!
interface fxs 0/1
no shutdown
!
...............
!
interface fxs 0/8
no shutdown
!
!
interface fxo 0/0
no shutdown
!
!
!
!
!
!
!
!
ip access-list extended sip-fax-acl
permit ip host 64.94.196.103 any
permit ip any host 64.94.196.103
!
!
!
!
!
!
ip route 0.0.0.0 0.0.0.0 192.168.0.254
!
no tftp server
no tftp server overwrite
no http server
no http secure-server
no snmp agent
no ip ftp server
no ip scp server
no ip sntp server
!
!
!
!
!
!
!
!
ip sip
ip sip udp 5060
no ip sip tcp
!
!
!
voice feature-mode network
voice forward-mode network
!
!
!
!
!
!
!
!
!
!
!
!
voice codec-list 711
codec g711ulaw
!
voice codec-list g711_only
codec g711ulaw
!
!
!
voice trunk T01 type sip
sip-server primary fax01.coredial.com
registrar threshold absolute 5
codec-list g711_only both
!
!
voice grouped-trunk T01
description "VOICE SERVER"
trunk T01
accept $ cost 0
!
!
voice user 1001
connect fxs 0/1
password encrypted "1f1b4c6c6b536f39041ac568f6e7eec6ada1"
forward-disconnect delay 1000
sip-identity 8037674862 T01 register auth-name "sip9000001_dcttest" password encrypted "373ae3a74679687d5bead55156eee1b09fe3"
sip-authentication password encrypted "2f2b67a85fc7fe507f6c2215dd4664bfcfd8"
modem-passthrough
codec-list g711_only
!
!
!
ip sip proxy
ip sip proxy transparent
!
!
!
!
!
line con 0
no login
!
line telnet 0 4
login
no shutdown
line ssh 0 4
login local-userlist
no shutdown
!
sntp server pool.ntp.org
!
!
!
!
end
Here is the current output from debug sip trunk-registration:
15:16:42.140 SIP.TRK-REG T01 8037674862 Idle 1 Pending Event is waiting.
15:16:42.140 SIP.TRK-REG T01 8037674862 Idle Executing RegisterEvent.
15:16:42.140 SIP.TRK-REG T01 8037674862 State change >> Idle -> AcquireClient
15:16:42.141 SIP.TRK-REG T01 8037674862 AcquireClient Stopping ReregistrationTimer.
15:16:42.141 SIP.TRK-REG T01 8037674862 AcquireClient Requesting permission to acquire RegisterClient.
15:16:42.141 SIP.TRK-REG T01 8037674862 AcquireClient Permission granted - proceeding.
15:16:42.141 SIP.TRK-REG T01 8037674862 State change >> AcquireClient -> Registering
15:16:42.141 SIP.TRK-REG T01 8037674862 Registering Stopping RetryTimer.
15:16:42.141 SIP.TRK-REG T01 8037674862 Registering Stopping RolloverTimer.
15:16:42.145 SIP.TRK-REG T01 8037674862 Registering RegClient -> REGISTERING
15:16:42.145 SIP.TRK-REG T01 8037674862 Registering Starting RolloverTimer (3000 ms).
15:16:42.836 SIP.TRK-REG T01 8037674862 Registering RegClient -> UNAUTHENTICATED
15:16:42.837 SIP.TRK-REG T01 8037674862 State change >> Registering -> Unauthenticated
15:16:42.837 SIP.TRK-REG T01 8037674862 Unauthenticated Stopping RolloverTimer.
15:16:42.839 SIP.TRK-REG T01 8037674862 Unauthenticated RegClient -> REGISTERING
15:16:42.839 SIP.TRK-REG T01 8037674862 Unauthenticated Starting RolloverTimer (3000 ms).
15:16:43.571 SIP.TRK-REG T01 8037674862 Unauthenticated RegClient -> FAILED
15:16:43.572 SIP.TRK-REG T01 8037674862 State change >> Unauthenticated -> Failed
15:16:43.572 SIP.TRK-REG T01 8037674862 Failed Stopping RolloverTimer.
15:16:43.572 SIP.TRK-REG T01 8037674862 Failed Starting ReregistrationTimer (180000 ms).
15:16:43.572 SIP.TRK-REG T01 8037674862 State change >> Failed -> ReleaseClient
15:16:43.573 SIP.TRK-REG T01 8037674862 ReleaseClient RegClient -> TERMINATED
15:16:43.573 SIP.TRK-REG T01 8037674862 State change >> ReleaseClient -> Idle
15:16:43.573 SIP.TRK-REG T01 8037674862 Idle No Pending Events are waiting.
Packet capture output is 401 and 403 errors.
Jayh,
Thank you for all the help and detailed explanations. I got a hold of Coredial support and the tech I spoke with said he was not seeing any registered attempts from the Adtran. The cause for that was that I had the fax number they provided as the sip-identity and SIP username as the auth-name. As soon as I changed the SIP username to be the sip-identity, everything worked.
If possible, connect the 908e directly to the WAN outside of the ASA.
Otherwise, if the ASA is doing NAT (and it looks like it is based on the 192.168.0.248 address), you may need to toggle SIP fixup in the ASA. SIP through NAT can break things.
On the ASA do disable SIP fixup:
policy-map global_policy
class inspection_default
no inspect sip
or if it is disabled now, turn it on with "inspect sip".
What does "debug sip stack messages" show?
Thanks for the reply jayh. Your are correct, our ASA is doing the NAT. Here is the current config the policy-map global-policy
policy-map global-policy
class class-default
inspect ftp
set connection random-sequence-number disable
Here is a fragment of the sip stack messages:
20:52:43.354 SIP.STACK MSG Tx: UDP src=192.168.0.248:5060 dst=64.94.196.103:5060
20:52:43.355 SIP.STACK MSG REGISTER sip:fax01.coredial.com:5060 SIP/2.0
20:52:43.355 SIP.STACK MSG From: <sip:8037674862@fax01.coredial.com:5060;transport=UDP>;tag=475bfa0-7f000001-13c4-bf07b-5deb5899-bf07b
20:52:43.355 SIP.STACK MSG To: <sip:8037674862@fax01.coredial.com:5060;transport=UDP>
20:52:43.355 SIP.STACK MSG Call-ID: 47d50d0-7f000001-13c4-12457-6cf3efab-12457
20:52:43.355 SIP.STACK MSG CSeq: 14108 REGISTER
20:52:43.356 SIP.STACK MSG Via: SIP/2.0/UDP 192.168.0.248:5060;branch=z9hG4bK-bf07b-2ea36137-232cbc63
20:52:43.356 SIP.STACK MSG Max-Forwards: 70
20:52:43.356 SIP.STACK MSG Supported: 100rel,replaces
20:52:43.356 SIP.STACK MSG Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, REFER, REGISTER
20:52:43.356 SIP.STACK MSG User-Agent: ADTRAN_Total_Access_908e_2nd_Gen/R10.6.0.E
20:52:43.356 SIP.STACK MSG Contact: <sip:8037674862@192.168.0.248:5060;transport=UDP>
20:52:43.357 SIP.STACK MSG Expires: 3600
20:52:43.357 SIP.STACK MSG Content-Length: 0
20:52:43.357 SIP.STACK MSG
20:52:43.853 SIP.STACK MSG Rx: UDP src=64.94.196.103:5060 dst=192.168.0.248:5060
20:52:43.853 SIP.STACK MSG SIP/2.0 401 Unauthorized
20:52:43.853 SIP.STACK MSG Via: SIP/2.0/UDP 192.168.0.248:5060;branch=z9hG4bK-bf07b-2ea36137-232cbc63;received=207.54.171.2;rport=34606
20:52:43.853 SIP.STACK MSG From: <sip:8037674862@fax01.coredial.com:5060;transport=UDP>;tag=475bfa0-7f000001-13c4-bf07b-5deb5899-bf07b
20:52:43.853 SIP.STACK MSG To: <sip:8037674862@fax01.coredial.com:5060;transport=UDP>;tag=as1cfbf750
20:52:43.854 SIP.STACK MSG Call-ID: 47d50d0-7f000001-13c4-12457-6cf3efab-12457
20:52:43.854 SIP.STACK MSG CSeq: 14108 REGISTER
20:52:43.854 SIP.STACK MSG Server: CoreDialPBX
20:52:43.854 SIP.STACK MSG Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
20:52:43.854 SIP.STACK MSG Supported: replaces, timer
20:52:43.854 SIP.STACK MSG WWW-Authenticate: Digest algorithm=MD5, realm="fax01.coredial.com", nonce="5ebedc2e"
20:52:43.855 SIP.STACK MSG Content-Length: 0
20:52:43.855 SIP.STACK MSG
I don't see the Adtran responding to the challenge.
The first REGISTER message is sent, and the response has a 401 Unauthorized which is normal. It also contains a challenge nonce as seen by WWW-Authenticate: Digest algorithm=MD5, realm="fax01.coredial.com", nonce="5ebedc2e".
The Adtran unit should hash this challenge with the password and reply with a second REGISTER message containing the result. If the SIP server at the other end matches this with its hash of the password and the challenge nonce, then registration will succeed. However, the Adtran isn't sending a response to the challenge.
Try removing
registrar threshold absolute 5
from the voice trunk T01 configuration. We don't have that in our configurations and it may be that the Adtran itself is trying to act as registrar.
tetu04 wrote:
Here is a fragment of the sip stack messages:
Does that fragment have the complete sequence from a REGISTER? I'm wondering if the response to the challenge was omitted? Your
registrar threshold absolute 5 is pretty aggressive with 5-second refresh. If authentication is failing, the carrier's SBC may block you as an attacker. There should be another REGISTER sent immediately after the first 401 with a response to the challenge.
jayh,
I was hoping you could aid me in getting the SIP inspection issue corrected. I think the problem may be correlated with that. Looking at my current ASA config here is what i hav:
dctasa# sh run class-map
!
class-map inspection-default
match default-inspection-traffic
class-map inspection-sip
class-map inspection_default
dctasa# sh run policy-map
!
policy-map global-policy
class class-default
inspect ftp
set connection random-sequence-number disable
dctasa(config)# policy-map global-policy
dctasa(config-pmap)# class class-default
dctasa(config-pmap-c)# no insp
dctasa(config-pmap-c)# no inspect sip
ERROR: Inspection not installed or parameters do not match
dctasa(config-pmap-c)# inspect sip
ERROR: Multiple inspect commands can't be configured for a class without 'match default-inspection-traffic|none' in it
It seems that whoever configured the ASA before removed inspect sip and they configured class class-default instead of inspection_default.
I did the following, but since sip inspection was not even present, I guess it was it irrelevant:
1) added "match default-inspection-traffic" to "class-map inspection_default".
2) removed "class class-default" from "policy-map global-policy" then
3) applied "class-map inspection_default" to "policy-map global-policy" then issued inspect sip/no inspect sip.
Coredial responded that they do not see any failed attempts on their server from my device.
fax.test.ta908e#debug sip stack messages
fax.test.ta908e#
15:24:50.859 SIP.STACK MSG Tx: UDP src=192.168.0.248:5060 dst=64.94.196.103:5060
15:24:50.859 SIP.STACK MSG REGISTER sip:fax01.coredial.com:5060 SIP/2.0
15:24:50.859 SIP.STACK MSG From: <sip:8037674862@fax01.coredial.com:5060;transport=UDP>;tag=4752a70-7f000001-13c4-3c7e3-7b978474-3c7e3
15:24:50.859 SIP.STACK MSG To: <sip:8037674862@fax01.coredial.com:5060;transport=UDP>
15:24:50.860 SIP.STACK MSG Call-ID: 47d50d0-7f000001-13c4-50-12b68541-50
15:24:50.860 SIP.STACK MSG CSeq: 4951 REGISTER
15:24:50.860 SIP.STACK MSG Via: SIP/2.0/UDP 192.168.0.248:5060;branch=z9hG4bK-3c7e3-ec4ced7-f79ab4c
15:24:50.860 SIP.STACK MSG Max-Forwards: 70
15:24:50.860 SIP.STACK MSG Supported: 100rel,replaces
15:24:50.861 SIP.STACK MSG Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, REFER, REGISTER
15:24:50.861 SIP.STACK MSG User-Agent: ADTRAN_Total_Access_908e_2nd_Gen/R10.6.0.E
15:24:50.861 SIP.STACK MSG Contact: <sip:8037674862@192.168.0.248:5060;transport=UDP>
15:24:50.861 SIP.STACK MSG Expires: 3600
15:24:50.861 SIP.STACK MSG Content-Length: 0
15:24:50.861 SIP.STACK MSG
15:24:50.894 SIP.STACK MSG Rx: UDP src=64.94.196.103:5060 dst=192.168.0.248:5060
15:24:50.895 SIP.STACK MSG SIP/2.0 401 Unauthorized
15:24:50.895 SIP.STACK MSG Via: SIP/2.0/UDP 192.168.0.248:5060;branch=z9hG4bK-3c7e3-ec4ced7-f79ab4c;received=207.54.171.2;rport=56537
15:24:50.895 SIP.STACK MSG From: <sip:8037674862@fax01.coredial.com:5060;transport=UDP>;tag=4752a70-7f000001-13c4-3c7e3-7b978474-3c7e3
15:24:50.895 SIP.STACK MSG To: <sip:8037674862@fax01.coredial.com:5060;transport=UDP>;tag=as6609a499
15:24:50.895 SIP.STACK MSG Call-ID: 47d50d0-7f000001-13c4-50-12b68541-50
15:24:50.895 SIP.STACK MSG CSeq: 4951 REGISTER
15:24:50.896 SIP.STACK MSG Server: CoreDialPBX
15:24:50.896 SIP.STACK MSG Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
15:24:50.896 SIP.STACK MSG Supported: replaces, timer
15:24:50.896 SIP.STACK MSG WWW-Authenticate: Digest algorithm=MD5, realm="fax01.coredial.com", nonce="0f2a78ea"
15:24:50.896 SIP.STACK MSG Content-Length: 0
15:24:50.896 SIP.STACK MSG
15:24:50.900 SIP.STACK MSG Tx: UDP src=192.168.0.248:5060 dst=64.94.196.103:5060
15:24:50.900 SIP.STACK MSG REGISTER sip:fax01.coredial.com:5060 SIP/2.0
15:24:50.900 SIP.STACK MSG From: <sip:8037674862@fax01.coredial.com:5060;transport=UDP>;tag=4752a70-7f000001-13c4-3c7e3-7b978474-3c7e3
15:24:50.901 SIP.STACK MSG To: <sip:8037674862@fax01.coredial.com:5060;transport=UDP>
15:24:50.901 SIP.STACK MSG Call-ID: 47d50d0-7f000001-13c4-50-12b68541-50
15:24:50.901 SIP.STACK MSG CSeq: 4952 REGISTER
15:24:50.901 SIP.STACK MSG Via: SIP/2.0/UDP 192.168.0.248:5060;branch=z9hG4bK-3c7e3-ec4ceff-2aedf05
15:24:50.901 SIP.STACK MSG Max-Forwards: 70
15:24:50.901 SIP.STACK MSG Supported: 100rel,replaces
15:24:50.902 SIP.STACK MSG Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, REFER, REGISTER
15:24:50.902 SIP.STACK MSG User-Agent: ADTRAN_Total_Access_908e_2nd_Gen/R10.6.0.E
15:24:50.902 SIP.STACK MSG Contact: <sip:8037674862@192.168.0.248:5060;transport=UDP>
15:24:50.902 SIP.STACK MSG Expires: 3600
15:24:50.902 SIP.STACK MSG Authorization: Digest username="sip9000001_dcttest",realm="fax01.coredial.com",nonce="0f2a78ea",uri="sip:fax01.coredial.com:5060",response="a36102fca497a512031bd76f7bfde1ae",algorithm=MD5
15:24:50.902 SIP.STACK MSG Content-Length: 0
15:24:50.903 SIP.STACK MSG
15:24:50.939 SIP.STACK MSG Rx: UDP src=64.94.196.103:5060 dst=192.168.0.248:5060
15:24:50.939 SIP.STACK MSG SIP/2.0 403 Forbidden (Bad auth)
15:24:50.939 SIP.STACK MSG Via: SIP/2.0/UDP 192.168.0.248:5060;branch=z9hG4bK-3c7e3-ec4ceff-2aedf05;received=207.54.171.2;rport=56537
15:24:50.939 SIP.STACK MSG From: <sip:8037674862@fax01.coredial.com:5060;transport=UDP>;tag=4752a70-7f000001-13c4-3c7e3-7b978474-3c7e3
15:24:50.939 SIP.STACK MSG To: <sip:8037674862@fax01.coredial.com:5060;transport=UDP>;tag=as6609a499
15:24:50.940 SIP.STACK MSG Call-ID: 47d50d0-7f000001-13c4-50-12b68541-50
15:24:50.940 SIP.STACK MSG CSeq: 4952 REGISTER
15:24:50.940 SIP.STACK MSG Server: CoreDialPBX
15:24:50.940 SIP.STACK MSG Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
15:24:50.940 SIP.STACK MSG Supported: replaces, timer
15:24:50.940 SIP.STACK MSG Content-Length: 0
15:24:50.941 SIP.STACK MSG
Hi,
Maybe this link can be helpful Cisco ASA 5500 Series Configuration Guide using the CLI, 8.4 and 8.6 - Configuring Inspection of Voi....
If you are allowing the ASA to do the SIP fixup, then you should disable the "ip firewall alg" for SIP in the Adtran.
Looking here:
15:24:50.939 SIP.STACK MSG Rx: UDP src=64.94.196.103:5060 dst=192.168.0.248:5060
15:24:50.939 SIP.STACK MSG SIP/2.0 403 Forbidden (Bad auth)
the problem is a mismatch in authentication parameters. The Cisco ASA isn't the issue. The SIP registrar doesn't agree with the TA900 as far as authentication parameters.
These are typically a triplet:
SIP identity (Broadsoft calls this line port).
This is the sip-identity defined under the voice user. It is frequently the same as the phone number but this isn't required.
Authorization username
This is the auth-name parameter defined under the sip-identity. It too is frequently the same as the phone number but this isn't required.
Authorization password
This is the password parameter defined on the same line as the auth-name. In your case it is stored encrypted because you have service password-encryption enabled (a good thing).
Any mismatch in any of these parameters will result in the authentication failing.
You may want to engage the support of coredial.com in terms of what they're seeing and what they expect.
It could be a simple terminology mismatch where you and they have swapped the SIP identity and the Authorization username.
Make sure the SIP realm, SIP identity, username, and password match what you have. You will never see the password sent in the clear over the wire. It's a two-step process.
The first REGISTER is sent with no authentication.
The first response will always come back as 401 unauthorized. The SIP headers will contain a random string called a "nonce".
15:24:50.894 SIP.STACK MSG Rx: UDP src=64.94.196.103:5060 dst=192.168.0.248:5060
15:24:50.895 SIP.STACK MSG SIP/2.0 401 Unauthorized
15:24:50.896 SIP.STACK MSG | WWW-Authenticate: Digest algorithm=MD5, realm="fax01.coredial.com", nonce="0f2a78ea" |
The Adtran takes that random string and performs a calculation called a hash function based on that random string and its stored password. Hash functions are designed to be one-way. The result is always the same for the same input but it is deliberately difficult to compute the input based on the output.
It then sends a second REGISTER containing the username and the result of the calculation.
15:24:50.900 SIP.STACK MSG Tx: UDP src=192.168.0.248:5060 dst=64.94.196.103:5060
15:24:50.900 SIP.STACK MSG REGISTER sip:fax01.coredial.com:5060 SIP/2.0
15:24:50.902 SIP.STACK MSG | Authorization: Digest username="sip9000001_dcttest",realm="fax01.coredial.com",nonce="0f2a78ea",uri="sip:fax01.coredial.com:5060",response="a36102fca497a512031bd76f7bfde1ae",algorithm=MD5 |
If this result matches the result that the SIP server has from its own calculation of the random string and its stored password, the passwords can be assumed to match.
The reason for this two-step process is to prevent someone from sniffing the wire and intercepting the clear-text password.
Jayh,
Thank you for all the help and detailed explanations. I got a hold of Coredial support and the tech I spoke with said he was not seeing any registered attempts from the Adtran. The cause for that was that I had the fax number they provided as the sip-identity and SIP username as the auth-name. As soon as I changed the SIP username to be the sip-identity, everything worked.