[asterisk-dev] IAX2 OSP support - issue 8531

[Kevin P. Fleming]

Tilghman Lesher wrote:

> I think, though, that as OSP is properly a CDR mechanism, appropriate
> for post-call billing, placing it within the IAX2 protocol specifically is the
> wrong place for it.  As it is protocol agnostic, we shouldn't make it IAX2
> specific.  Even if we did, I would prefer to see the information encoded
> within OSP compressed in some way.  While SIP is a text protocol and
> additional text is no threat, IAX2 is a binary protocol, meant to be as
> compact as possible.  If we want to encode billing information in IAX2,
> we should adopt this same design and encode that billing information as
> compactly as possible.

OSP is used for more than CDRs, but in this specific case your logic is
pretty close... at least enough for this usage.

The OSP token is already encoded and compressed as I understand it; the
token contains quite a bit of information about the session that was
requested from the OSP server.

Di-Shi, can you comment on whether the OSP token as proposed in IAX2 is
already in as compact a form as it can be?

> My concern is that at some point, we're going to run into a wall of the
> standard IAX2 NEW packet becoming too big, consistently fragmented by
> IP to pass the MTU, with a net effect that with a certain amount of packet 
> loss, IAX2 will become unusable.  As much as possible, I'd like to avoid that
> threat.

Nobody is suggesting that OSP tokens be a part of _every_ NEW request,
so I'm not sure why you consider this to be the 'standard IAX2 NEW
packet'. The whole point of IAX2 using IEs is that they can be optional,
and only users of OSP would ever have to deal with this issue.

Another option, although more radical, would be to add some other sort
of IAX2 full frame that allowed for additional session-related
information to be passed once the NEW has been ACKed... something like
INFO in the SIP world, for example.