Analysis of Asterisk1.8 transcoding strategy

Recently, in the modification of Asterisk transcoding and coding negotiation, it is found that the choice of Asterisk transcoding strategy is still somewhat problematic (based on the 1.8.9.3 version).
——————————————
Related CLI Commands
Debug commands for transcoding paths:
Core Show Channels
Core Show Channel ${channel}

To view the time overhead for converting between different encodings:
Core Show Translation

To view the path to which a certain encoding is converted to another encoding:
Core Show translation paths {codec}
Eg:core Show translation Paths Ulaw

Data members related to transcoding in Ast_channel:
Ast_channel->nativeformats
Ast_channel->writeformat
Ast_channel->readformat
Ast_channel->rawwriteformat
Ast_channel->rawreadformat
Ast_channel->writetrans
Ast_channel->readtrans
——————————————
Here's the case for testing:
Phone A:PCMU phone b:gsm
User a:pcmu,gsm User b:pcma,gsm

This is true for the transcoding path of the use case asterisk.
1.phone A = Phone B
Channel A read transcoding (PCMU = PCMA)
Channel B Write transcoding (PCMA = Slinear = GSM)
2.phone B = Phone A
Channel B read transcoding (GSM = Slinear = PCMU)
Channel a write transcoding (PCMU without transcoding)

From the caller to the called and from the called to the calling of the transcoding path is inconsistent, the former more than the latter from the PCMU to PCMA conversion. Why does this happen?

Open the log switch, analyze it with CLI commands, and start looking at the code.

Asterisk the choice of whether transcoding and transcoding strategies are required is done in ast_channel_make_compatible. The function also calls Ast_channel_make_compatible_helper to set the transcoding strategy from calling to called and called to calling.

intAst_channel_make_compatible (structAst_channel *chan,structAst_channel *peer) {    /*Some callers do not check return code, and we must try to set all call legs correctly*/    intrc =0; /*Set up translation from the Chan to the peer*/    //Modify//rc = Ast_channel_make_compatible_helper (chan, peer);rc = Ast_channel_make_compatible_helper (chan, Peer,0); //Modify End     if(RC <0)        returnRC; /*Set up translation from the peer to the Chan*/    //Modify//rc = Ast_channel_make_compatible_helper (peer, Chan);rc = Ast_channel_make_compatible_helper (Peer, Chan,1); //Modify End     returnRC;}

Ast_channel_make_compatible_helper determines if the encoding of the caller's channel is compatible, and if no, calls Ast_set_read_format and Ast_set_write_ Format sets the Readformat and Writeformat, respectively, and establishes the transcoding path.

/*! \brief Set up translation from one channel to another*//*modify:add a ' bool ' argument to judge which is a caller channel and which a callee channel.        If ' bool ' is true and then the ' from ' was a caller channel, ' to ' is a callee channel. Otherwise, ' to ' was a caller channel, ' from ' is a callee channel.*/Static intAst_channel_make_compatible_helper (structAst_channel * from,structAst_channel *to,int BOOL) {format_t src, DST; //int Use_slin;     /*See If the channel driver can natively make these-channels compatible*/    if( from->tech->bridge && from->tech->bridge = = To->tech->bridge &&!ast_channel_setoption ( from, Ast_option_make_compatible, to,sizeof(structAst_channel *),0)) {        return 0; }     if( from->readformat = = To->writeformat && from->writeformat = = to->Readformat) {        /*already compatible! Moving on ...*/Ast_log (Log_notice,"already compatible!\n"); return 0; }     /*Set up translation from the "from " channel to the "channel"*/src= from-Nativeformats; DST= to->Nativeformats; /*If There's no audio in this call, don ' t bother with trying to find a translation path*/    if(src & ast_format_audio_mask) = =0|| (DST & ast_format_audio_mask) = =0)        return 0; if(Ast_translator_best_choice (&AMP;DST, &AMP;SRC) <0) {Ast_log (log_warning,"No path to translate from%s to%s\n", from->name, to->name); return-1; }     /*if the best path was not ' pass through ' and then * transcoding was needed; if desired, Force transcode path * to u Se slinear between channels, but only if there is * no direct conversion available. If generic PLC is * desired, then transcoding via slinear is a requirement*/     //Modify:comment These    /*Use_slin = (src = = Ast_format_slinear | | dst = = ast_format_slinear); if (src! = DST) && (AST_OPT_GENERIC_PLC | | ast_opt_transcode_via_slin) && (ast_translate_path_step S (DST, src)! = 1 | |        Use_slin) {Ast_log (Log_notice, "DST is ast_format_slinear!\n");    DST = ast_format_slinear; }    */    //Modify End//Add    /*we only build translation path and does translations in the callee channel. To achieve this goal, we set Readformat and Writeformat of the caller channel and the callee channel both to native    Format of the caller CHANNEL,SO the caller channel won ' t execute Read-transcode and Write-transcode. */    if(BOOL) {DST=src; }    //Add End     if(Ast_set_read_format ( from, DST) <0) {Ast_log (log_warning,"unable to set read format on channel%s to%s\n", from-name, Ast_getformatname (DST)); return-1; }    if(Ast_set_write_format (To, DST) <0) {Ast_log (log_warning,"Unable to set write format on channel%s to%s\n", to->name, Ast_getformatname (DST)); return-1; }     return 0;}

In Ast_set_read_format, first call Ast_translator_best_choice (&fmt,&native) from native (that is, the nativeformates of the corresponding channel) and FMT ( The encoding collection to be set), select an optimal encoding separately and reassign the selected encoding to native and FMT, where the address is passed and modified by the pointer. The value of the native is then assigned to Rawformat (the channel's Rawreadformat), and the value of the FMT is assigned to format (the Readformat of the channel). Finally, if format is not the same as the native value, call Ast_translator_build_path (*format, *rawformat) to create a linked list of transcoding paths. Ast_set_write_format and Ast_set_read_format the same, except that the FMT is assigned to the channel Writeformat,native is assigned to the channel Rawwriteformat.

After receiving the OK, PROCESS_SDP (FILE:CHANNELS/CHAN_SIP.C) is called to parse the SDP, and the nativeformats of the called Channel may change when processing the SDP of the called Terminal. The read-write transcoding path for the called channel needs to be reset, for Writetranscode: conversion from Channel->writeformat to Channel->nativeformats, for Readtranscode: Convert from Channel->nativeformats to Channel->readformat. The Writeformat and Readformat of the called Channel have been set before the call to Ast_channel_make_compatible.

    if(! (P->owner->nativeformats & P->jointcapability) && (P->jointcapability &ast_format_audio_mask)) {        if(Debug) {CharS1[sipbufsize], s2[sipbufsize]; Ast_debug (1,"Oooh, we need to the change we have audio formats since our peer supports only%s and not%s\n", Ast_getformatname_multiple (S1, sipbufsize, p-jointcapability), ast_getformatname_multiple (S2, sipbufsize, p->owner->nativeformats)); } P->owner->nativeformats = Ast_codec_choose (&p->prefs, P->jointcapability,1) | (P->capability & vpeercapability) | (P->capability &tpeercapability); Ast_set_read_format (P->owner, p->owner->Readformat); Ast_set_write_format (P->owner, p->owner->Writeformat); }

Come back to our question. After analysis, the cause of this problem is that the Channelb->nativeformats audio encoding is ulaw before receiving the call, and after receiving the OK,channelb-> The audio encoding of the nativeformats is G729, and when the channel is bridged, there is no check whether the channelb->nativeformats has changed or not to change the Channelb->writeformat (in the example Ulaw) and Channela->readformat (Ulaw in the example), so that the caller still follows the previously selected path to transcode, resulting in unnecessary transcoding steps.

In addition, in the implementation of Asterisk about transcoding, both the calling and the called channels are respectively Writetranscode and Readtranscode (can be viewed through the core show channel Sip/{exten) during the call, This can use up to four transcoding resources (AST_TRANS_PVT) per call. In response to these problems, I modified the practice is: only on the side of the called Channel to do transcoding, the main call, called Channel Readformat and Writeformat set as the main channel nativeformats (the nativeformats is not changed), This way, the calling channel does not need to allocate transcoding resources, up to a maximum of two transcoding resources. And if the nativeformats of the called Channel is changed after processing the SDP called the terminal reply, there is no need to reset the calling and called Readformat and Writeformat, only the read and write transcoding path of the called Channel can be reset ( See the Modify and Add sections in the code above for specific modifications).

Ast_channel_make_compatible This function simply examines some encoded members of the two channel data structures in the call and sets the encoding path between the two channel. The actual transcoding is bridged (for example: Ast_generic_bridge) in Ast_read or Ast_write, and calls Ast_translate according to the set transcoding before reading and writing the frame

Analysis of Asterisk1.8 transcoding strategy