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

[Tim Panton]

Comments in-line.

On 29 Jul 2006, at 01:48, John Todd wrote:

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

I agree that we should formalise the method and not leave it up to  
the dialplan to chop the strings.

When I said we could use url style values in the dial plan, I was  
thinking of having it work like this:

dial(IAX2/mexuar/3?customer="JoeBob")

Asterisk would strip ?customer="JoeBob" from the dial string before  
sending it.
It would then add an (optional) InfoElement to the NEW frame with the  
variable name and value in it

The receiving IAX would either ignore the extra InfoElement, or if it  
supported it, it would
check to see if the variable existed, if not, create it and assign  
the value.
(pre existing asterisks will ignore IEs they don't understand)

>
> 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
>

But what happens if server1 hangs up first ?

>
> 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
>

Tim Panton

www.mexuar.com