[Home]

Summary:ASTERISK-09065: h extension not executed on sip call ending
Reporter:Miguel Paolino (punkgode)Labels:
Date Opened:2007-03-21 08:49:49Date Closed:2007-03-23 11:31:28
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) messages-hangup-asterisk-1.4.log
( 1) messages-hangup-asterisk-1.4-wsipdebug.log
Description:When an outbound call from a sip peer is routed to pstn through a SPA-3102 (sip fxo gateway) and any call-leg ends the call the h extension is not executed. This is present in 1.4.1 and 1.2.13 (both tested). Also present with calls routed through an E1 (using Digium card) instead of a Linksys FXO (I don't have logs of that scenario yet).

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

---------------------- Test  Involved peers ----------------------
SIP/703       - peer doing the requesting the call,
               belongs to tecnologia context when registered
SIP/spaprueba - gateway, belongs to pstn context when registered

--------------- (Almost)Minimun AEL dialplan:---------------------

globals {
       DTO=40;                  // Dial TimeOut
};

context default {
       h => NoOp(H extension default context);
};

context pstn {
       _x. => {
                       BackGround(tt-monkeys);
              };
       h => NoOp(H extension pstn context);
};

context tecnologia {
       includes {
               local;
       };
       h => NoOp(H extension tecnologia context);
};

context local {
       _9xxxxxxx => &Discar(SIP/spaprueba/${EXTEN:1});
       h => NoOp(H extension local context);
};

macro Discar(NRADISCAR){
       Dial(${NRADISCAR}|${DTO}|);
};



-------------------- Asterisk log setup --------------------------------
logger.conf with:
messages => notice,warning,error,debug,verbose

Asterisk started as: $ asterisk -vvvvddddc
On CLI: sip set debug
Comments:By: Miguel Paolino (punkgode) 2007-03-21 09:10:05

Attached log with sip debug
By: Serge Vecher (serge-v) 2007-03-21 09:26:07

what happens if you place h extension inside the macro?
By: Miguel Paolino (punkgode) 2007-03-22 08:53:18

I can't define extensions inside macros, but I do can define catch statements. To my surprise it did worked. Is this behaviour correct? I mean, should extensions be defined only in contexts? Let's say for example I have a context that executes multiple macros, I need to define the same a catch block on every macro. In my opinion it would be much more nice and robust if the dialplan execution path jumped back to the context where the macro was invoqued (default in case of no h catch statements defined), actually, I thought that was the default behavior.
By: Serge Vecher (serge-v) 2007-03-22 08:55:49

murf: I'm not sure if this is documented very well, so perhaps you can help out here ... Thanks.
By: Steve Murphy (murf) 2007-03-22 10:09:00

Well, macros really are contexts, and AEL just uses catch to define extensions other than "s". You have to catch hangup/invalid/etc events in the context you are in when they occur. Thus, your having to use the catch.

I'll update the macro app docs to make it more clear that 'h' extensions (and others) have to be defined if it's possible that a hangup could occur while the macro is running.
By: Miguel Paolino (punkgode) 2007-03-23 10:22:13

murf, I see what you say, and it solved my problem. The thing is that you are calling macros something that isn't really a 'macro'. Is not like you call a macro and it get's "substituted" with something defined elsewhere, it's a jump to other context. So macros are just context which accept parameters, and you can't really do an efficiente programming that way, you need to redifine extensions everywhere just to handle the same situation (for example, a hangup).
I believe is more than just update the docs, someone need to review this dialplan behavior.
Thank's for the solution and your time :).


By: Steve Murphy (murf) 2007-03-23 11:27:08

This involves a bit more than you might at first suspect. First of all, I think you are really after some sort of signal handling facility like C++ or java has, in that at some level, you can "catch" these signals hierarchically. The extension engine just isn't that featured.

Also, you can always take the bulk of the code in the "h" extension, and put it in a macro. And call that macro. There are some complexities in this, in that macros can only be called safely 7 levels deep. There is a mechanism to keep from going any further-- because you crash asterisk if you go more than that. That's one of the main reasons we are switching to Gosubs with arguments in trunk-- 7 is just not deep enough for safety.

I've also got some complaints about CDR's getting messed up when you call a macro from the 'h' extension, etc. etc.

You also might get some code reuse from using #include  -- but that's got its own set of drawbacks, too.
By: Steve Murphy (murf) 2007-03-23 11:31:28

OK, I've added a short section to the Macro apps documentation (you know,
the output of the "core show application Macro" CLI command), which explains
a little bit more about the use of extensions in macros.

It's commited into 1.2 via 59186 and 59187 (dumb mistake fixed), 1.4 via 59188, and trunk via 59160.