[Home]

Summary:ASTERISK-17034: [regression] Can't receive SIP INFO DTMF when using Read() without Answer()
Reporter:johnnylu (johnnylu)Labels:
Date Opened:2010-11-26 23:20:39.000-0600Date Closed:2015-03-27 16:47:20
Priority:MajorRegression?Yes
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:I use Read command to read dtmf like:

{noformat}
Read(digito,input,20,n,3,30)
{noformat}

It's works good in asterisk 1.6.2.7, but it's not work when I update to asterisk 1.8.1-rc1

when I change to {{Read(digito,input,20,i,3,30)}} it's works ok, but I  want't answer the line.

My Exten:
{noformat}
exten =>_X.,1,Ringing()
exten =>_X.,2,Progress()
exten =>_X.,3,Playback(welcome)
exten =>_X.,4,Read(digito,input,20,n,3,30)
{noformat}

and i revice the sip info:

{noformat}
<------------->
--- (12 headers 2 lines) ---

<--- SIP read from UDP:192.168.1.101:5060 --->
INFO sip:511@192.168.1.102 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.101:5060;branch=z9hG4bK1055cc8709f8e9af
From: <sip:135@192.168.1.101>;tag=5d478c2528f28482
To: <sip:511@192.168.1.102>
User-Agent: Asterisk
CSeq: 3 INFO
Call-ID: 6eb1064116403e8852ec1d3c00080e9b@192.168.1.101
Contact: <sip:135@192.168.1.101:5060>
Max-Forwards: 70
Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, INFO, UPDATE, PRACK
Content-Type: application/dtmf-relay
Content-Length: 22

Signal=8
Duration=0
<------------->
--- (12 headers 2 lines) ---

<--- SIP read from UDP:192.168.1.101:5060 --->
INFO sip:511@192.168.1.102 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.101:5060;branch=z9hG4bK2ed64d862aa64792
From: <sip:135@192.168.1.101>;tag=5d478c2528f28482
To: <sip:511@192.168.1.102>
User-Agent: Asterisk
CSeq: 4 INFO
Call-ID: 6eb1064116403e8852ec1d3c00080e9b@192.168.1.101
Contact: <sip:135@192.168.1.102:5060>
Max-Forwards: 70
Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, INFO, UPDATE, PRACK
Content-Type: application/dtmf-relay
Content-Length: 22

Signal=8
Duration=0
<------------->
{noformat}





Comments:By: Matt Jordan (mjordan) 2015-03-27 16:47:05.274-0500

I don't think this is a bug.

In your log snippet, the {{INFO}} request does not contain a to-tag. As such, Asterisk would be unable to match the {{INFO}} request to a dialog, and would simply drop it. This would have worked prior to 1.8 as Asterisk ran with {{pedantic=no}} by default. Setting that back to {{no}} in 1.8 would probably mask the issue.

The {{INFO}} request may not have the to-tag for a variety of reasons:
# Your endpoint may be faulty.
# By indicating Ringing prior to Progress, you may be inhibiting sending of a 183.
# You may have {{progressinband}} enabled.

With the lack of a full DEBUG log on the issue along with a corresponding {{sip.conf}}, it is impossible to say for certain. However, this doesn't look like a bug.