Domain not sent by UA with specific dialed number

Asterisk Asterisk Support
1

Hi Guys,

I have an Avaya phone 4620 converted from H323 to SIP, I have almost everything working except when I dial a number starting with DTMF *

When Asterisk receive the INVITE from Avaya phone the field “To” contain the number dialed *077777 but without the domain, so Asterisk return a error message 401 Unauthorized due to the missing domain.

When I dial a number like 40075 the domain telecom.test.fr is correctly sent by phone.

See below an example of a call when I dial from Avaya phone the number *077777:

<--- SIP read from UDP:10.147.116.240:5060 --->
INVITE sip:*077777 SIP/2.0
Via: SIP/2.0/UDP 10.147.116.240:5060;branch=z9hG4bKac0f54add
Max-Forwards: 70
Content-Length: 268
To: *077777 <sip:*077777>
From: 46044 <sip:46044@telecom.test.fr>;tag=e720c41b0ffa03b
Call-ID: cf9e3ae17752a4425fbbaf22598a7ceb@10.147.116.240
CSeq: 1821799987 INVITE
Route: <sip:10.147.113.73;lr>
Supported: timer
Allow: NOTIFY
Allow: REFER
Allow: OPTIONS
Allow: INVITE
Allow: ACK
Allow: CANCEL
Allow: BYE
Content-Type: application/sdp
Contact: 46044 <sip:46044@10.147.116.240:5060>
Supported: replaces
User-Agent: Avaya SIP R2.2 Endpoint Brcm Callctrl/1.5.1.0 MxSF/v3.2.6.26

v=0
o=MxSIP 0 2143443207 IN IP4 10.147.116.240
s=SIP Call
c=IN IP4 10.147.116.240
t=0 0
m=audio 34008 RTP/AVP 0 8 18 2 127
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=rtpmap:2 G726-32/8000
a=rtpmap:127 telephone-event/8000
a=ptime:20
<------------->
--- (21 headers 12 lines) ---
Sending to 10.147.116.240:5060 (NAT)
Using INVITE request as basis request - cf9e3ae17752a4425fbbaf22598a7ceb@10.147.116.240
Found peer '46044' for '46044' from 10.147.116.240:5060

<--- Reliably Transmitting (no NAT) to 10.147.116.240:5060 --->
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 10.147.116.240:5060;branch=z9hG4bKac0f54add;received=10.147.116.240
From: 46044 <sip:46044@telecom.test.fr>;tag=e720c41b0ffa03b
To: *077777 <sip:*077777>;tag=as4a3c298e
Call-ID: cf9e3ae17752a4425fbbaf22598a7ceb@10.147.116.240
CSeq: 1821799987 INVITE
Server: DTC
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="69023bd1"
Content-Length: 0

See below an example when I dial number 40075 domain name is correctly indicated into the INVITE:

<--- SIP read from UDP:10.147.116.240:5060 --->
INVITE sip:40075@telecom.test.fr SIP/2.0
Via: SIP/2.0/UDP 10.147.116.240:5060;branch=z9hG4bK177745ee3
Max-Forwards: 70
Content-Length: 268
To: 40075 <sip:40075@telecom.test.fr>
From: 46044 <sip:46044@telecom.test.fr>;tag=525fc3f33445702
Call-ID: dc25ef649c58d8909d06fc57065fe494@10.147.116.240
CSeq: 328660852 INVITE
Route: <sip:10.147.113.73;lr>
Supported: timer
Allow: NOTIFY
Allow: REFER
Allow: OPTIONS
Allow: INVITE
Allow: ACK
Allow: CANCEL
Allow: BYE
Contact: 46044 <sip:46044@10.147.116.240:5060>
Content-Type: application/sdp
Supported: replaces
Authorization:Digest response="22e530e0f093ae7d6804c9ceb91410dd",username="46044",realm="asterisk",nonce="20d0f315",algorithm=MD5,uri="sip:40075@telecom.test.fr"
User-Agent: Avaya SIP R2.2 Endpoint Brcm Callctrl/1.5.1.0 MxSF/v3.2.6.26

So if it’s a bug on Avaya Phone do there is a way to force Asterisk to add a domain when there is nothing indicated into the INVITE ?

Thanks a lot for your advice.

Best Regards.

Cyril

2

A malformed To will not cause an authentication problem.

The 401 response is normal. The actual problem is that the phone has not repeated the request with a password included. This may mean that it has not been configured with a password, or it may mean the response never reached it.

Whilst I think the To: is invalid, and more precisely the INVITE method parameter is invalid, t should still be possible to handle that by explicitly examining the To: header.

3

Hi,

Apparently the phone is able to answer with a password when dialing any others numbers than *077777 so it doesn’t looks to be an issue for the phone to do it, the issue only occurs when phone try to call this extension number *077777 if you look the “To:”, domain is not sent so I was interesting to add it on Asterisk side when it was not provided by the phone.

Any way to force it ?

Thanks for the advice

Regards

4

The To domain isn’t used by Asterisk. The problem you actually have with Asterisk is that it will assume that there is no user part, and probably route to the “s” extension.

You can’t change the values used in the response. That would be a protocol violation. Maybe the phone is shooting itself in the foot by sending a To header that it doesn’t recognize as its own?

PS. Note that the actual protocol violation here is the presence of the * in a host name. It is legal to miss the user part and the @.

5

Hi David,

When I’m using any others UA and dial *077777 it works, there is apparently no protocol violation, see below a trace when I dial this number from Counterpath Bria, but when I dial from Avaya phone until I put “sip set debug peer 46044” I see no information into Asterisk in debug and verbose mode call doesn’t try to go to “s” extension if it was the case it would easy to sort out:

Call made from Counterpath Bria:

<--- SIP read from UDP:10.147.116.67:16230 --->
INVITE sip:*077777@telecom.test.fr;transport=udp SIP/2.0
Via: SIP/2.0/UDP 10.147.116.67:16230;branch=z9hG4bK-d8754z-4199f1ad77974d00-1---d8754z-;rport
Max-Forwards: 70
Contact: <sip:46000@10.147.116.67:16230;transport=udp>
To: <sip:*077777@telecom.test.fr>
From: "Cyril <40075>"<sip:46000@telecom.test.fr>;tag=e79476ea
Call-ID: Mzg4ZTEyOGJiZDVhNDZlMzlhODYzMzM5ZWI5ZDIxYjU
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
Content-Type: application/sdp
Supported: replaces
User-Agent: Bria 3 release 3.4.3 stamp 68291
Content-Length: 289

v=0
o=- 12996148229839844 1 IN IP4 10.147.116.67
s=CounterPath Bria 3.3
c=IN IP4 10.147.116.67
t=0 0
m=audio 15524 RTP/AVP 8 0 9 97 105 98 101
a=rtpmap:97 SPEEX/8000
a=rtpmap:105 SPEEX-FEC/8000
a=rtpmap:98 iLBC/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
<------------->
--- (13 headers 12 lines) ---
Sending to 10.147.116.67:16230 (NAT)
Using INVITE request as basis request - Mzg4ZTEyOGJiZDVhNDZlMzlhODYzMzM5ZWI5ZDIxYjU
Found peer '46000' for '46000' from 10.147.116.67:16230

<--- Reliably Transmitting (no NAT) to 10.147.116.67:16230 --->
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 10.147.116.67:16230;branch=z9hG4bK-d8754z-4199f1ad77974d00-1---d8754z-;received=10.147.116.67;rport=16230
From: "Cyril <40075>"<sip:46000@telecom.test.fr>;tag=e79476ea
To: <sip:*077777@telecom.test.fr>;tag=as794e3dc2
Call-ID: Mzg4ZTEyOGJiZDVhNDZlMzlhODYzMzM5ZWI5ZDIxYjU
CSeq: 1 INVITE
Server: DTC
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
upported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="2dd67708"
Content-Length: 0


<------------>
Scheduling destruction of SIP dialog 'Mzg4ZTEyOGJiZDVhNDZlMzlhODYzMzM5ZWI5ZDIxYjU' in 6400 ms (Method: INVITE)

<--- SIP read from UDP:10.147.116.67:16230 --->
ACK sip:*077777@telecom.test.fr;transport=udp SIP/2.0
Via: SIP/2.0/UDP 10.147.116.67:16230;branch=z9hG4bK-d8754z-4199f1ad77974d00-1---d8754z-;rport
Max-Forwards: 70
To: <sip:*077777@telecom.test.fr>;tag=as794e3dc2
From: "Cyril <40075>"<sip:46000@telecom.test.fr>;tag=e79476ea
Call-ID: Mzg4ZTEyOGJiZDVhNDZlMzlhODYzMzM5ZWI5ZDIxYjU
CSeq: 1 ACK
Content-Length: 0

<------------->
--- (8 headers 0 lines) ---

<--- SIP read from UDP:10.147.116.67:16230 --->
INVITE sip:*077777@telecom.test.fr;transport=udp SIP/2.0
Via: SIP/2.0/UDP 10.147.116.67:16230;branch=z9hG4bK-d8754z-2b80360fc9bc167d-1---d8754z-;rport
Max-Forwards: 70
Contact: <sip:46000@10.147.116.67:16230;transport=udp>
To: <sip:*077777@telecom.test.fr>
From: "Cyril <40075>"<sip:46000@telecom.test.fr>;tag=e79476ea
Call-ID: Mzg4ZTEyOGJiZDVhNDZlMzlhODYzMzM5ZWI5ZDIxYjU
CSeq: 2 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
Content-Type: application/sdp
Supported: replaces
User-Agent: Bria 3 release 3.4.3 stamp 68291
Authorization: Digest username="46000",realm="asterisk",nonce="2dd67708",uri="sip:*077777@telecom.test.fr;transport=udp",response="edaecb460b5a512a19b5d4fbe1f42f4f",algorithm=MD5
Content-Length: 289

v=0
o=- 12996148229839844 1 IN IP4 10.147.116.67
s=CounterPath Bria 3.3
c=IN IP4 10.147.116.67
t=0 0
m=audio 15524 RTP/AVP 8 0 9 97 105 98 101
a=rtpmap:97 SPEEX/8000
a=rtpmap:105 SPEEX-FEC/8000
a=rtpmap:98 iLBC/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
<------------->
--- (14 headers 12 lines) ---
Sending to 10.147.116.67:16230 (no NAT)
Using INVITE request as basis request - Mzg4ZTEyOGJiZDVhNDZlMzlhODYzMzM5ZWI5ZDIxYjU
Found peer '46000' for '46000' from 10.147.116.67:16230
  == Using SIP RTP CoS mark 5
Found RTP audio format 8
Found RTP audio format 0
Found RTP audio format 9
Found RTP audio format 97
Found RTP audio format 105
Found RTP audio format 98
Found RTP audio format 101
Found audio description format SPEEX for ID 97
Found unknown media description format SPEEX-FEC for ID 105
Found audio description format iLBC for ID 98
Found audio description format telephone-event for ID 101
Capabilities: us - 0x38160c (ulaw|alaw|speex|ilbc|g722|h263|h263p|h264), peer - audio=0x160c (ulaw|alaw|speex|ilbc|g722)/video=0x0 (nothing)/text=0x0 (nothing), combined - 0x160c (ulaw|alaw|speex|ilbc|g722)
Non-codec capabilities (dtmf): us - 0x1 (telephone-event|), peer - 0x1 (telephone-event|), combined - 0x1 (telephone-event|)
Peer audio RTP is at port 10.147.116.67:15524
Peer doesn't provide video
Looking for *077777 in from-sip (domain telecom.test.fr)
list_route: hop: <sip:46000@10.147.116.67:16230;transport=udp>

<--- Transmitting (no NAT) to 10.147.116.67:16230 --->
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.147.116.67:16230;branch=z9hG4bK-d8754z-2b80360fc9bc167d-1---d8754z-;received=10.147.116.67;rport=16230
From: "Cyril <40075>"<sip:46000@telecom.test.fr>;tag=e79476ea
To: <sip:*077777@telecom.test.fr>
Call-ID: Mzg4ZTEyOGJiZDVhNDZlMzlhODYzMzM5ZWI5ZDIxYjU
CSeq: 2 INVITE
Server: DTC
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Contact: <sip:*077777@10.147.113.73:5060>
Content-Length: 0


<------------>
    -- Executing [*077777@from-sip:1] SIPDtmfMode("SIP/46000-000028ca", "info") in new stack
    -- Executing [*077777@from-sip:2] Dial("SIP/46000-000028ca", "OOH323/*077777@Avaya") in new stack
    -- Called OOH323/*077777@Avaya
    -- OOH323/Avaya-11917 is ringing

Call made from Avaya phone with complete traces:


<--- SIP read from UDP:10.147.116.240:5060 --->
INVITE sip:*077777 SIP/2.0
Via: SIP/2.0/UDP 10.147.116.240:5060;branch=z9hG4bK70b2cf7b9
Max-Forwards: 70
Content-Length: 267
To: *077777 <sip:*077777>
From: 46044 <sip:46044@telecom.test.fr>;tag=ca0acd93a05f67a
Call-ID: 282e644180cf8640790ee437a0d3c0bc@10.147.116.240
CSeq: 561178912 INVITE
Route: <sip:10.147.113.73;lr>
Supported: timer
Allow: NOTIFY
Allow: REFER
Allow: OPTIONS
Allow: INVITE
Allow: ACK
Allow: CANCEL
Allow: BYE
Content-Type: application/sdp
Contact: 46044 <sip:46044@10.147.116.240:5060>
Supported: replaces
User-Agent: Avaya SIP R2.2 Endpoint Brcm Callctrl/1.5.1.0 MxSF/v3.2.6.26

v=0
o=MxSIP 0 613651292 IN IP4 10.147.116.240
s=SIP Call
c=IN IP4 10.147.116.240
t=0 0
m=audio 34008 RTP/AVP 0 8 18 2 127
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=rtpmap:2 G726-32/8000
a=rtpmap:127 telephone-event/8000
a=ptime:20
<------------->
--- (21 headers 12 lines) ---
Sending to 10.147.116.240:5060 (NAT)
Using INVITE request as basis request - 282e644180cf8640790ee437a0d3c0bc@10.147.116.240
Found peer '46044' for '46044' from 10.147.116.240:5060

<--- Reliably Transmitting (no NAT) to 10.147.116.240:5060 --->
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 10.147.116.240:5060;branch=z9hG4bK70b2cf7b9;received=10.147.116.240
From: 46044 <sip:46044@telecom.test.fr>;tag=ca0acd93a05f67a
To: *077777 <sip:*077777>;tag=as052ba87a
Call-ID: 282e644180cf8640790ee437a0d3c0bc@10.147.116.240
CSeq: 561178912 INVITE
Server: DTC
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="157b6ce6"
Content-Length: 0


<------------>
Scheduling destruction of SIP dialog '282e644180cf8640790ee437a0d3c0bc@10.147.116.240' in 6400 ms (Method: INVITE)
Retransmitting #1 (no NAT) to 10.147.116.240:5060:
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 10.147.116.240:5060;branch=z9hG4bK70b2cf7b9;received=10.147.116.240
From: 46044 <sip:46044@telecom.test.fr>;tag=ca0acd93a05f67a
To: *077777 <sip:*077777>;tag=as052ba87a
Call-ID: 282e644180cf8640790ee437a0d3c0bc@10.147.116.240
CSeq: 561178912 INVITE
Server: DTC
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="157b6ce6"
Content-Length: 0


---
Retransmitting #2 (no NAT) to 10.147.116.240:5060:
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 10.147.116.240:5060;branch=z9hG4bK70b2cf7b9;received=10.147.116.240
From: 46044 <sip:46044@telecom.test.fr>;tag=ca0acd93a05f67a
To: *077777 <sip:*077777>;tag=as052ba87a
Call-ID: 282e644180cf8640790ee437a0d3c0bc@10.147.116.240
CSeq: 561178912 INVITE
Server: DTC
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="157b6ce6"
Content-Length: 0


---

<--- SIP read from UDP:10.147.116.240:5060 --->
INVITE sip:*077777 SIP/2.0
Via: SIP/2.0/UDP 10.147.116.240:5060;branch=z9hG4bK70b2cf7b9
Max-Forwards: 70
Content-Length: 267
To: *077777 <sip:*077777>
From: 46044 <sip:46044@telecom.test.fr>;tag=ca0acd93a05f67a
Call-ID: 282e644180cf8640790ee437a0d3c0bc@10.147.116.240
CSeq: 561178912 INVITE
Route: <sip:10.147.113.73;lr>
Supported: timer
Allow: NOTIFY
Allow: REFER
Allow: OPTIONS
Allow: INVITE
Allow: ACK
Allow: CANCEL
Allow: BYE
Content-Type: application/sdp
Contact: 46044 <sip:46044@10.147.116.240:5060>
Supported: replaces
User-Agent: Avaya SIP R2.2 Endpoint Brcm Callctrl/1.5.1.0 MxSF/v3.2.6.26

v=0
o=MxSIP 0 613651292 IN IP4 10.147.116.240
s=SIP Call
c=IN IP4 10.147.116.240
t=0 0
m=audio 34008 RTP/AVP 0 8 18 2 127
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=rtpmap:2 G726-32/8000
a=rtpmap:127 telephone-event/8000
a=ptime:20
<------------->
--- (21 headers 12 lines) ---
Ignoring this INVITE request
Retransmitting #3 (no NAT) to 10.147.116.240:5060:
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 10.147.116.240:5060;branch=z9hG4bK70b2cf7b9;received=10.147.116.240
From: 46044 <sip:46044@telecom.test.fr>;tag=ca0acd93a05f67a
To: *077777 <sip:*077777>;tag=as052ba87a
Call-ID: 282e644180cf8640790ee437a0d3c0bc@10.147.116.240
CSeq: 561178912 INVITE
Server: DTC
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="157b6ce6"
Content-Length: 0


---
Retransmitting #4 (no NAT) to 10.147.116.240:5060:
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 10.147.116.240:5060;branch=z9hG4bK70b2cf7b9;received=10.147.116.240
From: 46044 <sip:46044@telecom.test.fr>;tag=ca0acd93a05f67a
To: *077777 <sip:*077777>;tag=as052ba87a
Call-ID: 282e644180cf8640790ee437a0d3c0bc@10.147.116.240
CSeq: 561178912 INVITE
Server: DTC
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="157b6ce6"
Content-Length: 0


---

<--- SIP read from UDP:10.147.116.240:5060 --->
INVITE sip:*077777 SIP/2.0
Via: SIP/2.0/UDP 10.147.116.240:5060;branch=z9hG4bK70b2cf7b9
Max-Forwards: 70
Content-Length: 267
To: *077777 <sip:*077777>
From: 46044 <sip:46044@telecom.test.fr>;tag=ca0acd93a05f67a
Call-ID: 282e644180cf8640790ee437a0d3c0bc@10.147.116.240
CSeq: 561178912 INVITE
Route: <sip:10.147.113.73;lr>
Supported: timer
Allow: NOTIFY
Allow: REFER
Allow: OPTIONS
Allow: INVITE
Allow: ACK
Allow: CANCEL
Allow: BYE
Content-Type: application/sdp
Contact: 46044 <sip:46044@10.147.116.240:5060>
Supported: replaces
User-Agent: Avaya SIP R2.2 Endpoint Brcm Callctrl/1.5.1.0 MxSF/v3.2.6.26

v=0
o=MxSIP 0 613651292 IN IP4 10.147.116.240
s=SIP Call
c=IN IP4 10.147.116.240
t=0 0
m=audio 34008 RTP/AVP 0 8 18 2 127
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=rtpmap:2 G726-32/8000
a=rtpmap:127 telephone-event/8000
a=ptime:20
<------------->
--- (21 headers 12 lines) ---
Ignoring this INVITE request
Retransmitting #5 (no NAT) to 10.147.116.240:5060:
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 10.147.116.240:5060;branch=z9hG4bK70b2cf7b9;received=10.147.116.240
From: 46044 <sip:46044@telecom.test.fr>;tag=ca0acd93a05f67a
To: *077777 <sip:*077777>;tag=as052ba87a
Call-ID: 282e644180cf8640790ee437a0d3c0bc@10.147.116.240
CSeq: 561178912 INVITE
Server: DTC
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="157b6ce6"
Content-Length: 0


---

<--- SIP read from UDP:10.147.116.240:5060 --->
INVITE sip:*077777 SIP/2.0
Via: SIP/2.0/UDP 10.147.116.240:5060;branch=z9hG4bK70b2cf7b9
Max-Forwards: 70
Content-Length: 267
To: *077777 <sip:*077777>
From: 46044 <sip:46044@telecom.test.fr>;tag=ca0acd93a05f67a
Call-ID: 282e644180cf8640790ee437a0d3c0bc@10.147.116.240
CSeq: 561178912 INVITE
Route: <sip:10.147.113.73;lr>
Supported: timer
Allow: NOTIFY
Allow: REFER
Allow: OPTIONS
Allow: INVITE
Allow: ACK
Allow: CANCEL
Allow: BYE
Content-Type: application/sdp
Contact: 46044 <sip:46044@10.147.116.240:5060>
Supported: replaces
User-Agent: Avaya SIP R2.2 Endpoint Brcm Callctrl/1.5.1.0 MxSF/v3.2.6.26

v=0
o=MxSIP 0 613651292 IN IP4 10.147.116.240
s=SIP Call
c=IN IP4 10.147.116.240
t=0 0
m=audio 34008 RTP/AVP 0 8 18 2 127
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=rtpmap:2 G726-32/8000
a=rtpmap:127 telephone-event/8000
a=ptime:20
<------------->
--- (21 headers 12 lines) ---
Ignoring this INVITE request
Really destroying SIP dialog '67ce24ad67a14a6d0359c2ea8987c7e9@10.147.116.240' Method: INVITE
Retransmitting #6 (no NAT) to 10.147.116.240:5060:
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 10.147.116.240:5060;branch=z9hG4bK70b2cf7b9;received=10.147.116.240
From: 46044 <sip:46044@telecom.test.fr>;tag=ca0acd93a05f67a
To: *077777 <sip:*077777>;tag=as052ba87a
Call-ID: 282e644180cf8640790ee437a0d3c0bc@10.147.116.240
CSeq: 561178912 INVITE
Server: DTC
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="157b6ce6"
Content-Length: 0

Thanks for your advice.

Best Regards

6

There is an undetected (by Asterisk) protocol violation. Either the UAC is not receiving the responses (firewall, etc.) or it is expecting a conforming To header, even though not sending one.

Asterisk is recognizing the Avaya as a valid peer, and is responding with the best possible status given that a password has not been provided, to what appears to be the correct address, including port. It is expecting to get an ACK back followed by an INVITE including the authentication data. It is not getting an ACK, and the re-transmissions by the Avaya indicate that the Avaya is either not receiving the response, or failing to recognize it as matching its request.

7

Well it’s pointing to be an issue on Avaya phone SIP firmware which are not sending domain when dialing a number starting with “*”.

In H323 “*” could be considered on Avaya as a “Feature Access code” maybe that Avaya phone doesn’t interpret it as a dialed number, so probably in their SIP firmware.

Unfortunately Avaya will not change their firmrware for me.

Thanks

8

You can’t fix it in Asterisk, as Asterisk is already doing its best effort. if you could change the To header, the Avaya really ought to reject it, as it differs from what it sent!

I suppose you could guess that the Avaya is expecting the domain, but you would have to change the Asterisk source code to make it mangle the To: header value. You are trying to work round a bug when you are not completely sure what is going wrong, and it is in a system that you cannot control.

9

Hi David,

Yes it doesn’t looks good to modify code on Asterisk side to handle a bug on Avaya side.

I’ll try to see with Avaya.

Thanks for your support.

Have a nice day.

Best Regards.