Recently I noticed that fs (1.0.3 RC1) is not processing the calls. Previously about 50-60 calls were remaining active at any time. But then suddenly, only 5-6 active calls were there. So I checked sip INVITE's in ngrep, and I noticed that originator were sending CANCEL after INVITE. So I contacted them and they were telling that while sending calls, your gateways time outs after a call is sent, and so they send CANCEL after INVITE. My architecture is as follows : originator -> switch (our fs) -> terminator. CPU : Intel(R) Xeon(R) CPU X3220 @ 2.40GHz OS : Ubuntu 6.06.1 LTS 32-bit RAM : 4 GB We had also set ulimits on command prompt every time before starting fs with nc mode as follows : ulimit -c unlimited; ulimit -n 999999; ulimit -s 244; /usr/local/freeswitch/bin/freeswitch -nc In the ngrep trace, I noticed that fs was not sending INVITE to terminator in between the INVITE and CANCEL from originator. So what could be the reason for INVITE not being processed by fs and getting timeout from originator. Here is the sip trace for a sample call. Check the duration between INVITE and CANCEL from originator. -------------------------------------------------------------------- U 2009/02/07 13:16:44.354443 ori.ori.ori.ori:2000 -> fs.fs.fs.fs:5060 INVITE sip:yyyyyyyyyyyy@fs.fs.fs.fs:5060;user=phone SIP/2.0. Call-ID: 7008117790783130205-1234012604@ori.ori.ori.ori. From: <sip:xxxxxxxxxxx@ori.ori.ori.ori:2000;user=phone>;tag=13475. To: <sip:yyyyyyyyyyyy@fs.fs.fs.fs:5060;user=phone>. Content-Type: application/sdp. CSeq: 1 INVITE. Via: SIP/2.0/UDP ori.ori.ori.ori:2000;branch=z9hG4bK-6141d60007b94a5d-4297d09d-1. Contact: sip:xxxxxxxxxxx@ori.ori.ori.ori:2000;user=phone. Allow: INVITE,CANCEL,BYE,ACK,REFER,UPDATE,INFO. Supported: timer,100rel. Max-Forwards: 70. Content-Length: 317. . v=0. o=MG4000|2.0 492612 492612 IN IP4 66.151.208.138. s=-. c=IN IP4 66.151.208.138. t=0 0. m=audio 38832 RTP/AVP 97 18 98 96 101 13. a=rtpmap:97 G.729b/8000. a=rtpmap:98 G.729a/8000. a=rtpmap:96 G.729ab/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=fmtp:18 annexb=yes. a=ptime:20. a=rtpmap:13 CN/8000. # U 2009/02/07 13:16:44.354633 fs.fs.fs.fs:5060 -> ori.ori.ori.ori:2000 SIP/2.0 100 Trying. Via: SIP/2.0/UDP ori.ori.ori.ori:2000;branch=z9hG4bK-6141d60007b94a5d-4297d09d-1. From: <sip:xxxxxxxxxxx@ori.ori.ori.ori:2000;user=phone>;tag=13475. To: <sip:yyyyyyyyyyyy@fs.fs.fs.fs:5060;user=phone>. Call-ID: 7008117790783130205-1234012604@ori.ori.ori.ori. CSeq: 1 INVITE. User-Agent: FreeSWITCH-mod_sofia/1.0.trunk-hacked. Content-Length: 0. U 2009/02/07 13:16:59.208008 ori.ori.ori.ori:2000 -> fs.fs.fs.fs:5060 CANCEL sip:yyyyyyyyyyyy@fs.fs.fs.fs:5060;user=phone SIP/2.0. Call-ID: 7008117790783130205-1234012604@ori.ori.ori.ori. From: <sip:xxxxxxxxxxx@ori.ori.ori.ori:2000;user=phone>;tag=13475. To: <sip:yyyyyyyyyyyy@fs.fs.fs.fs:5060;user=phone>. CSeq: 1 CANCEL. Via: SIP/2.0/UDP ori.ori.ori.ori:2000;branch=z9hG4bK-6141d60007b94a5d-4297d09d-1. Supported: timer,100rel. Max-Forwards: 70. Content-Length: 0. . # U 2009/02/07 13:16:59.208095 fs.fs.fs.fs:5060 -> ori.ori.ori.ori:2000 SIP/2.0 200 OK. Via: SIP/2.0/UDP ori.ori.ori.ori:2000;branch=z9hG4bK-6141d60007b94a5d-4297d09d-1. From: <sip:xxxxxxxxxxx@ori.ori.ori.ori:2000;user=phone>;tag=13475. To: <sip:yyyyyyyyyyyy@fs.fs.fs.fs:5060;user=phone>;tag=7B6p78S5SDF0j. Call-ID: 7008117790783130205-1234012604@ori.ori.ori.ori. CSeq: 1 CANCEL. Content-Length: 0. . # U 2009/02/07 13:16:59.208134 fs.fs.fs.fs:5060 -> ori.ori.ori.ori:2000 SIP/2.0 487 Request Terminated. Via: SIP/2.0/UDP ori.ori.ori.ori:2000;branch=z9hG4bK-6141d60007b94a5d-4297d09d-1. From: <sip:xxxxxxxxxxx@ori.ori.ori.ori:2000;user=phone>;tag=13475. To: <sip:yyyyyyyyyyyy@fs.fs.fs.fs:5060;user=phone>;tag=7B6p78S5SDF0j. Call-ID: 7008117790783130205-1234012604@ori.ori.ori.ori. CSeq: 1 INVITE. User-Agent: FreeSWITCH-mod_sofia/1.0.trunk-hacked. Accept: application/sdp. Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE, NOTIFY, REFER, UPDATE, REGISTER, INFO, PUBLISH. Supported: timer, precondition, path, replaces. Allow-Events: talk, presence, dialog, call-info, sla, include-session-description, presence.winfo, message-summary, refer. Content-Length: 0. U 2009/02/07 13:16:59.253482 ori.ori.ori.ori:2000 -> fs.fs.fs.fs:5060 ACK sip:yyyyyyyyyyyy@fs.fs.fs.fs:5060;user=phone SIP/2.0. Call-ID: 7008117790783130205-1234012604@ori.ori.ori.ori. From: <sip:xxxxxxxxxxx@ori.ori.ori.ori:2000;user=phone>;tag=13475. To: <sip:yyyyyyyyyyyy@fs.fs.fs.fs:5060;user=phone>;tag=7B6p78S5SDF0j. CSeq: 1 ACK. Via: SIP/2.0/UDP ori.ori.ori.ori:2000;branch=z9hG4bK-6141d60007b94a5d-4297d09d-1. Max-Forwards: 70. Content-Length: 0. ------------------------------------------------------- -- View this message in context: http://www.nabble.com/Freeswitch-not-processing-calls-tp21909687p21909687.ht... Sent from the Freeswitch-users mailing list archive at Nabble.com.
I notice it offers 18 which is G729 but these listed below are 100% invalid. There is no such thing as G.729a, G.729b or G.729ab that are valid in the SDP. I suspect if you start FreeSWITCH and crank it up to debug level ("console loglevel debug") you'll clearly see why this is taking place. I think we talked to you on IRC about this and told this. If your termination gateway requires any of the above listed on 96,97 or 98 the call will fail. We can only do passthru on G729 which is the official name which is listed on payload 18. Your termination provider needs to be informed of this fact. The fmtp line is what controls annexb operation! /b On Feb 9, 2009, at 3:46 AM, Ankit Gandhi wrote:
a=rtpmap:97 G.729b/8000. a=rtpmap:98 G.729a/8000. a=rtpmap:96 G.729ab/8000.
Hi Brian, But issue here is that, FS is not processing any such calls and not sending 488 to the caller. Also the sip trace I had provided was from the caller to fs. FS does not even bridge the call to terminator in between the INVITE and CANCEL from the caller. It just gives so many errors in log like following : 2009-02-09 11:31:04 [ERR] mod_g729.c:145 switch_g729_decode() This codec is only usable in passthrough mode! 2009-02-09 11:31:04 [ERR] mod_g729.c:145 switch_g729_decode() This codec is only usable in passthrough mode! 2009-02-09 11:31:04 [ERR] mod_g729.c:145 switch_g729_decode() This codec is only usable in passthrough mode! 2009-02-09 11:31:04 [ERR] mod_g729.c:145 switch_g729_decode() This codec is only usable in passthrough mode! 2009-02-09 11:31:04 [ERR] mod_g729.c:145 switch_g729_decode() This codec is only usable in passthrough mode! It seems odd that due to codec mismatch, fs does not process the call at all and just times out and the caller sends CANCEL to us. Waiting for your reply. Brian West-3 wrote:
I notice it offers 18 which is G729 but these listed below are 100% invalid. There is no such thing as G.729a, G.729b or G.729ab that are valid in the SDP. I suspect if you start FreeSWITCH and crank it up to debug level ("console loglevel debug") you'll clearly see why this is taking place. I think we talked to you on IRC about this and told this. If your termination gateway requires any of the above listed on 96,97 or 98 the call will fail. We can only do passthru on G729 which is the official name which is listed on payload 18. Your termination provider needs to be informed of this fact. The fmtp line is what controls annexb operation!
/b
On Feb 9, 2009, at 3:46 AM, Ankit Gandhi wrote:
a=rtpmap:97 G.729b/8000. a=rtpmap:98 G.729a/8000. a=rtpmap:96 G.729ab/8000.
_______________________________________________ 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
-- View this message in context: http://www.nabble.com/Freeswitch-not-processing-calls-tp21909687p21911300.ht... Sent from the Freeswitch-users mailing list archive at Nabble.com.
Here is the correct codec sent to fs, but it times out again. http://www.nabble.com/file/p21911561/correct_codec_with_cancel.txt correct_codec_with_cancel.txt Ankit Gandhi wrote:
Hi Brian, But issue here is that, FS is not processing any such calls and not sending 488 to the caller. Also the sip trace I had provided was from the caller to fs. FS does not even bridge the call to terminator in between the INVITE and CANCEL from the caller. It just gives so many errors in log like following :
2009-02-09 11:31:04 [ERR] mod_g729.c:145 switch_g729_decode() This codec is only usable in passthrough mode! 2009-02-09 11:31:04 [ERR] mod_g729.c:145 switch_g729_decode() This codec is only usable in passthrough mode! 2009-02-09 11:31:04 [ERR] mod_g729.c:145 switch_g729_decode() This codec is only usable in passthrough mode! 2009-02-09 11:31:04 [ERR] mod_g729.c:145 switch_g729_decode() This codec is only usable in passthrough mode! 2009-02-09 11:31:04 [ERR] mod_g729.c:145 switch_g729_decode() This codec is only usable in passthrough mode!
It seems odd that due to codec mismatch, fs does not process the call at all and just times out and the caller sends CANCEL to us. Waiting for your reply.
Brian West-3 wrote:
I notice it offers 18 which is G729 but these listed below are 100% invalid. There is no such thing as G.729a, G.729b or G.729ab that are valid in the SDP. I suspect if you start FreeSWITCH and crank it up to debug level ("console loglevel debug") you'll clearly see why this is taking place. I think we talked to you on IRC about this and told this. If your termination gateway requires any of the above listed on 96,97 or 98 the call will fail. We can only do passthru on G729 which is the official name which is listed on payload 18. Your termination provider needs to be informed of this fact. The fmtp line is what controls annexb operation!
/b
On Feb 9, 2009, at 3:46 AM, Ankit Gandhi wrote:
a=rtpmap:97 G.729b/8000. a=rtpmap:98 G.729a/8000. a=rtpmap:96 G.729ab/8000.
_______________________________________________ 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
-- View this message in context: http://www.nabble.com/Freeswitch-not-processing-calls-tp21909687p21911561.ht... Sent from the Freeswitch-users mailing list archive at Nabble.com.
1) please do not report bugs on the mailing list. 2) please report the bug on jira http://jira.freeswitch.org according to the rules: http://wiki.freeswitch.org/wiki/Reporting_Bugs If you have an issue that you want us to correct you will have to try the latest SVN trunk (not a snapshot) issue "make current" from your RC1 directory. Attach the entire console log output from start of call to finish with console loglevel debug. On Mon, Feb 9, 2009 at 6:06 AM, Ankit Gandhi <ahgindia308@gmail.com> wrote:
Here is the correct codec sent to fs, but it times out again. http://www.nabble.com/file/p21911561/correct_codec_with_cancel.txt correct_codec_with_cancel.txt
Ankit Gandhi wrote:
Hi Brian, But issue here is that, FS is not processing any such calls and not sending 488 to the caller. Also the sip trace I had provided was from the caller to fs. FS does not even bridge the call to terminator in between the INVITE and CANCEL from the caller. It just gives so many errors in log like following :
2009-02-09 11:31:04 [ERR] mod_g729.c:145 switch_g729_decode() This codec is only usable in passthrough mode! 2009-02-09 11:31:04 [ERR] mod_g729.c:145 switch_g729_decode() This codec is only usable in passthrough mode! 2009-02-09 11:31:04 [ERR] mod_g729.c:145 switch_g729_decode() This codec is only usable in passthrough mode! 2009-02-09 11:31:04 [ERR] mod_g729.c:145 switch_g729_decode() This codec is only usable in passthrough mode! 2009-02-09 11:31:04 [ERR] mod_g729.c:145 switch_g729_decode() This codec is only usable in passthrough mode!
It seems odd that due to codec mismatch, fs does not process the call at all and just times out and the caller sends CANCEL to us. Waiting for your reply.
Brian West-3 wrote:
I notice it offers 18 which is G729 but these listed below are 100% invalid. There is no such thing as G.729a, G.729b or G.729ab that are valid in the SDP. I suspect if you start FreeSWITCH and crank it up to debug level ("console loglevel debug") you'll clearly see why this is taking place. I think we talked to you on IRC about this and told this. If your termination gateway requires any of the above listed on 96,97 or 98 the call will fail. We can only do passthru on G729 which is the official name which is listed on payload 18. Your termination provider needs to be informed of this fact. The fmtp line is what controls annexb operation!
/b
On Feb 9, 2009, at 3:46 AM, Ankit Gandhi wrote:
a=rtpmap:97 G.729b/8000. a=rtpmap:98 G.729a/8000. a=rtpmap:96 G.729ab/8000.
_______________________________________________ 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
-- View this message in context: http://www.nabble.com/Freeswitch-not-processing-calls-tp21909687p21911561.ht... Sent from the Freeswitch-users mailing list archive at Nabble.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
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400
participants (3)
-
Ankit Gandhi
-
Anthony Minessale
-
Brian West