Just pipe it to a file. fs_cli > file.txt. However, without seeing any logs there are really only two options, the remote node doesn't offer GSM codec, or GSM codec is not loaded in FS (IIRC mod_spandsp handles this codec). /Peter 13 apr 2012 kl. 07:45 skrev "Malay Thakershi" <mthakershi@gmail.com>:
When I do "sofia global siptrace on", my console just doesn't stop. I get text so fast, I can't even paste the originate command. So I can't produce what will hep you help me on this.
Is there a way I can divert the whole thing to a text file?
Thanks.
Malay
On Thu, Apr 12, 2012 at 10:55 PM, Vitalie Colosov <vetali100@gmail.com> wrote:
Could you collect the full siptrace of one call and paste into pastebin?
To do so, type at the cli:
sofia global siptrace on
Then make 1 call and collect whatever you got at the screen, and paste into pastebin.
Then, you'll probably want to disable siptrace:
sofia global siptrace off
Regards, Vitalie
2012/4/12 Malay Thakershi <mthakershi@gmail.com>
Thanks.
Before I do what you said, I have another problem. Sorry about that.
I use different mechanism to make outgoing calls (originate calls from ESL). So I do not use bridge. I tried to put "{absolute_codec_string=GSM}" in originate call along with other parameters I pass but it throws error.
My originate call looks like: originate {absolute_codec_string=GSM,ignore_early_media=true,origination_caller_id_name=CH,origination_caller_id_number=1877XXXXXXX,originate_timeout=45,chivr_outbound=true,other_var=1}sofia/gateway/vitelity-outbound/1972XXXXXXX 1056 XML default
Error thrown on the log: -ERR INCOMPATIBLE_DESTINATION 2012-04-12 19:14:01.589739 [NOTICE] sofia.c:6332 Hangup sofia/sipinterface_1/1972XXXXXXX [CS_CONSUME_MEDIA] [INCOMPATIBLE_DESTINATION]
Call without absolute_codec_string works fine.
The way this works is: call gets originated -- it goes to default dial plan extension 1056 -- mod_managed is called from this point to handle call flow.
<extension name="CH1"> <!-- Calls from public.xml will come with 1056 extension and will be handled here --> <condition field="destination_number" expression="^1056$"> <!-- codec trial setting --> <!-- <action application="set" data="absolute_codec_string=GSM"/> --> <!-- <action application="log" data="codec debug: codec_string is ${codec_string}" /> <action application="log" data="codec debug: originator_codec is ${originator_codec}" /> <action application="log" data="codec debug: absolute_codec_string is ${absolute_codec_string}" /> --> <action application="sleep" data="1000" /> <action application="managed" data="clsAsmtApp" /> </condition> </extension>
As you can see, I tried setting absolute string from here too but it didn't work.
Let me know what can be done if you can.
Thanks.
Malay
On Wed, Apr 11, 2012 at 5:48 PM, Vitalie Colosov <vetali100@gmail.com> wrote:
Lets forget for a minute about vars.xml and what is there (when you use absolute_codec_string=GSM, it overrides any settings from vars.xml), and concentrate at the OUTGOING call from FreeSWITCH to your sip provider first.
Try to change your bridge to the following string: <action application="bridge">
data="{absolute_codec_string=GSM}sofia/gateway/your_provider/12345678901_example"/>
(obviously use your sip provider and phone number :)
And do one outgoing call to this sip provider.
Then, reply back whether the call was successful or not (did you hear the voice and whether the other party did hear you). And paste the log to the pastebin (http://pastebin.freeswitch.org/) and reply back with the link.
2012/4/11 Malay Thakershi <mthakershi@gmail.com>
1.You need OUTGOING leg to use GSM codec, right? (You wont be able to use G729 right now as it needs the license). By OUTGOING I mean call from FreeSWITCH to your provider, and not back. Yes. I want to try some codec that will use less bandwidth and see how much audio quality is compromised. So I chose GSM because G729 has license requirements.
I want this to work when someone calls my DID or my FS program calls someone via DID. So both for incoming calls as well as outgoing calls.
2. If #1 is true, then inbound-codec-negotiation is not much useful at this point. Because this setting is for INCOMING leg, and not for OUTGOING. And even if it _might_ be using GSM for INCOMING leg, but still transcode to the OUTGOING PCMA/PCMU by some reason (this is what we need to find out - why). I am not very familiar with internals of FS so having lot of trouble figuring this out.
Weird thing is, even if I do not have any mention of G729, it is being negotiated and used. Here are my configuration lines: vars.xml <X-PRE-PROCESS cmd="set" data="global_codec_prefs=GSM,PCMU,PCMA"/> <X-PRE-PROCESS cmd="set" data="outbound_codec_prefs=GSM,PCMU,PCMA"/>
sip profile has: <param name="inbound-codec-negotiation" value="greedy"/>
dial plan <extension name="CH"> <condition field="destination_number" expression="^105\d$"> <action application="set" data="absolute_codec_string=GSM"/> <action application="sleep" data="1000"/> <action application="managed" data="clsAsmtApp"/> </condition> </extension>
<extension name="vitel-outbound"> <condition field="destination_number" expression="^(1{0,1}\d{10})$"> <action application="set" data="absolute_codec_string=GSM"/> <action application="set" data="effective_caller_id_number=18770001111"/> <action application="bridge" data="sofia/gateway/vitelity-outbound/$1"/> </condition> </extension>
3. Try using absolute_codec_string before bridging your call to your SIP provider:
<action application="set" data="absolute_codec_string=GSM"/> <action application="bridge" data="sofia/gateway/your_provider/12345678901_example"/>
I did as you said. But found what I described above. If I remove "greedy" setting, system simply uses PCMU codec like before.
This thing is so confusing. Even my SIP provider is saying they can't help out with FS because some guy quit who knew the configurations.
Thanks for help.
On Wed, Apr 11, 2012 at 4:12 PM, Vitalie Colosov <vetali100@gmail.com> wrote:
Lets confirm the following statements now:
1.You need OUTGOING leg to use GSM codec, right? (You wont be able to use G729 right now as it needs the license). By OUTGOING I mean call from FreeSWITCH to your provider, and not back.
2. If #1 is true, then inbound-codec-negotiation is not much useful at this point. Because this setting is for INCOMING leg, and not for OUTGOING. And even if it _might_ be using GSM for INCOMING leg, but still transcode to the OUTGOING PCMA/PCMU by some reason (this is what we need to find out - why).
3. Try using absolute_codec_string before bridging your call to your SIP provider:
<action application="set" data="absolute_codec_string=GSM"/> <action application="bridge" data="sofia/gateway/your_provider/12345678901_example"/>
And reply back if this changes anything...
Vitalie
2012/4/11 Malay Thakershi <mthakershi@gmail.com> > > Under my sipinterface_1 profile that I use for these calls, I have: > > <param name="inbound-codec-negotiation" value="greedy"/> > > On Wed, Apr 11, 2012 at 1:43 PM, Bzzz <lazyvirus@gmx.com> wrote: >> >> On Wed, 11 Apr 2012 13:31:45 -0500 >> Malay Thakershi <mthakershi@gmail.com> wrote: >> >>> Understood your point about G722. But if my list has GSM at >>> higher >>> priority >>> over PCMU/PCMA and far-end SDP supports GSM then why isn't the >>> call >>> using >>> GSM? >>> >>> I don't know where G726 comparisons are coming from. If I haven't >>> mentioned >>> it in vars.xml and far-end SDP doesn't support it then why would >>> it >>> even >>> consider that codec? >> >> From: wiki.freeswitch.org/wiki/Sofia_Configuration_Files >> (inbound-codec-negotiation): >> 'generous' permits the remote codec list have precedence and 'win' >> the codec negotiation and selection process >> >> JY >> -- >> Don't drop acid -- take it pass/fail. >> -- Seen in a Ladies' Room at Harvard >> >> >> >> >> _________________________________________________________________________ >> Professional FreeSWITCH Consulting Services: >> consulting@freeswitch.org >> http://www.freeswitchsolutions.com >> >> FreeSWITCH-powered IP PBX: The CudaTel Communication Server >> http://www.cudatel.com >> >> Official FreeSWITCH Sites >> http://www.freeswitch.org >> http://wiki.freeswitch.org >> http://www.cluecon.com >> >> FreeSWITCH-users mailing list >> FreeSWITCH-users@lists.freeswitch.org >> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users >> >> >> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users >> http://www.freeswitch.org > > > > > > _________________________________________________________________________ > Professional FreeSWITCH Consulting Services: > consulting@freeswitch.org > http://www.freeswitchsolutions.com > > FreeSWITCH-powered IP PBX: The CudaTel Communication Server > http://www.cudatel.com > > Official FreeSWITCH Sites > http://www.freeswitch.org > http://wiki.freeswitch.org > http://www.cluecon.com > > FreeSWITCH-users mailing list > FreeSWITCH-users@lists.freeswitch.org > http://lists.freeswitch.org/mailman/listinfo/freeswitch-users > > > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users > http://www.freeswitch.org >
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
!DSPAM:4f87bae732768532145870!