[Asterisk-bugs] [Asterisk 0010206]: [feature] [patch] Add ability to execute 'h' on the called peer in addition to the calling channel
noreply at bugs.digium.com
noreply at bugs.digium.com
Thu Jul 19 16:35:10 CDT 2007
A NOTE has been added to this issue.
======================================================================
http://bugs.digium.com/view.php?id=10206
======================================================================
Reported By: blitzrage
Assigned To: murf
======================================================================
Project: Asterisk
Issue ID: 10206
Category: PBX/NewFeature
Reproducibility: always
Severity: feature
Priority: normal
Status: closed
Asterisk Version: 1.4.7.1
SVN Branch (only for SVN checkouts, not tarball releases): N/A
SVN Revision (number only!):
Disclaimer on File?: N/A
Request Review:
Resolution: fixed
Fixed in Version:
======================================================================
Date Submitted: 07-16-2007 09:22 CDT
Last Modified: 07-19-2007 16:35 CDT
======================================================================
Summary: [feature] [patch] Add ability to execute 'h' on the
called peer in addition to the calling channel
Description:
I have been using a Local channel which then does a Dial() to a SIP channel
in order to have 2 separate 'h' extensions execute at the end of the call.
While talking about how to get around this in #asterisk-doc, Murf said that
was a cool idea, and that he'd like to add an option to Dial() that would
allow this (just like when we execute a GoSub() or Macro() for the called
channel).
He said he'd supply a patch, so this isn't just an open ended feature
request, which I know you all hate :D
======================================================================
----------------------------------------------------------------------
murf - 07-19-07 16:35
----------------------------------------------------------------------
Hit a snag with the user community. Luigi doesn't like this approach to
allowing Dial more flags.
Also, I am adding a note here that 75585 involved making the %lld's edible
to 64-bit machines, and is a part of this bug.
So, I tried Luigi's suggestion of moving two flag values, but wrote a long
letter explaining why I didn't like that option. Then I tried coding up an
alternative, where 64 bit flags are used only in Dial, but... that was
really, really, quite messy. Nearly every test/set_flag call had to be
changed.
You can refer to the flag64hack file for diffs.
Of the several suggestions I got for reforming Dial to allow more options,
the only one I liked was to create a new dial, Dial2(), and have it take
two args (or more) for flags, instead of just one; Caller options, and
Callee options. Well, this was more palatable. Not wildly different, not
that hard to do. I went thru the options to Dial, and was able to pretty
cleanly split the options somewhat down the middle. 13 caller opts; 13
callee opts (incl. privacy opts), and 4 general opts that apply to both
sides, that can be grouped with the caller opts.
But, now, sitting back after the analysis, and beginning to think of the
coding involved, I conclude that I'll have to pass caller_opts and
callee_opts where-ever I passed opts before; that some careful study of the
peer flags will need to be done, to insure that I don't have some caller
opts mixed into the callee opts. This will then involve sorting thru all of
dial2(), and changing just about every ast_test_flag, and ast_set_flag
call, to adjust the name of the field from which to draw the flags. Not
only that, We'll be left with two dial commands, and will we have to
obsolesce one, and force everybody to change their dialplans later? Ugh,
ugh, ugh, ugh, UGH! No. I'm not going to go that route.
Suddenly, the work I've already done for 64 bit flags in dial, seems very
practical! I'm going to go with it!
Issue History
Date Modified Username Field Change
======================================================================
07-19-07 16:35 murf Note Added: 0067610
======================================================================
More information about the asterisk-bugs
mailing list