[asterisk-dev] Wish: adding intelligent codec negotiation to asterisk / pjsip

[Joshua Colp]

On Tue, Jan 31, 2017, at 12:01 PM, Michael Maier wrote:

<snip>

> > 
> > There's no current generic mechanism in the core by which you can
> > request that a reinvite be sent to do this. PJSIP presents a PJSIP
> > specific dialplan function which can do it, and the interface for doing
> > remote RTP bridging naturally allows it (but not solely for the purposes
> > of changing the media codec). A mechanism for doing this has actually
> > been defined as part of the stream support[1] coming in 15. We will
> > accept incoming reinvites and act accordingly in a simple manner.
> 
> You're speaking here about *incoming* reinvites to change codec (this is
> already working today - I could see it with my C610IP).
> To change a codec used by a stream subsequently after the initial
> negotiation to prevent existing transcoding, the reinvite must be
> started by asterisk itself. Will this be done, too?

I'm talking about outgoing reinvites. The stream support includes a way
to do this. You request that a stream topology (which includes what
streams are present, their type, the formats) be changed. This will
result in a reinvite going out and the result being conveyed back.

> 
> > We
> > don't pass the information to the other side, we just adjust our formats
> > and transcoding.
> 
> Yes. That's not necessary. But it is necessary, that asterisk is able to
> identify
> - that transcoding between two UAs is currently active.
> - the codec used by the peer UA stream and if this codec is allowed (by
> configuration) for the other UA, too. If yes: send other UA a reinvite
> to ensure both UAs are using the same codec as from now and switch off
> transcoding and all other related stuff, which isn't need any more.

It's not currently possible to know from a configuration perspective.
The bridging core can know what has been currently negotiated on each
side only. There is no mechanism to reach across and get the
configuration information.

> 
> > A reinvite is also an asynchronous operation, so you would still need to
> > set up a translation path to ensure any media flowed in the meantime and
> > once accepted (if it is) the translation path could be terminated.
> 
> Yes. But you must have it already today in some way, as changing codec
> originated by UA already works fine here.

Yes, we accept the incoming reinvite, negotiate it against the
configuration, update the formats on the channel, and change the
translation paths accordingly. If this results in no translation path
then the existing is terminated.

-- 
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & www.asterisk.org