<div dir="ltr">Guys,<div><br></div><div>just tried asterisk13 and added seanbrights' patch for opus.</div><div><br></div><div>incoming INVITE has fmtp ------> maxplaybackrate=8000;sprop-maxcapturerate=8000</div><div>but INVITE to my registered peer is ----------> maxplaybackrate=48000;sprop-maxcapturerate=48000</div><div><br></div><div>it should not even have to load up the opus patch because it is just a passthrough.</div><div>have you changed anything to chan_sip.c to make this work?</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature">Kelvin Chua</div></div>
<br><div class="gmail_quote">On Sat, Jun 27, 2015 at 7:26 AM, Kelvin Chua <span dir="ltr"><<a href="mailto:kelchy@gmail.com" target="_blank">kelchy@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">i verified parse_sdp is doing its job correctly and stores it in struct. but after going back to chan_sip somehow somewhere everything resets before generate_sdp. maybe because i am working on ast12, i'm going to try 13</p><div class="HOEnZb"><div class="h5">
<div class="gmail_quote">On Jun 26, 2015 5:49 PM, "Joshua Colp" <<a href="mailto:jcolp@digium.com" target="_blank">jcolp@digium.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Kelvin Chua wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Just an experiment I am doing, correct me if I am wrong<br>
<br>
If I receive an INVITE with fmtp from a peer, it won't be used to build<br>
the INVITE to the egress right?<br>
<br>
What will happen is, codecs.conf will be checked for the parameters and<br>
use that to build the INVITE.<br>
<br>
Is there any function I can use to get away from this behavior and act<br>
like a proxy and just copy the fmtp from the ingress?<br>
</blockquote>
<br>
As Alexander mentioned there has to be a specific handler for each codec in order to parse/store/create the specific attributes internally. It's not done for every codec. Asterisk also has to be aware of the codec. This is a bit easier in 13+, but may be possible in earlier versions depending on the amount of storage required.<br>
<br>
Cheers,<br>
<br>
-- <br>
Joshua Colp<br>
Digium, Inc. | Senior Software Developer<br>
445 Jan Davis Drive NW - Huntsville, AL 35806 - US<br>
Check us out at: <a href="http://www.digium.com" rel="noreferrer" target="_blank">www.digium.com</a> & <a href="http://www.asterisk.org" rel="noreferrer" target="_blank">www.asterisk.org</a><br>
<br>
-- <br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" rel="noreferrer" target="_blank">http://www.api-digital.com</a> --<br>
<br>
asterisk-dev mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
  <a href="http://lists.digium.com/mailman/listinfo/asterisk-dev" rel="noreferrer" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-dev</a><br>
</blockquote></div>
</div></div></blockquote></div><br></div>