Try trunk again
On Wed, Dec 2, 2009 at 5:33 PM, Anthony Minessale
anthony.miness...@gmail.com wrote:
I am not sure what you are sending over the socket but you have a queued
hangup being processed on line 640 of your pastebin
are you executing any commands with a ! character in it by any
Tony,
The call no longer hangs up but we still only get hold music in one
direction - if the callee places the caller on hold there is no music.
PB here:
http://pastebin.freeswitch.org/11378
This was on rev 15773.
Thanks again Tony!
On Thu, Dec 3, 2009 at 10:56 AM, Anthony Minessale
As always, you are correct.
The scenario now is:
- If the caller places the callee on hold, the callee will get hold music
- If the callee places the caller on hold, the caller will not get hold music
I've uploaded a fresh pastebin here:
http://pastebin.freeswitch.org/11356
On Fri, Nov 20,
I decided to just change the code so its more elegant to handle recursive
broadcasting so you can try again and see if that helps.
On Wed, Dec 2, 2009 at 10:35 AM, Kristian Kielhofner
kristian.kielhof...@gmail.com wrote:
As always, you are correct.
The scenario now is:
- If the caller
Tony,
Thanks for that but now it appears that the call just gets hung up
on when the caller takes the callee off hold. Debug here:
http://pastebin.freeswitch.org/11359
Thanks again!
On Wed, Dec 2, 2009 at 1:13 PM, Anthony Minessale
anthony.miness...@gmail.com wrote:
I decided to just
I am not sure what you are sending over the socket but you have a queued
hangup being processed on line 640 of your pastebin
are you executing any commands with a ! character in it by any chance or
executing the hangup app on purpose?
On Wed, Dec 2, 2009 at 2:16 PM, Kristian Kielhofner
Finally got a chance to test this, the results are the same.
Why am I getting this? Is it because I'm executing ring_ready before
I attempt the bridge? Is it because I'm using a socket?
On Wed, Nov 11, 2009 at 10:14 PM, Anthony Minessale
anthony.miness...@gmail.com wrote:
dont execute bridge
Full log and trace here:
http://pastebin.freeswitch.org/11062
Pretty standard situation. User calls another user (same profile) and
tries to place the call on hold (RFC 3264/sendonly). FS places call
on hold and tries to start music but ends with:
[local_stream://moh] already
From the trace:
#
2009-11-11 11:23:58.909804 [DEBUG] switch_ivr.c:540
sofia/pjsip/nob...@192.168.4.192 Command Execute
set(sip_h_X-voalte-call-id=9a072f8e-06cd-48e2-b7bd-2b2b8babb3ec)
#
EXECUTE sofia/pjsip/nob...@192.168.4.192
set(sip_h_X-voalte-call-id=9a072f8e-06cd-48e2-b7bd-2b2b8babb3ec)
#
Also forgot to mention - this is trunk rev 15428 on CentOS 5 x86_64.
On Wed, Nov 11, 2009 at 5:20 PM, Kristian Kielhofner
kristian.kielhof...@gmail.com wrote:
From the trace:
..snip..
--
Kristian Kielhofner
http://www.astlinux.org
http://blog.krisk.org
http://www.star2star.com
dont execute bridge that way, your bridge itself is the other thing already
broadcasting.
api uuid_transfer uuid of chan bridge:sofia/myprofile/f...@bar.com inline
if you want to do more after the bridge
set the variable park_after_bridge=true to make it go back to idle
On Wed, Nov 11, 2009
11 matches
Mail list logo
