[asterisk-dev] AstriDevCon Recap - Call Setup Negotiation

[Russell Bryant]

Greetings,

One discussion we had at the developer conference was how to improve 
call setup negotiation.  I don't think we really came up with much of a 
plan here, but I'll try to put the notes I have into a readable form so 
that they are preserved in the archives and the discussion can continue.

* Short Term Plans

1) Code review needs to be done on the videocaps branch to determine 
whether this code can be merged into the trunk to improve the way video 
is currently handled in trunk.

* Long Term Plans

We spent a lot more of the time talking about what we'd like to do in 
this area in the long term.

1) Requirements

1.a) We need to be able to handle more codecs.  Our current bitfield 
method is near full and must be redesigned.

1.b) We need to be able to describe formats with more than just the 
format itself.  Many codecs, especially video, have various parameters 
associated with them that must be preserved.

1.c) Asterisk needs to have a way to change codecs in the middle of a 
call.  There are many cases where this can be useful to make calls more 
efficient.  In fact, every time a channel goes to a new application in 
the dialplan, it may be necessary to renegotiate formats.

1.d) Asterisk currently can only handle one audio stream and one video 
stream.  We need to be able to handle multiple streams.

1.e) In the design of a new way to handle formats, we should consider 
the information used in the offer/answer SDP model described in RFC 3264 
as a guide for how we handle things internally.

1.f) Our new format model should handle some data formats (such as with 
faxing) in addition to text, audio, and video.

1.g) Video format negotiation needs to be improved.

1.h) We should make sure we refuse unknown types of media streams.  We 
should certainly refuse transports that we don't know about.  Also, for 
now we should refuse codecs that we don't know about.  However, in the 
future, we should probably allow passthrough for codecs that we don't 
know about.

1.i) Currently, Asterisk can not handle a call without audio.  We should 
be able to handle a call that has video only, for example.

1.j) Transport parameters need to be included in the description of a 
format.  For example, IPv4 or v6.

2) Other notes ...

2.a) When playing back files, if we have a file in a format that was 
listed as supported, even if it is not the one currently being used, it 
should be sent anyway to avoid transcoding.  We can already change 
formats in the middle of a call for both SIP and IAX2 to a format that 
was agreed upon as supported in the initial call setup.

2.b) Video negotiation should be done down to one format, by 
recommendation by phone manufacturers.

2.c) If we offer G.729 for a call, even if it is not the preferred 
format, a license needs to be reserved, because the other side could 
start sending it at any time.

2.d) Someone suggested that configuring new codecs in a configuration 
file may be a useful way to add support for passthrough of new codec 
types without changing the code.  Everyone seemed to agree this was a 
good idea.

2.e) Briding calls between IPv4 and IPv6 was brought up.  This needs to 
be added to the decision tree for whether we should allow re-INVITEs or 
not.  Also, the SDP for a call may include offers for both IPv4 and 
IPv6.  This needs to be remembered for renegotiation purposes.

3) Where to begin?

The first step to improving all of this is to come up with a much more 
rich way to describe media formats in Asterisk.  Then, all of these 
other things will be implemented using this information.

4) IAX2 specific notes

4.a) Once we have a better way to describe formats in Asterisk, we 
should create a FORMAT information element that contains all of this 
information.  A series of these elements should be included in the NEW 
to indicate which formats are supported and preferred for a call.

4.b) We need a new frame type (called RENEW, or maybe something else) 
that can be sent in the middle of a call to initiate the renegotiation 
of formats.  The response to this should be an ACCEPT.  This frame 
should include a new list of FORMAT information elements.

4.c) We should probably have the FORMAT information elements dynamically 
mapped to a bit field.  That way, when we want to switch formats in the 
middle of a call to one of the formats already agreed upon, it can do so 
using the same means that it does today, by sending a voice full frame 
with a bit set to indicate which format is currently being sent.

-- 
Russell Bryant
Software Engineer
Digium, Inc.