Avaya 9650: Every other call is failing and goes to fast busy!


#1

I have received a couple of Avaya 9650 phones that I am now hooking up to Asterisk. I got the phones to upgrade to a SIP firmware, get the settings and log into Asterisk. So far, so good. I am also able to make calls, however, every other call initiation ends in the fast busy tone. Dialing the same number again will result in a proper call setup.

With a wireshark trace of the traffic, I can see that the phone sends an INVITE with an “Authentication:” header:

INVITE sip:102@pbx01.SYN-bit.office SIP/2.0
From: sip:103@pbx01.syn-bit.office;tag=2864ec215c5f026b5c6ab778_F10310.0.4.101
To: sip:102@pbx01.syn-bit.office
Call-ID: 16_bb2a8-fd5cacd5c6ab518_I@10.0.4.101
CSeq: 22 INVITE
Via: SIP/2.0/TCP 10.0.4.101;branch=z9hG4bK16_bb2a8-7c0d9c7a5c6abde6_I103
Content-Length: 342
Max-Forwards: 70
Contact: <sip:103@10.0.4.101;transport=tcp>
Accept-Language: en
Allow: INVITE,CANCEL,BYE,ACK,SUBSCRIBE,NOTIFY,MESSAGE,INFO,PUBLISH,REFER,UPDATE,PRACK
Authorization: Digest username="103",realm="asterisk",nonce="59ddc9d2",uri="sip:102@pbx01.SYN-bit.office",response="4dd20c3ff91f8a750e14ae2a25dd164f"
Content-Type: application/sdp
User-Agent: Avaya one-X Deskphone 2.6.17.0 (43258)
Supported: eventlist, 100rel

Asterisk then responds with a “401 Unauthorized”:

SIP/2.0 401 Unauthorized
Via: SIP/2.0/TCP 10.0.4.101;branch=z9hG4bK16_bb2a8-7c0d9c7a5c6abde6_I103;received=10.0.4.101
From: sip:103@pbx01.syn-bit.office;tag=2864ec215c5f026b5c6ab778_F10310.0.4.101
To: sip:102@pbx01.syn-bit.office;tag=as3a015245
Call-ID: 16_bb2a8-fd5cacd5c6ab518_I@10.0.4.101
CSeq: 22 INVITE
Server: VitalPBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="569ce458"
Content-Length: 0

The phone then sends an ACK with “Authorization” header, instead of sending an new INVITE.

I assume the phone interprets this “401 Unauthorized” message not as a username/password failure (as it knows the username/password combination is correct) but as an “Not authorized to call XXX”.

On the second call, the INVITE does not have an “Authorization:” header and when Asterisk sends a “401 Unauthorized”, the phone does send a new INVITE with an “Authorization:” header.

After a lot of googling and RFC reading, I have the following questions:

  • In RFC 2617 I read that when a nonce is not valid anymore, “stale=True” SHOULD be added to the WWW-Authenticate header to tell the client that the username/password were correct, but that it should use the new (provided) nonce to recreate a new “Authorization” header. In the source code of “channels/chan_sip.c” that the stale variable is added for a REGISTER request, however, I do not see why it is not added for an INVITE request. Is there a particular reason this was not implemented? Should this be filed as a bug?

  • I’m not sure the phone is correct in sending out an INVITE with an “Authorization:” header, using a nonce that has already been used before. As per the name (number once) of nonce, I assume it may not be used again. Is there any document specifically prohibiting the use of a new “Authentication:” header based on a previous nonce? This would help in getting it fixed on the Avaya side :slight_smile:

  • I have read a similar report on http://forums.asterisk.org/viewtopic.php?f=1&t=84786 which suggests to use Avaya firmware version 2.6.7. However, this version is ancient and can not be downloaded anymore. Can someone provide me with this version so I can test it to see if the behavior is indeed different? This could help too in taking this up with Avaya.

Cheers,
Sake


#2

I would say that this is an Avaya problem. It is clear that the UAS is allowed to reject the previously used Authorization and provide a new nonce for Authorization in a 401. As you mentioned about the usage of “stale=True”, it is a SHOULD and not a MUST, and so I think the UAC must be designed in a way in which it does not depend on this. It seems to me that the Avaya endpoint is behaving according to this section of RFC 3261 even though it does not apply in this case:

" Under an authentication scheme that uses responses to carry values
used to compute nonces (such as Digest), some problems come up for
any requests that take no response, including ACK. For this reason,
any credentials in the INVITE that were accepted by a server MUST be
accepted by that server for the ACK. UACs creating an ACK message
will duplicate all of the Authorization and Proxy-Authorization
header field values that appeared in the INVITE to which the ACK
corresponds. Servers MUST NOT attempt to challenge an ACK."

So, it seems to me that the Avaya endpoint is acting as if the credentials in the INVITE were accepted, but they weren’t.