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

[Michael Maier]

On 01/31/2017 at 01:38 PM Joshua Colp wrote:
> On Tue, Jan 31, 2017, at 04:22 AM, Michael Maier wrote:
> 
> <snip>
> 
>>
>> My first idea was to prevent transcoding already during call setup. But
>> now I understand, that this is not a trivial thing to do.
>>
>> Would it be easier to do it *after* the call has been completely
>> established (peer has answered and both legs have been finally
>> established)?
>>
>> Start an additional job (if a new extension based option
>> (prevent_transocding e.g.) is set to true) which first checks, if
>> transcoding for this extension is active. If it is active, check, if the
>> target codec is part of the defined codecs for this extension. If yes,
>> send a reinvite to the extension to place the target codec as new codec.
>>
>> I would shrink this feature to extensions. If the call is between two
>> extensions, do it always for the callers extension.
>>
>> This sounds practicable to *me* (but I'm not an asterisk specialist :-))
>> as you already today have to be able to change codecs on base of a
>> reinvite during a running call.
> 
> 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?

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

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

> As well the core has no concept of "extensions".

You're right. This isn't necessary. It is enough to switch on this
feature by an option. If this option is set for a trunk or an extension
shouldn't matter. It's the decision of the admin.

> It just knows channels.
> The mechanism and behavior for controlling the above and how it would
> interact with the core would also need to be defined. For example the
> request to do the reinvite could always be provided to the channel
> driver and then it would decide what to do based on configuration.

This sounds reasonable to me.

> [1] https://wiki.asterisk.org/wiki/display/AST/Stream+Support
> 


Thanks,
Michael