[Asterisk-Dev] IAX2 call variable passing between servers
John Todd
jtodd at loligo.com
Wed Dec 3 08:29:46 MST 2003
Linus -
If you're up to the task, then I fully encourage you to go forward.
Your method is more robust and has better long-range goals in mind
than my simple variable passing concept. If it can be staged in
small increments that do not seem to have large code modification
implications, as you imply (and William describes) then I think it
would be well accepted.
IAX2 can quickly surpass SIP in core systems if this type of
functionality is implemented. It's already much more robust in
certain areas than SIP; we need to keep building better stuff in. :-)
Do you have the cycles to start and complete a project like this?
I'd be more than happy to help with the development effort, but I am
not a coder and merely a tester/documenter/commenter.
JT
At 12:42 PM +0000 12/3/03, Linus Surguy wrote:
>
>Quite right, I am thinking of doing something slightly broader that your
>original idea, however all I'm looking for is being able to transmit
>variables over IAX - the rest can come later, the important trick is to lay
>the groundwork now.
>
>All I would do now is:
>
>As William mentioned, I would suggest that a new structure is added to
>'ast_channel', which contains a linked list of variables.
>
>chan_iax2 is enhanced to transmit/receive this structure when a call is
>made.
>
>Two new applications are created to 'Set' these new variables, and 'Read'
>these new variables.
>
>End.
>
>Seperate work which *could* come later:
>
>a) Adding the ability to send/receive this to chan_sip as well
>b) Adding to chan_zap the ability for it to send/receive Q931 flags/data
>through this new variable set
>c) As above for H.323
>
>These don't have to be done now, or even at all - but it gives us the
>ability for this potentially to occur, which I don't think could happen with
>your simpler suggestion.
>
>I will open a feature request, although its more likely we'll end up doing
>the work for ourselves and submit it if others are interested.
>
>Linus
>
>----- Original Message -----
>From: "John Todd" <jtodd at loligo.com>
>To: <asterisk-dev at lists.digium.com>
>Sent: Wednesday, December 03, 2003 3:35 AM
>Subject: Re: [Asterisk-Dev] IAX2 call variable passing between servers
>
>
>> Linus -
>> Your method seems to have much broader scope than my somewhat
>> smaller request. My comments were specifically referring to adding
>> user-defined flags in between two different systems (using SIP, IAX2,
>> and PRI) for use within dialplans. Your comments seem to be much
>> more general configuration option requests on each channel type,
>> which is significantly more work, and completely encompasses my
>> request.
>>
>> I like the idea of using a special application to set channel
>> specific variables, but again, this would be useful only in the
>> context of the much larger patches you promote below.
>>
>> I imagine that these types of overly sweeping changes will not
>> happen in the near or mid-term, as it would require significant
>> re-working of every channel type. Even if you did come up with the
>> patches, the chances that Mark would implement them are slim, as
>> evidenced by many of the much simpler patches/features which languish
>> in the bugtracker due to the limits of time and brainpower.
>>
>> I'd prefer to see the simple additions done first, so that those of
>> us in larger installations can meaningfully move variables around
>> without having to resort to some out-of-band database (does this
>> smell like an SS7 network, anyone?) to get the desired effect, or
>> using the (aiee!) "language" flag to create a horrific hack to pass
>> packed variables around. At the very least, IAX2 seems like a likely
> > candidate for this extension of variable transmission/reception.
> >
> > Your final comments about a clearing cause does seem an obvious
> > win, and yes, that would be a near-term objective I think for IAX2.
>> Care to open a feature request on it?
>>
>> JT
>>
>>
>>
>> >Hi John,
>> >
>> >I am very interested in the idea of passing extra data with IAX2 as I see
> > >that is one of the most major areas that it is lacking.
>> >
>> >My particular interest is in passing call related information at two
>times,
>> >a) call establishment and b) call end.
>> >
>> >The first fits in with what you have proposed here, and I agree that you
>> >don't want to be sending or receiving all of the tasks 'environment'
>> >variables. I also agree in principle with the thoughts behind the
>> >inbound.variable, outbound.variable system, although I would tend to
>suggest
>> >not directly linking the variables in the same 'name' space, instead you
>> >might have:
>> >
>> >SetCallVar(Q931BEARER=039090)
>> >SetCallVar(Q931NOA=INTERNATIONAL)
>> >
>> >and
>> >
>> >ReadCallVar(Q931BEARER,BEARER)
>> >ClearCallVar(Q931NOA)
>> >blah blah ${BEARER}
>> >
>> >Any variables that are set and contained in the 'callvar' name space will
>be
>> >automatically passed on any outbound Dial call unless specifically
>cleared -
>> >or maybe blocked with a Dial option.
>> >
>> >These variables may be set by the application *but could also be set* by
>the
>> >channel code itself, for example chan_zap.c/q931.c might set Q931BEARER,
>and
>> >more importantly might *read* it and set it in the Q931 call setup
>packet.
>> >
>> >With this mechanism in IAX2 and appropriate support in Zap/pri/q931 IAX2
>> >then becomes a very real transport for telco applications where we need
>to
>> >transit call flags.
>> >
>> >Secondly, an additional variable that I would like to see passed would be
>> >sent and read *in reverse* when a call clears. At the moment, a very real
>> >restriction on IAX2 is that calls either connect and then clear or fail
>to
>> >connect and clear. There is no way to tell *why* the call cleared. I'd
>like
>> >to be able to pass, whether as a variable or otherwise a 'CLEARCAUSE'
>> >variable whoes values could reflect a far wider range of values ( at the
>> >very least Busy, Congested, Number Unobtainable, Call Failed, Call
>Rejected,
>> >Out Of Order, Incompatible Equipment)
>> >
>> >What do you think?
>> >
>> >Linus
>> >Magrathea
>> >
>> >----- Original Message -----
>> >From: "John Todd" <jtodd at loligo.com>
>> >To: <asterisk-dev at lists.digium.com>
>> >Sent: Tuesday, December 02, 2003 3:42 PM
>> >Subject: [Asterisk-Dev] IAX2 call variable passing between servers
>> >
>> >
>> >>
>> >> Here's an idea for you all to shoot down. I'll await the nonexistant
>> >> comments before I open a feature request.
>> > >
>> >> We have the luxury of moving calls around with IAX2, where we (the
>> >> Asterisk community) have control of the protocol. Various hacks are
>> >> being installed into SIP headers to move data around, as I'm
>> >> experiencing with some of the installations I've now seen. With
>> >> IAX2, it seems apparent that we should be able to move variables
>> >> around semi-transparently, since IAX2 integrates with Asterisk
>> >> completely.
>> >>
>> >> Sending all variables might be difficult/insecure/silly, as we don't
>> > > want to clutter the call setup with a slew of variables, some of
>> > > which may be inherently "secure" and should not leave the server on
>> > > which they were generated. Perhaps some naming convention could be
>> >> used to differentiate variables that would be passed to the remote
>> >> end as "special case" variables.
>> >>
>> >> There are two possible methods that could be used to determine if
>> >> certain variables might get passed. The first method is the
>> >> simplest, which is to simply search all the named variables and see
>> >> if any of them begin with "resend." and then transmit those
>> >> automatically. Alternately (and perhaps, in addition to this method)
>> >> one could add yet another modifier to the Dial command, such as "v"
>> >> which stands for "send [v]ariables".
>> >>
>> >> I propose a format like this for outbound: outbound.VARNAME
>> >> I propose a format like this for inbound: inbound.VARNAME
>> >>
>> >> I think that it would be wise to "sandbox" the variables with a
>> >> distinguishing feature (name prefix) so that we do not inadvertently
>> >> move variables out of or into local/remote dialplan executions. The
>> >> extra two steps is a small enough effort. (really, one step at each
> > >> end is needed to be "clean", but we could skip the re-translation at
>> >> the far end and just use ${inbound.VARNAME} if we were lazy.)
>> >>
>> >>
>> >> As an example:
>> >> exten => 123,1,SetVar(GREETING=hello there)
>> >> exten => 123,2,SetVar(NAME=John Doe)
>> >> exten => 123,3,SetVar(outbound.GREETING=${GREETING})
>> >> exten => 123,4,SetVar(outbound.NUMBER=${EXTEN})
>> >> exten => 123,5,Dial(IAX2/remote1 at hub1/${EXTEN},,v)
>> >>
>> >> Upon receiving the call, the other host (hub1) would then have to
>> >> translate back like this:
>> >>
>> >> [from-remote1]
>> >> exten => _X.,1,SetVar(OURGREETING=${inbound.GREETING})
>> >> exten => _X.,2,SetVar(DIALEDNUMBER=${inbound.NUMBER})
>> >> exten => _X.,3,blah blah blah
>> >>
>> >>
>> >>
>> >> SIP:
>> >> As far as having this work across channels other than IAX2: SIP can
>> >> handle almost any number of additional headers. It could be possible
>> >> to incorporate a "custom" header if there are any variables that fall
>> >> into the 'resend.' group. Of course, fully escaped syntax would need
>> >> to be followed. As an example, a custom header could be
>> >> generated/parsed:
>> >>
>> >> Asterisk-Variables: FOO="hello there";NUMBER="123"
>> >>
>> >> PRI:
>> >> There are special areas in the PRI outbound call which could contain
>> >> a limited number of variables passed along. See:
>> >>
>http://www.mail-archive.com/asterisk-dev@lists.digium.com/msg01246.html
>> >>
>> >> MGCP:
>> >> No idea.
>> >>
>> >> SKINNY:
>> >> No idea.
>> >>
>> >> H323:
>> >> No idea.
>> >>
>> >> Local:
>> >> Multiple methods: db[put/get] or native bridge variable transfers.
>> >>
>> >>
>> >> JT
>> >> _______________________________________________
>> >> Asterisk-Dev mailing list
>> >> Asterisk-Dev at lists.digium.com
>> >> http://lists.digium.com/mailman/listinfo/asterisk-dev
>> >>
>> >
>> >_______________________________________________
>> >Asterisk-Dev mailing list
>> >Asterisk-Dev at lists.digium.com
>> >http://lists.digium.com/mailman/listinfo/asterisk-dev
>>
>> _______________________________________________
>> Asterisk-Dev mailing list
>> Asterisk-Dev at lists.digium.com
>> http://lists.digium.com/mailman/listinfo/asterisk-dev
>>
>
>_______________________________________________
>Asterisk-Dev mailing list
>Asterisk-Dev at lists.digium.com
>http://lists.digium.com/mailman/listinfo/asterisk-dev
More information about the asterisk-dev
mailing list