[asterisk-dev] IAX2 OSP support - issue 8531
Tim Panton
tim at mexuar.com
Thu Apr 12 03:25:45 MST 2007
On 12 Apr 2007, at 03:48, Russell Bryant wrote:
> I have been looking at the code in issue 8531 a bit today:
>
> http://bugs.digium.com/view.php?id=8531
>
> However, my current feeling is that now that Tilghman's IAX2 remote
> variables patch has been merged, this change isn't necessary at
> all. An OSP token can be handled just like any other variable.
>
> In fact, the way the patch is written, you can use the two methods
> interchangeably and chan_iax2 will treat them the same. The code
> would actually send the OSP token in both the new OSP information
> element, as well as a generic variable element.
>
> The patch introduces a new dialplan function, IAXCHANINFO(), which
> lets you set the OSP token. However, as I read the code, you could
> set it with either IAXCHANINFO() or IAXVAR(), and retrieve it with
> either one on the other side as well.
>
> The last comment in the report indicates that Kevin may have said
> in discussion that he agreed it should be its own information
> element. Kevin, if you still feel this way, what's the reason?
> Can anyone else think of a reason it should be handled differently
> or do you agree that it should already be accounted for?
>
I know it is a bit late to bring this up, but there is a problem with
putting all this
functionality into the 'NEW' message.
Because of the way IAX encryption works, the NEW is never encrypted,
even if the rest of the call is.
I don't know enough about OSP to know if that matters, but it does
seem a shame
that both this and the IAXVARS have to be passed in the clear.
At the IAX Bof there was a discussion about this, but to be honest I
don't think we
came to a firm conclusion. Perhaps one of the guys taking notes can
remember ??
We did however agree that there should be _no_ standardized names or
meaning for
IAXVARS. I'm not sure that this proposal breaks that 'rule' but it
does come close.
Tim
Tim Panton
www.mexuar.net
www.westhawk.co.uk/
More information about the asterisk-dev
mailing list