[asterisk-dev] IAX2 OSP support - issue 8531

[Tilghman Lesher]

On Thursday 12 April 2007, Tim Panton wrote:
> 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 ??

I suspect that would require a redesign of the protocol.  I very intentionally
stuck IAXVARS in the NEW to ensure that those variables would be available
at call setup time.  There are a great many race conditions if the variables
show somewhat after call setup, which creates its own set of problems.

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

There is no more standardization here than the simple fact that the sender and
receiver must agree on the usage of a particular variable name for the sending
of that variable to have any effect at all on the receiving system.  Those
names and meanings should be left up to the individual Asterisk administrator
(and their providers, if applicable).

Given that OSP is XML and XML takes a lot of space, it would seem troublesome
to force everybody to send an OSP packet every time.  Note that the proposal
in question uses 4 IE elements (totalling 1024 bytes) which gets you close to
the practical limit of 1500 bytes per UDP packet that we all would prefer
not to exceed, for obvious reasons.  I would think it would be more flexible
to allow (via a single line in the dialplan) administrators to send OSP
information via IAXVARS, but only at their own option.

I agree with Russell that the patch under consideration seems unnecessary.

-- 
Tilghman