I believe in the scenario you describe that the call would fail since the incoming call cannot inherit the only codec supported by the b leg device (GSM).<div><br></div><div>-MC<br><br><div class="gmail_quote">On Thu, May 26, 2011 at 10:56 AM, Spencer Thomason <span dir="ltr"><<a href="mailto:spencer@5ninesolutions.com">spencer@5ninesolutions.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div style="word-wrap:break-word">Thanks for you help, I'll try that. So I'm a little confused with the negotiation process with two profiles. Lets say for example that I have a device that only supports GSM on the internal profile and a call comes in on the external profile as ULAW, G729. If I set inherit_codec=true would Freeswitch then transcode? How does the disable-transcoding option work in regards to two profiles? I.e. Only one profile has transcoding disabled but a call traverses both of them.. (2 legs, one bridge). Which profile would the transcoding need to be enabled (or not disabled rather)?<div>
<br></div><div>Thanks,</div><div>Spencer</div><div><div></div><div class="h5"><div><br></div><div><br><div><div>On May 26, 2011, at 11:47 AM, DJB International wrote:</div><br><blockquote type="cite">Your profile has late negotion enabled. I believe you can set inherit_codec=true, so that it will force A leg to use the same codec as B leg offered.<span style="border-collapse:separate;font-family:'Times New Roman';font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;font-size:medium"><span style="font-family:sans-serif;font-size:13px;line-height:19px"></span></span><br>
<br><br><div class="gmail_quote">On Thu, May 26, 2011 at 9:04 AM, Spencer Thomason <span dir="ltr"><<a href="mailto:spencer@5ninesolutions.com" target="_blank">spencer@5ninesolutions.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello all,<br>
I have a problem regarding the codec negotiation on an outbound call. My setup is like this:<br>
<br>
Polycom IP 650 (1-n) -NAT-> FS --> Our Signaling Proxy --> ITSP Proxy ---> ITSP Cisco GW<br>
<br>
I'd like to use different codecs for different call paths (in order of pref), g729 in passthru only:<br>
IP-650 -> IP-650 G722, PCMU, G729<br>
Inbound -> IP-650 PCMU<br>
IP-650 -> Outbound PCMU,G729<br>
<br>
I have two sofia profiles, internal, public IPv4:5060 and external, public:IPv4:5080.<br>
<br>
The phones use the internal profile and the external profile only communicates with our signaling proxy (no media proxy).<br>
On the internal one:<br>
CODECS IN G722,PCMU,G729,GSM<br>
CODECS OUT G722,PCMU,G729,GSM<br>
NOMEDIA false<br>
LATE-NEG true<br>
<br>
External:<br>
CODECS IN PCMU,G729<br>
CODECS OUT PCMU,G729<br>
NOMEDIA false<br>
LATE-NEG true<br>
<br>
I have inbound-codec-negotiation set to greedy on both profiles and on outbound calls set absolute_codec_string=PCMU,G729 to prevent transcoding. Note that mod_g729 is enabled for passthru only.<br>
<br>
The problem I have is this:<br>
We use the dynamic routing module in OpenSIPS to select an outbound provider/GW, all support PCMU and G729. On one of the routes, the Cisco IOS GW on this route has G729, PCMU configured as its codec pref.<br>
<br>
I have included a ladder diagram to better illustrate the problem but in a nutshell, the polycom negotiates PCMU with FS, FS asks for both PCMU and G729, the cisco GW sends G729 and FS sends a 488 because it can't transcode. I would like to keep G729 in the outbound prefs because some routes might not support PCMU. Should I set one of the profiles to generous, and if so which one?<br>
<br>
When someone makes an outbound call the following happens (ladder diagram):<br>
<a href="http://pastebin.freeswitch.org/16380" target="_blank">http://pastebin.freeswitch.org/16380</a><br>
<br>
<br>
Sorry for the novella, :-)<br>
<br>
Thanks!<br>
Spencer<br>
<br>
<br>
_______________________________________________<br>
FreeSWITCH-users mailing list<br>
<a href="mailto:FreeSWITCH-users@lists.freeswitch.org" target="_blank">FreeSWITCH-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org/" target="_blank">http://www.freeswitch.org</a><br>
</blockquote></div><br>
_______________________________________________<br>FreeSWITCH-users mailing list<br><a href="mailto:FreeSWITCH-users@lists.freeswitch.org" target="_blank">FreeSWITCH-users@lists.freeswitch.org</a><br><a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br><a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
</blockquote></div><br></div></div></div></div><br>_______________________________________________<br>
FreeSWITCH-users mailing list<br>
<a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<br></blockquote></div><br></div>