[Home]

Summary:ASTERISK-12437: [patch] Setting up a HANGUPCAUSETEXT variable for SIP channel
Reporter:Carles Pina i Estany (cpina)Labels:
Date Opened:2008-07-23 13:31:18Date Closed:2009-10-21 18:49:27
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/NewFeature
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) 20081114__bug13140.diff.txt
( 1) 20090721__issue13140.diff.txt
( 2) 20090807__issue13140.diff.txt
( 3) hanguptextcause02.patch
( 4) hanguptextcause04.patch
( 5) hanguptextcause05.patch
( 6) hanguptextcause06.patch
Description:I found that sometimes it's needed to have the exactly "SIP disconnect code" from the other end. HANGUPCAUSE could not be enough as it's mapping different SIP codes to the same number.

After talking about it in -dev mailing list:
http://lists.digium.com/pipermail/asterisk-dev/2008-July/034004.html

Some people was interested and attached there is a initial patch to implement it.

Note: there is a problem with a Dial to multiple channels: same problem than HANGUPCAUSE. A good solution, as talked here:

http://lists.digium.com/pipermail/asterisk-dev/2008-July/034020.html

is to have a hash/function handling all disconnect reasons. In this status the classic HANGUPCAUSE and also HANGUPCAUSETEXT don't handle it.

PATCH:
Mail: http://lists.digium.com/pipermail/asterisk-dev/2008-July/034049.html
Attachment: http://lists.digium.com/pipermail/asterisk-dev/attachments/20080723/6da29aa3/attachment.patch

In my tests the patch has been working fine. If you see any problem or patch should be done in a different way, I'm open to work on it.

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

To test the patch, the dialplan should be like:
exten => 555,1,Set(CALLERID(all)=401113)
exten => 555,2,Dial(SIP/004477@ASTERISK_IP,,tTwWg)
exten => 555,3,Verbose(HANGUPCAUSE: ${HANGUPCAUSE})
exten => 555,4,Verbose(HANGUPCAUSETEXT: ${HANGUPCAUSETEXT})

exten => i,1,Verbose(HANGUPCAUSE2: ${HANGUPCAUSE})
exten => i,2,Verbose(HANGUPCAUSETEXT2: ${HANGUPCAUSETEXT})

In Asterisk 1.6 some disconnect codes makes the dialplan logic to jump to the invalid extension and other ones to the n+1 extension.
Comments:By: Eliel Sardanons (eliel) 2008-07-23 13:43:24

I think it is too much LOG_WARNING for the log output:

ast_log(LOG_WARNING,"Setted up: %s\n",hangupcausetext);

LOG_NOTICE, or LOG_DEBUG are better for this situation.
By: snuffy (snuffy) 2008-07-23 16:28:31

You should never attach code without ticking the box that it is a code/documentation update.

I'm sure you license will be approved within a few days.
By: Carles Pina i Estany (cpina) 2008-07-23 18:54:28

To snuffy: you are right, I read the textbox text too late on first time (that's the reason that I uploaded the file two times, sorry).

To eliel: you are right, actually that ast_log was for my debugging and I should remove this line. When Digium approves the license I will upload a new version without this line or only wigh LOG_DEBUG.

Thank you
By: Tilghman Lesher (tilghman) 2008-07-30 18:22:56

The license has been approved for several days now.  Are you planning to update your patch?
By: Carles Pina i Estany (cpina) 2008-08-02 16:51:57

Hi Caryodon: I plan to change from LOG_WARN to LOG_DEBUG. If I remember correctly, in my tests it worked fine so no need to update (only the same changing LOG_WARN by LOG_DEBUG).
By: Olle Johansson (oej) 2008-08-04 03:33:46

What's the meaning of:
pbx_builtin_setvar_helper(chan,"HANGUPCAUSETEXT","AQUI1");

Also, you need to add documentation in the proper files.
By: Carles Pina i Estany (cpina) 2008-08-04 10:02:22

Hi Oej,

I will udpate the patch removing the AQUI1 (debugging statement) and document the proper files.

Thanks for reviewing
By: Carles Pina i Estany (cpina) 2008-08-06 13:57:14

Hello,

I've uploaded a newer version (the correct one, actually).
If fixes:
a) eliel comment about too much level in a debug statement
b) removes a test (AQUI1) reported by Oej

As always, I'm open to any comments.

Thank you
By: Carles Pina i Estany (cpina) 2008-08-06 15:57:16

Ops, I see that I've missed the documentation that Oej was referring. I will look which documentation I should add and add it on next days.
By: Carles Pina i Estany (cpina) 2008-08-11 15:23:48

I've uploaded a new patch. This one adds a comment in one of the places.

In my opinion, other places are easy to understand and would be over-commenting (following what I have seen in Asterisk code). I can also add if more comments are needed.
By: Eliel Sardanons (eliel) 2008-08-11 15:36:57

You also need to update the CHANGES file explaining this new feature.
By: Carles Pina i Estany (cpina) 2008-08-11 15:50:20

eliel: done!
By: Tilghman Lesher (tilghman) 2008-11-14 14:13:55.000-0600

I've taken the liberty of updating this issue with an initial implementation of reverse inheritance just discussed on the -dev list.  This implementation isn't yet complete, because I'd like to add several more measures to deal with multiple children, as well as avoiding overwriting variables in the parent channel.  However, the actual inheritance should work now, in a way that is more widely useful than just this single use case.
By: Carles Pina i Estany (cpina) 2009-01-28 03:10:14.000-0600

I see that status has changed to assigned to Corydon76 (good news).

I have not been dealing with it for long time (August), but if you need anything (testing, etc.) that can help you feel free to ask.

Thanks,
By: Tilghman Lesher (tilghman) 2009-07-21 14:48:25

Okay, new solution.  This creates a universal accessor method back to the creating channel, through a dialplan function called MASTER_CHANNEL().  This will allow dialplan users in macros to also pass back values to the master channel.
By: Leif Madsen (lmadsen) 2009-08-04 14:08:24

This seems to work as advertised from what I can tell. If I call ${MASTER_CHANNEL(CHANNEL)} from a Macro that was called from a Dial(...,,M(getChan)) for example, it returns the originating channel.
By: Leif Madsen (lmadsen) 2009-08-04 14:28:16

exten => 109,1,Dial(Local/jimmy@testing,12,M(get_orig_channel))

[testing]
exten => jimmy,1,Answer()
exten => jimmy,n,NoOp(${MASTER_CHANNEL(CHANNEL)})
exten => jimmy,n,Dial(SIP/00085D193AB5,6,M(get_orig_channel))
exten => jimmy,n,Hangup()



Output:

-- Executing [109@start:1] Dial("SIP/00085D182ACF-01771a90", "Local/jimmy@testing,12,M(get_orig_channel)") in new stack



   -- Executing [s@macro-get_orig_channel:2] NoOp("Local/jimmy@testing-d88e;1", "Originating channel was SIP/00085D182ACF-01771a90") in new stack



   -- Executing [s@macro-get_orig_channel:2] NoOp("SIP/00085D193AB5-017c8b30", "Originating channel was Local/jimmy@testing-d88e;2") in new stack
By: Tilghman Lesher (tilghman) 2009-08-07 14:30:16

New patch uploaded that should address the Local channel deficiency.
By: Leif Madsen (lmadsen) 2009-08-07 15:25:02

What is the expected output on the test I proposed above? I'm getting the same output as previously on the same test.

Leif!
By: Leif Madsen (lmadsen) 2009-08-07 15:27:36

Oh wait, I was incorrect! I read it wrong. Here is the output now:


-- Executing [109@start:1] Dial("SIP/00085D182ACF-00fdd8f0", "Local/jimmy@testing,12,M(get_orig_channel)") in new stack


-- Executing [s@macro-get_orig_channel:2] NoOp("Local/jimmy@testing-0eb4;1", "Originating channel was Local/jimmy@testing-0eb4;1") in new stack


-- Executing [s@macro-get_orig_channel:2] NoOp("SIP/00085D193AB5-00ff0430", "Originating channel was SIP/00085D193AB5-00ff0430") in new stack
By: Tilghman Lesher (tilghman) 2009-08-10 10:46:41

This has actually exposed a bug in the trunk API, which Russell is working on fixing.
By: Leif Madsen (lmadsen) 2009-08-27 10:13:00

Is there an open issue we can link back to here?
By: Tilghman Lesher (tilghman) 2009-08-27 10:49:18

No, I think that issue is now solved in trunk, so testing may resume.
By: Leif Madsen (lmadsen) 2009-09-01 11:26:35

I now see:

  -- Local/jimmy@testing-2948;1 answered SIP/00085D193AB5-073e4a68
   -- Executing [s@macro-get_orig_channel:1] NoOp("Local/jimmy@testing-2948;1", "Originating channel was SIP/00085D193AB5-073e4a68") in new stack


...

   -- SIP/00085D182ACF-073f21c8 answered Local/jimmy@testing-2948;2
   -- Executing [s@macro-get_orig_channel:1] NoOp("SIP/00085D182ACF-073f21c8", "Originating channel was SIP/00085D193AB5-073e4a68") in new stack
By: Digium Subversion (svnbot) 2009-09-01 18:41:50

Repository: asterisk
Revision: 215301

U   trunk/CHANGES
U   trunk/channels/chan_sip.c
U   trunk/funcs/func_channel.c

------------------------------------------------------------------------
r215301 | tilghman | 2009-09-01 18:41:50 -0500 (Tue, 01 Sep 2009) | 8 lines

Add MASTER_CHANNEL() dialplan function, as well as a useful usage.
(closes issue ASTERISK-12437)
Reported by: cpina
Patches:
      20090807__issue13140.diff.txt uploaded by tilghman (license 14)
Tested by: lmadsen
Change-type: feature

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=215301