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. We don't pass the information to the other side, we just adjust our formats and transcoding. 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. As well the core has no concept of "extensions". 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. [1] https://wiki.asterisk.org/wiki/display/AST/Stream+Support -- 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 -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
