[Asterisk-Dev] IAX2 call variable passing between servers

Linus Surguy linus at magrathea-telecom.co.uk
Tue Dec 2 14:28:03 MST 2003


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
>




More information about the asterisk-dev mailing list