this trace is useless without this command from the cli to capture xmpp dl_debug on The behavior is not stable or unstable in terms of behavior, dozens of people got it working in under 10 minutes you simply have to review your setup and find the problem in your config or network topology. On Mon, Sep 20, 2010 at 8:49 PM, Oleg Khovayko <khovayko@gmail.com> wrote:
Hi All,
I understand, mod_dingaling on 32-bit machine can works unstable, but on the my machine this behaviour stable repeating.
My build from ~Sep, 15.
I think, need to continue debug mod_dingaling.
This is explanation of behaviour:
1. If I oroginate call through GV, and recepient pick up handset, everything OK, conversation goes, etc.
2. But, problem in the following scenario:
- I call from FS by GV to PSTN - PSTN phone start calling - I cancel call on orogonator's side * - rcpt phone continue calling! * - when I pick up handset on rcpt side, hear nothing.
Please, see log in there:
http://olegh.ath.cx/fs/dingaling.txt
I noticed, when I cancel call on orogonator's side, mod_dingaling prints correct log values, like:
2010-09-20 21:29:09.925255 [DEBUG] mod_dingaling.c:1342 dingaling/xmppc/+12404760839@voice.google.com CHANNEL KILL 2010-09-20 21:29:09.925255 [DEBUG] switch_core_session.c:1210 Session 13 (dingaling/xmppc/+12404760839@voice.google.com) Locked, Waiting on external entities 2010-09-20 21:29:09.925255 [NOTICE] switch_core_session.c:1228 Session 13 (dingaling/xmppc/+12404760839@voice.google.com) Ended
You see, session 13 Ended.
But, RCPT phone continue calling!
When I pick up RCPT-handset, I see log messages:
2010-09-20 21:29:16.442028 [DEBUG] mod_dingaling.c:1002 Send Candidate 173.79.240.220:24818 [zkNRjTp5rkWS9Kim] 2010-09-20 21:29:16.442028 [DEBUG] mod_dingaling.c:3067 Creating an identity for 0872291417 Google Voice<+12404760839> 12027139373 2010-09-20 21:29:16.442028 [NOTICE] switch_channel.c:779 New Channel dingaling/12027139373 [cca305a6-1fc5-df11-9af2-005004c3cb7e]
Looks like mod_dingaling continue work on canceled call, despite on "session 13 Ended".
And, at the end (after pick up handset on recepient side), I see: 2010-09-20 21:29:16.622104 [DEBUG] switch_core_session.c:1210 Session 14 (DingaLing/new) Locked, Waiting on external entities 2010-09-20 21:29:16.622104 [NOTICE] switch_core_session.c:1228 Session 14 (DingaLing/new) Ended 2010-09-20 21:29:16.622104 [NOTICE] switch_core_session.c:1230 Close Channel DingaLing/new [CS_DESTROY]
I assume, mod_dingaling generates 2 sessions per phone call, and destroy only one, when originator drops handset...
Interesting, is this behaviour repeatable on another OS/builds?
Oleg
_______________________________________________ FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900