Russell Bryant has posted a recap on Call Setup Negotiation:

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.

Comments (Click to post)

Name:
Subject:
Website:
Message: