<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 29, 2014 at 6:15 AM, Joshua Colp <span dir="ltr"><<a href="mailto:jcolp@digium.com" target="_blank">jcolp@digium.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><div class="h5">Matthew Jordan wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
(1) Where will the packetization of a format on a channel reside? With<br>
the format on the channel? Or with the capability of the channel?<br>
</blockquote>
<br></div></div>
It "has" to reside in the RTP engine layer and optionally can (but I've written it so it is) in the format capabilities layer.<br>
<br>
It has to be in the RTP layer so that the underlying stack can know how to set up the smoother so packets contain the right amount of media.<br>
<br>
It can optionally be in format capabilities so that further down the road the smoothing logic can be moved out of RTP and into the core.<div class=""><br></div></blockquote><div><br>I'd say it makes sense then for the information to reside in an 
ast_format_cap structure. The RTP engine can use that as its storage 
mechanism, and it makes it easier to extract to the core if needed.<br><br></div><div>Storing it in two places could get confusing and lead to errors.<br></div><br><div><snip><br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="">
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
(3) Are all these questions moot, and should I just go ahead and add the<br>
proposed framing size functions from the wiki:<br>
<br>
<br></blockquote></div></blockquote><div><br></div><div><snip><br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

</blockquote>
<br></div>
The ability to set the framing per-format, globally in a capabilities structure, and to get the framing already exists. What doesn't exist is adding a format and then setting the framing as two separate API calls. That is something that could be added but to make sure you set the right format (format capabilities can contain multiple formats of the same codec) you have to keep that format around, in which case why not just add/set in the same API call?<br>
</blockquote><div><br></div><div>We may end up needing that API call sometime down the road. For example, if an Offer arrives with a new ptime attribute, it may be easier to modify an existing ast_format_cap structure rather than create a new one. But currently I just need the packetization values.<br>
<br></div><div>What API call provides them? I must be missing it, because I couldn't seem to find it in format_cap.h. (I could be just going crazy however)<br><br>Matt <br></div></div><br>-- <br><div dir="ltr"><div>Matthew Jordan<br>
</div><div>Digium, Inc. | Engineering Manager</div><div>445 Jan Davis Drive NW - Huntsville, AL 35806 - USA</div><div>Check us out at: <a href="http://digium.com" target="_blank">http://digium.com</a> & <a href="http://asterisk.org" target="_blank">http://asterisk.org</a></div>
</div>
</div></div>