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

[John Todd]

At 1:03 PM -0500 7/28/06, Tilghman Lesher wrote:
>On Friday 28 July 2006 12:12, Douglas Garstang wrote:
>> what's the length limitation on the called number?
>
>In terms of the dialplan, 80.  In terms of the IAX2 protocol, 255.
>
>--
>Tilghman

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.


 - 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.  Secondly, ordering variables inside of such a string is ugly and prone to fragility.  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.   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.

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").

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


Execution on foo:123 on server1 would look like this:

    -- Executing [foo:1] Set("SIP/2203-6696", "outbound.customer=JoeBob") in new stack
    -- Executing [foo:2] NoOp("SIP/2203-6696", "") in new stack
    -- Executing [foo:3] Dial("SIP/2203-6696", "IAX2/server1 at server2/main") in new stack
    -- Executing [foo:4] NoOp("SIP/2203-6696", "99999") in new stack


Execution on server2 would look like this:

    -- Executing [foo:1] NoOp("IAX2/2203-6696", "JoeBob") in new stack
    -- Executing [foo:2] Set("IAX2/2203-6696", "outbound.result=99999") in new stack
    -- Executing [foo:3] Hangup("IAX2/2203-6696", "") in new stack


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?

JT