[asterisk-dev] 'IAX2 call variable passing between servers '

[Tilghman Lesher]

On Friday 28 July 2006 19:48, John Todd wrote:
> This message is a summary of some of the comments made in this
> thread; apologies for not including all forwards - it was a bit
> messy.
>
>  - I don't know if there was any particular "use" for the SIP
> header read/write routines; saying that inclusion of variables in
> there wasn't part of it's intention might be an overstatement of
> intent.  I think they can be used for whatever the administrator
> wants; variable transfer from server to server seems like a totally
> reasonable and SIP-consistent method.

The major reason for having these is the ability to send custom
headers to particular devices to cause particular behavior, such as
to force a SIP phone to go into auto-answer mode or to ring a
particular ring.  While I agree that they could be used to send
variables to a remote server, that was not their original intended
use.

>  - I would disagree that using IAX2 to transport variables in a
> "static" fashion is equivalent to putting the variables into the
> dialed number sequence.  Firstly, you've hit upon an obvious limit
> in having only 255 characters, which is a serious problem to any
> robust transfer of values across the channel.

There is always a limit; for the protocol, it is 255, but even with
80, you have more than enough room to pass reasonable indications to
a remote IAX2 server that you control.  Remember, passing variables
is useful only when you can control their interpretation on the remote
end.  Even if you encode variables within the protocol itself, you
should be mindful of the fact that MTU limits mean that a SETUP
message exceeding that limit could cause your call delivery more than
the usual delay.

> Secondly, ordering 
> variables inside of such a string is ugly and prone to fragility. 

Ugliness is a subjective judgement and requires no response.  In terms
of fragility, variable passing is just as fragile, given that the
remote server may or may not understand (or could even misinterpret!)
the variables you're passing, if that server is not within your
control.

> Thirdly, it would require that the remote server is ALWAYS one that
> can handle such garbled string dial requests, since an unsuspecting
> server would surely fail on a dial pattern of such massive length. 

An unsuspecting server would also fail to process any variables sent
or could misinterpret them and do something unexpected and unintended.

>  Lastly, it is overly onerous to the dialplan administrator who has
> to write a fairly obtuse section of string-chopping code to make
> things work.  It seems that this could fairly elegantly be "hidden"
> in the internals of Asterisk to let the administrator simply use
> the values instead of parsing them as well.

I think that string chopping is much more obvious and easy to
understand for the casual administrator who might be surprised to see
variables suddenly appear in the dialplan for which there were no
originating assignments.  Again, debugging is easier when you can see
all the values in front of you on the server you're working on.

> There are often concessions within Asterisk that make life easier
> for the administrator, and putting  variables inside of IAX2 does
> not seem to only have those benefits but many others as well.
>
> While I agree that setting of variables on the initiation of calls
> (and not dynamically changing them as the call progresses) is of
> limited use, I would say that it is of enough use that it merits
> attention from any enterprising programmer who wishes to fill an
> uneventful Saturday afternoon (and Sunday, and Monday...) with good
> coding.  Once the ability exists in a start-of-call fashion,
> perhaps demand and interest will push others to solve the problems
> surrounding dynamic variable transmission.  "Do not let perfection
> be the enemy of 'good enough'."
>
>
>  - The suggestion that variables can be set on conclusion of the
> call is a good idea, and I had not thought of it.  It does not seem
> to be much more complex than the setting of start-of-call
> variables, as long as they are transmitted back to the originating
> server only on disconnection or redirection of the signalling
> stream (note I didn't say "media stream").

The AOC messages that someone else is implementing is similar to this,
and they're going through all the problems that passing arbitrary
variables entails.

> Skeletal example (IAX configs omitted for brevity):
>
> server1:
> [foo]
> exten => 123,1,Set(outbound.customer="JoeBob")
> exten => 123,n,NoOp(${inbound.result})
> exten => 123,n,Dial(IAX2/server1 at server2/main)
> exten => 123,n,NoOp(${inbound.result})
> exten => 123,n,Hangup
>
> server2:
> [bar]
> exten => main,1,NoOp(${inbound.customer})
> exten => main,n,Set(outbound.result=99999)
> exten => main,n,Hangup

While I disagree with the premise, your syntax is begging for
dialplan functions.

> Finally, I think there is interest in such a patch, but my
> hand-waving or anyone else's complaints about it won't produce
> code.  Everyone on the list might think it's a good idea, but only
> the person that is willing to code it will be the one to submit the
> patch.  I'll put up $50 to seeing this patch idea or something
> close enough to it written in such a way that would permit (and
> results in) it's inclusion into TRUNK - anyone else want to put
> their money where their mouth is, or their code where their mouth
> is, or something to that effect?

Coding to spec would in no way guarantee its inclusion in trunk, but
it's an interesting enough idea that I'd code it simply to end this
thread.

-- 
Tilghman