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


More information about the asterisk-dev mailing list