[Asterisk-Dev] IAX2 call variable passing between servers

Adam Hart adam at teragen.com.au
Tue Dec 2 20:53:40 MST 2003 

you could send text messages? I'm currently doing that over IAX2 for instant
text messaging and user presence. I think there's a way to send text
messages in the dial plan (if so, tell me)

----- Original Message ----- 
From: "John Todd" <jtodd at loligo.com>
To: <asterisk-dev at lists.digium.com>
Sent: Wednesday, December 03, 2003 2:35 PM
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

More information about the asterisk-dev mailing list