[Home]

Summary:ASTERISK-09413: BRIDGEPEER does not properly represent peer
Reporter:Dmitry Andrianov (dimas)Labels:
Date Opened:2007-05-09 20:01:38Date Closed:2007-06-19 11:25:29
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_local
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:When a call is made using Dial(Local/1001) which actually goes to SIP/1001 and in the established call feature from [applicationmap] is activated, it sees BRIDREPEER equal to "Local/1001" not "SIP/1001" which makes ChannelRedirect and such unuseable.

****** ADDITIONAL INFORMATION ******

feature.conf:

[applicationmap]
btfeat => *9,self/both,Macro,bridgetest

extensions.ael:

macro bridgetest() {
   ChannelRedirect(${BRIDGEPEER},btcontext,1,1);
};

context btcontext {
   1 => {
       Answer;
       Morsecode(SOS);
       Hangup;
   };
};

and then finally test extensions:

   130 => {
       Set(DYNAMIC_FEATURES=btfeat);
       Dial(SIP/1011);
   };

   131 => {
        Set(DYNAMIC_FEATURES=btfeat);
        Dial(Local/1011);
   };

1. I dial 130, ext 1011 answers, then I press *9 and 1011 hears SOS Morse code. Everything is fine.
2. Now I dial 131, ext 1011 answers, I press *9 and see:

-- Executing [s@macro-bridgetest:1] ChannelRedirect("SIP/1002-09412e38", "Local/1011@default-b618,1|btcontext|1|1") in new stack
[May 8 19:06:19] WARNING[19815]: app_channelredirect.c:82 asyncgoto_exec: No such channel: Local/1011@default-b618,1
Comments:By: Olle Johansson (oej) 2007-05-10 01:33:46

The local channel is the bridged peer at that moment. However, at a later stage, chan_local performs a masquerade and the bridged channel changes. It should propably change BRIDGEPEER then. This is not a SIP bug however, it's a bug in the local channel.
By: Joshua C. Colp (jcolp) 2007-06-19 11:25:28

Fixed in 1.2 as of revision 69986, 1.4 as of revision 69987, and trunk as of revision 69988.