UA2 not receiving re-INVITE after Asterisk redirect action

Asterisk Asterisk Support
1
When performing the following redirect action from AMI we came across a problem where the re-INVITE was not sent to the receiver. 1.6.1.18 Linux (CentOS)

UA-1’s DN: 20000
UA-2’s DN: 20001

  1. Originate Action from AMI from SIP UA-1 to UA-2

action: originate
channel: SIP/20000
priority: 1
exten: 20001

2.From Asterisk, SIP UA-1 receives initial-INVITE so it returns “180 RING” and “200 OK”

3.From Asterisk, SIP UA-2 receives initial-INVITE so it returns “180 RING” and “200 OK”

  1. Asterisk sends both SIP UA-1 and UA-2 re-INVITE and the RTP route is established as a Peer2Peer between each UAs’ local IP addresses.

  2. Using the following AMI redirect action, we redirect each channel to a MeetMe number (or hold queue)

action: redirect
channel: SIP/20000’s channel
priority: 1
exten: 912
extrachannel: SIP/20001’s channel
extrapriority: 1
extraexten: 912

  1. UA-1 receives re-INVITE but UA-2 does not. Because of this, UA-2’s media stream doesn’t update. In the case of MeetMe, the sound for both UAs is mute. In the case of hold queue, UA-1 can hear the hold queue music and UA-2’s voice but UA-2 can only hear the hold music.
-user.conf

[20000]
type=friend
secret=20000
host=dynamic
nat=no
callerid=Sip<20000>
context=default
disallow=all
allow=ulaw
canreinvite=yes
dtmfmode=rfc2833

-extensions.conf (extract)

; Extension dial plan
exten => _2XXXX,1,Dial(SIP/${EXTEN},60)
exten => _2XXXX,n,Ringing()
exten => _2XXXX,n,GotoIf($["${DIALSTATUS}"=“CHANUNAVAIL”]?102)
exten => _2XXXX,102,Busy(3)
exten => _2XXXX,103,HangUp()

;MeetMe number dial plan
exten => _912,1,MeetMe(${EXTEN},dq)

; Hold queue dial plan
exten => _906XXXX,n,Queue(${EXTEN})

-meetme.conf (extract)
conf => 912

2

1.6.1.x is unsupported. If you can reproduce this on the current 1.6.2.x, you should raise an issue on issues.asterisk.org. You will need to follow the SIP bug reporting rules, i.e. you will need to attach console logs with a reasonable debug and verbosity level, showing sip set debug on output, and you will need to provide the sip show history output for the call.

You also need to clarify what you mean by DN. You appear to use it to mean both directory (extension) number and device name. In asterisk these can be different. SIP/20000 is a device name, 20001 is a directory number.

Note that you are exercising some of the most arcane parts of Asterisk in this example.

1.6.2.x will cease to be supported in about April, for all except security issues.

3

Hi,

Thank you for your reply.

Following your suggestions I tried on 1.6.2.16.1 and we got the same problem. As advised I’ve reworded my explanations to be a little clearer and added the necessary logs (+ Wireshark logs).

I’ve raised a new issue at:

issues.asterisk.org/view.php?id=18721