[asterisk-bugs] [Asterisk 0015395]: Dialling Fast on SIP (484) Does not match Dialplan
Asterisk Bug Tracker
noreply at bugs.digium.com
Thu Aug 20 13:04:46 CDT 2009
A NOTE has been added to this issue.
======================================================================
https://issues.asterisk.org/view.php?id=15395
======================================================================
Reported By: leobrown
Assigned To:
======================================================================
Project: Asterisk
Issue ID: 15395
Category: Channels/chan_sip/General
Reproducibility: always
Severity: minor
Priority: normal
Status: new
Asterisk Version: 1.6.0.6
Regression: No
SVN Branch (only for SVN checkouts, not tarball releases): N/A
SVN Revision (number only!):
Request Review:
======================================================================
Date Submitted: 2009-06-25 07:16 CDT
Last Modified: 2009-08-20 13:04 CDT
======================================================================
Summary: Dialling Fast on SIP (484) Does not match Dialplan
Description:
I am using the asterisk 484 response on a SIP device to control dial
patterns. In this mode, every digit dialled is sent, and only when the
number is matched by Asterisk is the call connected.
However, I am finding that for a short pattern (00 in this case), if the
two digits are dialled faster than about 200ms then the dialplan pattern
for these two digits are not matched.
The dialplan is a very simple form:
00 => {
Answer();
Read(number);
}
The slow (correct) form is shown just below. The incorrect (fast) form is
shown in additional information.
I have attempted a work around using _00. and then adding ${EXTEN} to a
read variable, but I again get strange results when dialing fast.
<--- SIP read from UDP://87.81.167.157:5062 --->
INVITE sip:0 at trunk1.netfuse.org SIP/2.0
Via: SIP/2.0/UDP 10.10.1.4:5062;branch=z9hG4bK442b133eade944e1;rport
From: "Leo Brown"
<sip:leo_kitchen at trunk1.netfuse.org>;tag=25621cf32c2e44b8
To: <sip:0 at trunk1.netfuse.org>
Contact: <sip:leo_kitchen at 87.81.167.157:5062;transport=udp>
Supported: replaces, timer, path
Call-ID: 8c0a8e3ebbf4d665 at 10.10.1.4
CSeq: 61064 INVITE
User-Agent: Grandstream GXP2000 1.1.6.37
Max-Forwards: 70
Allow:
INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE,UPDATE,PRACK,MESSAGE
Content-Type: application/sdp
Content-Length: 188
v=0
o=leo_kitchen 8000 8000 IN IP4 87.81.167.157
s=SIP Call
c=IN IP4 87.81.167.157
t=0 0
m=audio 5004 RTP/AVP 0 8
a=sendrecv
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=ptime:20
<------------->
--- (13 headers 10 lines) ---
Sending to 87.81.167.157 : 5062 (NAT)
Using INVITE request as basis request - 8c0a8e3ebbf4d665 at 10.10.1.4
Found user 'leo_kitchen' for 'leo_kitchen'
<--- Reliably Transmitting (NAT) to 87.81.167.157:5062 --->
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP
10.10.1.4:5062;branch=z9hG4bK442b133eade944e1;received=87.81.167.157;rport=5062
From: "Leo Brown"
<sip:leo_kitchen at trunk1.netfuse.org>;tag=25621cf32c2e44b8
To: <sip:0 at trunk1.netfuse.org>;tag=as4f02f000
Call-ID: 8c0a8e3ebbf4d665 at 10.10.1.4
CSeq: 61064 INVITE
User-Agent: Asterisk PBX 1.6.0.9
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm="asterisk",
nonce="40b9b6a8"
Content-Length: 0
<------------>
Scheduling destruction of SIP dialog '8c0a8e3ebbf4d665 at 10.10.1.4' in 32000
ms (Method: INVITE)
trunk1*CLI>
<--- SIP read from UDP://87.81.167.157:5062 --->
ACK sip:0 at trunk1.netfuse.org SIP/2.0
Via: SIP/2.0/UDP 10.10.1.4:5062;branch=z9hG4bK442b133eade944e1;rport
From: "Leo Brown"
<sip:leo_kitchen at trunk1.netfuse.org>;tag=25621cf32c2e44b8
To: <sip:0 at trunk1.netfuse.org>;tag=as4f02f000
Contact: <sip:leo_kitchen at 87.81.167.157:5062;transport=udp>
Supported: path
Call-ID: 8c0a8e3ebbf4d665 at 10.10.1.4
CSeq: 61064 ACK
User-Agent: Grandstream GXP2000 1.1.6.37
Max-Forwards: 70
Allow:
INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE,UPDATE,PRACK,MESSAGE
Content-Length: 0
<------------->
--- (12 headers 0 lines) ---
trunk1*CLI>
<--- SIP read from UDP://87.81.167.157:5062 --->
INVITE sip:0 at trunk1.netfuse.org SIP/2.0
Via: SIP/2.0/UDP 10.10.1.4:5062;branch=z9hG4bKdb26531f412fd122;rport
From: "Leo Brown"
<sip:leo_kitchen at trunk1.netfuse.org>;tag=25621cf32c2e44b8
To: <sip:0 at trunk1.netfuse.org>
Contact: <sip:leo_kitchen at 87.81.167.157:5062;transport=udp>
Supported: replaces, timer, path
Authorization: Digest username="leo_kitchen", realm="asterisk",
algorithm=MD5, uri="sip:0 at trunk1.netfuse.org", nonce="40b9b6a8",
response="bd0834f23cadeadae6874336898f00b9"
Call-ID: 8c0a8e3ebbf4d665 at 10.10.1.4
CSeq: 61065 INVITE
User-Agent: Grandstream GXP2000 1.1.6.37
Max-Forwards: 70
Allow:
INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE,UPDATE,PRACK,MESSAGE
Content-Type: application/sdp
Content-Length: 188
v=0
o=leo_kitchen 8000 8001 IN IP4 87.81.167.157
s=SIP Call
c=IN IP4 87.81.167.157
t=0 0
m=audio 5004 RTP/AVP 0 8
a=sendrecv
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=ptime:20
<------------->
--- (14 headers 10 lines) ---
Sending to 87.81.167.157 : 5062 (NAT)
Using INVITE request as basis request - 8c0a8e3ebbf4d665 at 10.10.1.4
Found user 'leo_kitchen' for 'leo_kitchen'
Found RTP audio format 0
Found RTP audio format 8
Peer audio RTP is at port 87.81.167.157:5004
Found audio description format PCMU for ID 0
Found audio description format PCMA for ID 8
Capabilities: us - 0xc (ulaw|alaw), peer - audio=0xc (ulaw|alaw)/video=0x0
(nothing)/text=0x0 (nothing), combined - 0xc (ulaw|alaw)
Non-codec capabilities (dtmf): us - 0x1 (telephone-event), peer - 0x0
(nothing), combined - 0x0 (nothing)
Peer audio RTP is at port 87.81.167.157:5004
Looking for 0 in acumen (domain trunk1.netfuse.org)
<--- Reliably Transmitting (NAT) to 87.81.167.157:5062 --->
SIP/2.0 484 Address Incomplete
Via: SIP/2.0/UDP
10.10.1.4:5062;branch=z9hG4bKdb26531f412fd122;received=87.81.167.157;rport=5062
From: "Leo Brown"
<sip:leo_kitchen at trunk1.netfuse.org>;tag=25621cf32c2e44b8
To: <sip:0 at trunk1.netfuse.org>;tag=as4f02f000
Call-ID: 8c0a8e3ebbf4d665 at 10.10.1.4
CSeq: 61065 INVITE
User-Agent: Asterisk PBX 1.6.0.9
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces, timer
Content-Length: 0
<------------>
Scheduling destruction of SIP dialog '8c0a8e3ebbf4d665 at 10.10.1.4' in 32000
ms (Method: INVITE)
trunk1*CLI>
<--- SIP read from UDP://87.81.167.157:5062 --->
ACK sip:0 at trunk1.netfuse.org SIP/2.0
Via: SIP/2.0/UDP 10.10.1.4:5062;branch=z9hG4bKdb26531f412fd122;rport
From: "Leo Brown"
<sip:leo_kitchen at trunk1.netfuse.org>;tag=25621cf32c2e44b8
To: <sip:0 at trunk1.netfuse.org>;tag=as4f02f000
Contact: <sip:leo_kitchen at 87.81.167.157:5062;transport=udp>
Supported: path
Authorization: Digest username="leo_kitchen", realm="asterisk",
algorithm=MD5, uri="sip:0 at trunk1.netfuse.org", nonce="40b9b6a8",
response="bd0834f23cadeadae6874336898f00b9"
Call-ID: 8c0a8e3ebbf4d665 at 10.10.1.4
CSeq: 61065 ACK
User-Agent: Grandstream GXP2000 1.1.6.37
Max-Forwards: 70
Allow:
INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE,UPDATE,PRACK,MESSAGE
Content-Length: 0
<------------->
--- (13 headers 0 lines) ---
trunk1*CLI>
<--- SIP read from UDP://87.81.167.157:5062 --->
INVITE sip:00 at trunk1.netfuse.org SIP/2.0
Via: SIP/2.0/UDP 10.10.1.4:5062;branch=z9hG4bK597deb3c9b6c1bc3;rport
From: "Leo Brown"
<sip:leo_kitchen at trunk1.netfuse.org>;tag=25621cf32c2e44b8
To: <sip:00 at trunk1.netfuse.org>;tag=as4f02f000
Contact: <sip:leo_kitchen at 87.81.167.157:5062;transport=udp>
Supported: replaces, timer, path
Authorization: Digest username="leo_kitchen", realm="asterisk",
algorithm=MD5, uri="sip:00 at trunk1.netfuse.org", nonce="40b9b6a8",
response="05f100a9753f43d2b51271c651c3474f"
Call-ID: 8c0a8e3ebbf4d665 at 10.10.1.4
CSeq: 61066 INVITE
User-Agent: Grandstream GXP2000 1.1.6.37
Max-Forwards: 70
Allow:
INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE,UPDATE,PRACK,MESSAGE
Content-Type: application/sdp
Content-Length: 188
v=0
o=leo_kitchen 8000 8002 IN IP4 87.81.167.157
s=SIP Call
c=IN IP4 87.81.167.157
t=0 0
m=audio 5004 RTP/AVP 0 8
a=sendrecv
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=ptime:20
<------------->
--- (14 headers 10 lines) ---
Sending to 87.81.167.157 : 5062 (NAT)
Using INVITE request as basis request - 8c0a8e3ebbf4d665 at 10.10.1.4
Found user 'leo_kitchen' for 'leo_kitchen'
Found RTP audio format 0
Found RTP audio format 8
Peer audio RTP is at port 87.81.167.157:5004
Found audio description format PCMU for ID 0
Found audio description format PCMA for ID 8
Capabilities: us - 0xc (ulaw|alaw), peer - audio=0xc (ulaw|alaw)/video=0x0
(nothing)/text=0x0 (nothing), combined - 0xc (ulaw|alaw)
Non-codec capabilities (dtmf): us - 0x1 (telephone-event), peer - 0x0
(nothing), combined - 0x0 (nothing)
Peer audio RTP is at port 87.81.167.157:5004
Looking for 00 in acumen (domain trunk1.netfuse.org)
list_route: hop: <sip:leo_kitchen at 87.81.167.157:5062;transport=udp>
<--- Transmitting (NAT) to 87.81.167.157:5062 --->
SIP/2.0 100 Trying
Via: SIP/2.0/UDP
10.10.1.4:5062;branch=z9hG4bK597deb3c9b6c1bc3;received=87.81.167.157;rport=5062
From: "Leo Brown"
<sip:leo_kitchen at trunk1.netfuse.org>;tag=25621cf32c2e44b8
To: <sip:00 at trunk1.netfuse.org>;tag=as4f02f000
Call-ID: 8c0a8e3ebbf4d665 at 10.10.1.4
CSeq: 61066 INVITE
User-Agent: Asterisk PBX 1.6.0.9
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces, timer
Contact: <sip:00 at 85.13.242.9>
Content-Length: 0
<------------>
-- Executing [00 at acumen:1] Answer("SIP/leo_kitchen-08315000", "") in
new stack
Audio is at 85.13.242.9 port 17842
Adding codec 0x8 (alaw) to SDP
Adding codec 0x4 (ulaw) to SDP
<--- Reliably Transmitting (NAT) to 87.81.167.157:5062 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP
10.10.1.4:5062;branch=z9hG4bK597deb3c9b6c1bc3;received=87.81.167.157;rport=5062
From: "Leo Brown"
<sip:leo_kitchen at trunk1.netfuse.org>;tag=25621cf32c2e44b8
To: <sip:00 at trunk1.netfuse.org>;tag=as4f02f000
Call-ID: 8c0a8e3ebbf4d665 at 10.10.1.4
CSeq: 61066 INVITE
User-Agent: Asterisk PBX 1.6.0.9
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces, timer
Contact: <sip:00 at 85.13.242.9>
Content-Type: application/sdp
Content-Length: 229
v=0
o=root 2112250526 2112250526 IN IP4 85.13.242.9
s=Asterisk PBX 1.6.0.9
c=IN IP4 85.13.242.9
t=0 0
m=audio 17842 RTP/AVP 8 0
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv
<------------>
trunk1*CLI>
<--- SIP read from UDP://87.81.167.157:5062 --->
ACK sip:00 at 85.13.242.9 SIP/2.0
Via: SIP/2.0/UDP 10.10.1.4:5062;branch=z9hG4bK719964f91a152b46;rport
From: "Leo Brown"
<sip:leo_kitchen at trunk1.netfuse.org>;tag=25621cf32c2e44b8
To: <sip:00 at trunk1.netfuse.org>;tag=as4f02f000
Contact: <sip:leo_kitchen at 87.81.167.157:5062;transport=udp>
Supported: path
Authorization: Digest username="leo_kitchen", realm="asterisk",
algorithm=MD5, uri="sip:00 at trunk1.netfuse.org", nonce="40b9b6a8",
response="05f100a9753f43d2b51271c651c3474f"
Call-ID: 8c0a8e3ebbf4d665 at 10.10.1.4
CSeq: 61066 ACK
User-Agent: Grandstream GXP2000 1.1.6.37
Max-Forwards: 70
Allow:
INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE,UPDATE,PRACK,MESSAGE
Content-Length: 0
<------------->
--- (13 headers 0 lines) ---
-- Executing [00 at acumen:2] Read("SIP/leo_kitchen-08315000", "number")
in new stack
======================================================================
----------------------------------------------------------------------
(0109356) mmichelson (administrator) - 2009-08-20 13:04
https://issues.asterisk.org/view.php?id=15395#c109356
----------------------------------------------------------------------
So here's the deal for the "fast" case. The first transaction is one where
an INVITE is sent to Asterisk, Asterisk requests authentication, and the
phone ACKs.
Then, the phone sends an INVITE to '0' with CSeq 57405 and includes
authentication information. Asterisk then sends back a 484. Now, here's
where things get weird. The phone SHOULD be sending an ACK now, and then
following that up with a new INVITE to '00' with CSeq 57406. Instead, no
ACK is sent and the phone sends an INVITE to '00' with CSeq 57405. Because
the CSeq is the same as the previous one, Asterisk thinks that this is a
retransmission of the previous INVITE to '0'.
This is clearly a problem with the phone.
Issue History
Date Modified Username Field Change
======================================================================
2009-08-20 13:04 mmichelson Note Added: 0109356
======================================================================
More information about the asterisk-bugs
mailing list