<div dir="ltr">Like a normal person, I decided to poke at the format work while watching tornadoes track North and South of Huntsville (because really, what else are you going to do?) After looking through Josh's notes on the wiki [1] and the code in the team branch [2], I decided to tackle bridge_native_rtp (as it was the first thing that didn't compile). After hacking through it a bit, I had a few questions. Since this is going to be a recurring theme while working on this, a thread seemed in order.<br>
<br>So: if you decide to work on this or take a poke at it and have some questions about things, feel free to respond to this thread.<br><br>Anyway, without further ado:<br><br>There is a portion of bridge_native_rtp that attempts to check if the channels are still compatible. If not, it breaks the native bridge so that the bridging framework can attempt a more suitable mixing technology. Part of the check looks at the packetization attribute of the formats in use:<br>
<br><span style="font-family:courier new,monospace">    read_ptime0 = (ast_codec_pref_getsize(&ast_rtp_instance_get_codecs(instance0)->pref, ast_channel_rawreadformat(c0->chan))).cur_ms;<br>    read_ptime1 = (ast_codec_pref_getsize(&ast_rtp_instance_get_codecs(instance1)->pref, ast_channel_rawreadformat(c1->chan))).cur_ms;<br>
    write_ptime0 = (ast_codec_pref_getsize(&ast_rtp_instance_get_codecs(instance0)->pref, ast_channel_rawwriteformat(c0->chan))).cur_ms;<br>    write_ptime1 = (ast_codec_pref_getsize(&ast_rtp_instance_get_codecs(instance1)->pref, ast_channel_rawwriteformat(c1->chan))).cur_ms;<br>
<br>    if (read_ptime0 != write_ptime1 || read_ptime1 != write_ptime0) {<br>        ast_debug(1, "Packetization differs between RTP streams (%d != %d or %d != %d). Cannot native bridge in RTP\n",<br>                read_ptime0, write_ptime1, read_ptime1, write_ptime0);<br>
        return 0;<br>    }<br></span><br>That is, if the packetization between the read/write of each channel pair is not the same, break the bridge.<br><br>Right now, there aren't compatible calls with this code in the branch. So... questions!<br>
<br>(1) Where will the packetization of a format on a channel reside? With the format on the channel? Or with the capability of the channel?<br><br>(2) Should we even be bothering with the codec's preferred packetization here? It doesn't really matter what a codec prefers at this point - if an SDP negotiated a different packetization rate, that's what we care about...<br>
<br>(3) Are all these questions moot, and should I just go ahead and add the proposed framing size functions from the wiki:<br><br>{quote}<br>Framing size<br><br>The framing size controls the length of media frames (in milliseconds). Previously this was stored in a separate structure but has now been rolled into ast_format_cap. To allow control two API calls will be added.<br>
<br><span style="font-family:courier new,monospace">void ast_format_cap_framing_set(struct ast_format_cap *cap, const struct ast_format *format, unsigned int framing);<br>unsigned int ast_format_cap_framing_get(const struct ast_format_cap *cap, const struct ast_format *format);</span><br>
{quote}<span class="sew4hz45a2ygrfc"></span><span class="sew4hz45a2ygrfc"></span><br><br>[1] <a href="https://wiki.asterisk.org/wiki/display/AST/Media+Format+Rewrite">https://wiki.asterisk.org/wiki/display/AST/Media+Format+Rewrite</a><br>
<br>[2] <a href="https://origsvn.digium.com/svn/asterisk/team/group/media_formats">https://origsvn.digium.com/svn/asterisk/team/group/media_formats</a><br><br>-- <br>Matthew Jordan<br>Digium, Inc. | Engineering Manager<br>
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA<br>Check us out at: <a href="http://digium.com">http://digium.com</a> & <a href="http://asterisk.org">http://asterisk.org</a></div>