[Asterisk-Dev] Transfer of variables to remote servers (new subject)

[John Todd]

At 10:14 PM +0200 on 4/20/04, Olle E. Johansson wrote:
>John Todd wrote:
>>more significant and vexing problem of transferring values OUT of a 
>>particular server to a remote server.
>>
>>I am uncertain how this should be created, actually.  How do you 
>>hand things off in SIP?  How about IAX2?  MGCP?  Zap?(1) How do you 
>>read them from the other side?  How do you refuse them?(2)  Can you 
>>get a list of the attached values at the other end?(3)
>
>I would suggest we concentrate on Asterisk to asterisk for this functionality.
>Which suggest IAX2.
>There need to be a "trust" concept - do we trust data from this 
>server, or not?
>
>>This would be _TREMENDOUSLY_ powerful if it could be well designed 
>>and had even basic functionality in SIP and IAX2.  Think of this 
>>very small variable name example: "__caller-is-ceo"
>For SIP, I can't recall an existing protocol extension. There's a lot of
>work going on in the 3G space so maybe there's functionality for this
>to be found there - metadata on a call to be handled only between one
>provider's trusted servers.
>
>
>/O


I don't see a need for "trust" in IAX2 or any other channel types, 
actually.  That can be regulated by sending the calls from certain 
"trusted" providers to different contexts, which have different 
values of "trust" for incoming variables.  This is already gated on 
username/password/IP address in the [channel].conf file, right?

Also, based on the contents of some "known" variables, we could do 
some GotoIf booleans to move to more-or-less trusted sub-contexts or 
extensions.  This is a kludge, if we're using it for "trust", but it 
will undoubtedly be done depending on the style of the administrator. 
This is essentially putting layers of "passwords" into call 
transfers, which implies that we have end-to-end encryption (cough, 
cough.)  However, I am firmly of the belief that variable passing 
should not be directly coupled to end-to-end crypto, so don't let 
that hold things up...  We already have a method to negotiate trust 
between endpoints, and that method supports multiple levels of 
security already.

JT