'g' argument in combination with 'e' causes Dial() to return to 'h' extension in a different context

Bug #1130467 reported by James Troup
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
asterisk (Ubuntu)
New
Medium
Unassigned

Bug Description

If the 'g' argument is passed to Dial(), the functionality provided by
the 'e' argument changes subtly (and, for us at least, breaks). If
'g' is passed to Dial(), when control is returned to the 'h'
extension, it returns in a different context, e.g.:

[Feb 19 19:01:46] VERBOSE[5956] pbx.c: -- Executing [s@macro-queueexten:4] Dial("Local/1004@agents-46b9;2", "SIP/8930,50,rtge") in new stack
[Feb 19 19:01:53] VERBOSE[5956] pbx.c: -- Executing [h@macro-queueexten:1] NoOp("SIP/8930-0005cea7", "") in new stack

This new context, naturally, has none of the variables of the original
context which breaks what we're trying to do in the 'h' extension.

If I remove the 'g' argument, 'h' is invoked in the original context
as expected.

We're running asterisk 1:1.8.10.1~dfsg-1ubuntu1 on Ubuntu 12.04.2.

This appears to be a regression from Asterisk 1.4, FWIW.

Changed in asterisk (Ubuntu):
status: New → Confirmed
importance: Undecided → Medium
Revision history for this message
Paul Belanger (pabelanger) wrote :

We'll need to see a complete debug log[1] and copy of your extensions.conf file.

[1] https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information

Changed in asterisk (Ubuntu):
status: Confirmed → Incomplete
Revision history for this message
James Troup (elmo) wrote :

Yeah, that's not going to happen. The debug log contains private and sensitive information.

If a standalone test case is a hard requirement, I can probably work something up, but it seems like an unnecessarily high bar to set for a bug report which gives pretty explicit symptoms and log info that demonstrates what I'm saying.

Changed in asterisk (Ubuntu):
status: Incomplete → New
Revision history for this message
Paul Belanger (pabelanger) wrote :

The issue will like need to be punted upstream to the asterisk issue tracker, and this is the first thing they are going to ask you.; reproduce the problem with a debug log.

Revision history for this message
James Troup (elmo) wrote :

*sigh*, fine. Here is an example config, steps with which to
reproduce and messages output with debug turned all the way up.

| apt-get install asterisk sip-tester
|
| From the example-config.tar.gz copy into /etc/asterisk/:
|
| * asterisk.conf - set verbose and debug to 10
| * extensions.conf - dummy extensions to demonstrate problem
| * logger.conf - enable logging of debug and verbose messages
| * modules.conf - don't load AEL or Lua extensions (not strictly necessary)
| * sip.conf - two dummy users, one for sipp and for a SIP UA
|
| # /etc/init.d/asterisk stop
| # rm /var/log/asterisk/messages
| # /etc/init.d/asterisk start
|
| Configure SIP UA (e.g. empathy) to register to local asterisk server.
|
| $ sipp -i 127.0.0.1 -d 1000000 -s 5550 -m 1 -sn uac -timeout 30 127.0.0.1
|
| Answer the call in SIP UA and hang up.
|
| Notice in asterisk console output:
|
| -- Executing [h@macro-test-e-only:1] NoOp("SIP/sipp-00000000", ""I'm in h@macro-test and TESTVAR is foo"") in new stack
|
| $ sipp -i 127.0.0.1 -d 1000000 -s 5555 -m 1 -sn uac -timeout 30 127.0.0.1
|
| Answer the call in SIP UA and hang up.
|
| Notice TESTVAR is not saved in console output and the 'h' extension
| is not correctly executed in the original context as described in
| the original bug report.

Revision history for this message
James Troup (elmo) wrote :
Revision history for this message
James Troup (elmo) wrote :
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.