[asterisk-bugs] [JIRA] Created: (ASTERISK-20342) The DIAL application does not cause asterisk to start reading packets if we have sent a "Session Progress" and the other end has sent a Re-INVITE.

[Matt Jordan (JIRA)]

The DIAL application does not cause asterisk to start reading packets if we have sent a "Session Progress" and the other end has sent a Re-INVITE.
--------------------------------------------------------------------------------------------------------------------------------------------------

                 Key: ASTERISK-20342
                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-20342
             Project: Asterisk
          Issue Type: Bug
      Security Level: None
          Components: Channels/chan_sip/Interoperability
    Affects Versions: 10.6.1, 10.7.0
         Environment: Mac OS X 10.4.11 PowerPC
            Reporter: John Covert
            Assignee: John Covert


If the SIP channel has sent a "Session Progress" and the other end has sent a Re-INVITE, when the call is answered in the Dial application, one-way transmission results.

Given the following dialplan:

[inbound]
exten => _X!,1,Dial(SIP/x28,120,m(5xbring))

or

exten => _X!,1,Progress
exten => _X!,n,Playback(pls-wait,noanswer)
exten => _X!,n,Dial(SIP/x28)

All works fine as long as the calling SIP endpoint does not issue a Re-INVITE.

However, if the calling system (also Asterisk 10.7.0) issues a Re-INVITE, the calling party can hear the called party, but the called party cannot hear the caller.

A SIP trace (attached) shows that the SIP dialogue is correct.

The tcpdump output shows that the calling party's packets are arriving at the interface.

An RTP trace shows that Asterisk is not reading the incoming packets.

A unacceptable workaround is to "Answer" the call before issuing the Dial command; this, of course, is bad because it provides a false answer condition on the trunk.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira