I've been battling while creating an IVR using FreeSWITCH mod_managed and connecting through a CISCO 2811. Most things now work quite well, but I am having a few issues with the way the system answers calls (or doesn't answer calls...). I have FreeSWITCH running as a windows service on Windows Server 2008, which is connected via LAN to a CISCO 2811 with a 4 port FXO card, which is then connected to a POTS phone line. Take the following scenario: 1. Managed .NET application creates a call string and uses ESL to talk to freeswitch and originate a call: string callstring = "{bridge_answer_timeout=20,ignore_early_media=true,call_timeout=20}sofia/internal/1091234567@192.168.x.x '&managed(ivrAppName)'"; eslConnection.API("originate", callstring); where 192.168.x.x is the CISCO IP. 2. The CISCO sees that the phone number (1091234567) starts with a 1 so it uses FXO port 1 and strips the 1 and uses the remaining phone number (091234567) to make the call. 3. My phone rings, I pick up and I can hear my IVR playing. These are my current problems: - IVR starts playing before I even pick up the phone. This means that if the system calls a mobile phone and the person doesn't pick up, the IVR will start playing and eventually the mobile phone will divert to voice mail. Obviously I then get a missed call and an sms saying I have a new voice mail, which is annoying. Instead I would like it to KNOW that no one has picked up, but I don't know how to do this. Somehow the CISCO needs to be able to tell FreeSWITCH that the call has not yet been answered. For some reason however as soon as the CISCO starts calling FreeSWITCH thinks the call is already connected. It doesn't know that the CISCO is actually still ringing. Maybe I'm doing originate the wrong way or something ... - The phone only rings for about 10 seconds before hanging up. I've tried "call_timeout", "bridge_answer_timeout". I've also tried setting CISCO "ring number". Nothing works, my phone still only rings for about 10 seconds. I don't know if this is a FreeSWITCH issue or a CISCO issue. I'm leaning towards CISCO, because FreeSWITCH IVR just starts playing even if no one answers the phone. CISCO Config for relevant FXO port: voice service voip allow-connections h323 to h323 allow-connections h323 to sip allow-connections sip to h323 allow-connections sip to sip no supplementary-service h450.2 no supplementary-service h450.3 supplementary-service h450.12 no supplementary-service sip moved-temporarily no supplementary-service sip refer fax protocol cisco sip registrar server expires max 3600 min 3600 no update-callerid no call service stop voice-port 0/3/2 output attenuation -3 no comfort-noise cptone AU impedance complex1 caller-id enable ! dial-peer voice 100 pots preference 1 destination-pattern 1T port 0/3/2 ! Many Thanks, Oliver
*bump* So I think maybe the way I'm doing the originate is the problem? In my call string I'm creating a connection directly from the CISCO (192.168.x.x) to the managed application, which may be why it starts playing straight away? Maybe I should be originating a call first and then only once I know the other side has picked up will I bridge the call to the IVR managed application. Problem is I dunno how to tell whether the other person has picked up (or even if the cisco is going to tell me) and I don't know how to do things to a call once it has been established. I'm currently reading the Dialplan wiki page, hoping to get something out of it there. Cheers Oliver On Tue, Jan 3, 2012 at 11:46 AM, Oliver Schenk <olimonkey@gmail.com> wrote:
I've been battling while creating an IVR using FreeSWITCH mod_managed and connecting through a CISCO 2811. Most things now work quite well, but I am having a few issues with the way the system answers calls (or doesn't answer calls...).
I have FreeSWITCH running as a windows service on Windows Server 2008, which is connected via LAN to a CISCO 2811 with a 4 port FXO card, which is then connected to a POTS phone line.
Take the following scenario:
1. Managed .NET application creates a call string and uses ESL to talk to freeswitch and originate a call:
string callstring = "{bridge_answer_timeout=20,ignore_early_media=true,call_timeout=20}sofia/internal/1091234567@192.168.x.x '&managed(ivrAppName)'"; eslConnection.API("originate", callstring);
where 192.168.x.x is the CISCO IP.
2. The CISCO sees that the phone number (1091234567) starts with a 1 so it uses FXO port 1 and strips the 1 and uses the remaining phone number (091234567) to make the call.
3. My phone rings, I pick up and I can hear my IVR playing.
These are my current problems:
- IVR starts playing before I even pick up the phone. This means that if the system calls a mobile phone and the person doesn't pick up, the IVR will start playing and eventually the mobile phone will divert to voice mail. Obviously I then get a missed call and an sms saying I have a new voice mail, which is annoying. Instead I would like it to KNOW that no one has picked up, but I don't know how to do this. Somehow the CISCO needs to be able to tell FreeSWITCH that the call has not yet been answered. For some reason however as soon as the CISCO starts calling FreeSWITCH thinks the call is already connected. It doesn't know that the CISCO is actually still ringing. Maybe I'm doing originate the wrong way or something ...
- The phone only rings for about 10 seconds before hanging up. I've tried "call_timeout", "bridge_answer_timeout". I've also tried setting CISCO "ring number". Nothing works, my phone still only rings for about 10 seconds. I don't know if this is a FreeSWITCH issue or a CISCO issue. I'm leaning towards CISCO, because FreeSWITCH IVR just starts playing even if no one answers the phone.
CISCO Config for relevant FXO port:
voice service voip allow-connections h323 to h323 allow-connections h323 to sip allow-connections sip to h323 allow-connections sip to sip no supplementary-service h450.2 no supplementary-service h450.3 supplementary-service h450.12 no supplementary-service sip moved-temporarily no supplementary-service sip refer fax protocol cisco sip registrar server expires max 3600 min 3600 no update-callerid no call service stop
voice-port 0/3/2 output attenuation -3 no comfort-noise cptone AU impedance complex1 caller-id enable ! dial-peer voice 100 pots preference 1 destination-pattern 1T port 0/3/2 !
Many Thanks,
Oliver
Also, maybe I should be doing something like this: sofia/gateway/mygatewayname/1091234567 '&managed(ivrAppName)' instead of: sofia/internal/1091234567@192.168.x.x '&managed(ivrAppName)' but, I don't really have the CISCO configured as a gateway, nor do I know how really...probably not on the right track there. On Thu, Jan 5, 2012 at 3:06 PM, Oliver Schenk <olimonkey@gmail.com> wrote:
*bump*
So I think maybe the way I'm doing the originate is the problem? In my call string I'm creating a connection directly from the CISCO (192.168.x.x) to the managed application, which may be why it starts playing straight away?
Maybe I should be originating a call first and then only once I know the other side has picked up will I bridge the call to the IVR managed application.
Problem is I dunno how to tell whether the other person has picked up (or even if the cisco is going to tell me) and I don't know how to do things to a call once it has been established.
I'm currently reading the Dialplan wiki page, hoping to get something out of it there.
Cheers
Oliver
On Tue, Jan 3, 2012 at 11:46 AM, Oliver Schenk <olimonkey@gmail.com> wrote:
I've been battling while creating an IVR using FreeSWITCH mod_managed and connecting through a CISCO 2811. Most things now work quite well, but I am having a few issues with the way the system answers calls (or doesn't answer calls...).
I have FreeSWITCH running as a windows service on Windows Server 2008, which is connected via LAN to a CISCO 2811 with a 4 port FXO card, which is then connected to a POTS phone line.
Take the following scenario:
1. Managed .NET application creates a call string and uses ESL to talk to freeswitch and originate a call:
string callstring = "{bridge_answer_timeout=20,ignore_early_media=true,call_timeout=20}sofia/internal/1091234567@192.168.x.x '&managed(ivrAppName)'"; eslConnection.API("originate", callstring);
where 192.168.x.x is the CISCO IP.
2. The CISCO sees that the phone number (1091234567) starts with a 1 so it uses FXO port 1 and strips the 1 and uses the remaining phone number (091234567) to make the call.
3. My phone rings, I pick up and I can hear my IVR playing.
These are my current problems:
- IVR starts playing before I even pick up the phone. This means that if the system calls a mobile phone and the person doesn't pick up, the IVR will start playing and eventually the mobile phone will divert to voice mail. Obviously I then get a missed call and an sms saying I have a new voice mail, which is annoying. Instead I would like it to KNOW that no one has picked up, but I don't know how to do this. Somehow the CISCO needs to be able to tell FreeSWITCH that the call has not yet been answered. For some reason however as soon as the CISCO starts calling FreeSWITCH thinks the call is already connected. It doesn't know that the CISCO is actually still ringing. Maybe I'm doing originate the wrong way or something ...
- The phone only rings for about 10 seconds before hanging up. I've tried "call_timeout", "bridge_answer_timeout". I've also tried setting CISCO "ring number". Nothing works, my phone still only rings for about 10 seconds. I don't know if this is a FreeSWITCH issue or a CISCO issue. I'm leaning towards CISCO, because FreeSWITCH IVR just starts playing even if no one answers the phone.
CISCO Config for relevant FXO port:
voice service voip allow-connections h323 to h323 allow-connections h323 to sip allow-connections sip to h323 allow-connections sip to sip no supplementary-service h450.2 no supplementary-service h450.3 supplementary-service h450.12 no supplementary-service sip moved-temporarily no supplementary-service sip refer fax protocol cisco sip registrar server expires max 3600 min 3600 no update-callerid no call service stop
voice-port 0/3/2 output attenuation -3 no comfort-noise cptone AU impedance complex1 caller-id enable ! dial-peer voice 100 pots preference 1 destination-pattern 1T port 0/3/2 !
Many Thanks,
Oliver
I think I've a similar problem related to callcenter app. When I made an originate like this: originate loopback/2500/default/XML &bridge(user/2001) 2500 is an extension that leads to a callcenter application. In this case, we dial first to the queue and when an agent answered we call to the customer. As far as I know When the A-leg reaches to the queue, without selecting an agent, the call is automatically sent to the B-leg. As far as I see, there is a pre-answer method that fs needs to send the media to A-leg. In order to try to avoid this, I tried using ignore_early_media=true as part of the originate in A-leg and/or B-leg, with no luck. originate {ignore_early_media=true}loopback/2500/default/XML &bridge({ignore_early_media=true}user/2001) Dialplan: loopback/2500-b Regex (PASS) [CallCenter_Click2Call] destination_number(2500) =~ /^(2500)$/ break=on-false Dialplan: loopback/2500-b Action set(ignore_early_media=true) Dialplan: loopback/2500-b Action callcenter(click2call) 2012-01-05 13:36:08.541517 [DEBUG] switch_core_state_machine.c:154 (loopback/2500-b) State Change CS_ROUTING -> CS_EXECUTE 2012-01-05 13:36:08.541517 [DEBUG] switch_core_session.c:1180 Send signal loopback/2500-b [BREAK] 2012-01-05 13:36:08.541517 [DEBUG] mod_loopback.c:475 loopback/2500-b CHANNEL KILL 2012-01-05 13:36:08.541517 [DEBUG] switch_core_state_machine.c:410 (loopback/2500-b) State ROUTING going to sleep 2012-01-05 13:36:08.541517 [DEBUG] switch_core_state_machine.c:362 (loopback/2500-b) Running State Change CS_EXECUTE 2012-01-05 13:36:08.541517 [DEBUG] switch_core_state_machine.c:417 (loopback/2500-b) State EXECUTE 2012-01-05 13:36:08.541517 [DEBUG] mod_loopback.c:375 loopback/2500-b CHANNEL EXECUTE 2012-01-05 13:36:08.541517 [DEBUG] switch_core_state_machine.c:192 loopback/2500-b Standard EXECUTE EXECUTE loopback/2500-b set(open=true) 2012-01-05 13:36:08.541517 [DEBUG] mod_dptools.c:1286 loopback/2500-b SET [open]=[true] EXECUTE loopback/2500-b hash(insert/10.8.0.70-spymap/0000000000/fef7d864-b3c7-407c-a6e1-94386642bfbb) EXECUTE loopback/2500-b hash(insert/10.8.0.70-last_dial/0000000000/2500) EXECUTE loopback/2500-b hash(insert/10.8.0.70-last_dial/global/fef7d864-b3c7-407c-a6e1-94386642bfbb) EXECUTE loopback/2500-b set(RFC2822_DATE=Thu, 05 Jan 2012 13:36:08 -0300) 2012-01-05 13:36:08.541517 [DEBUG] mod_dptools.c:1286 loopback/2500-b SET [RFC2822_DATE]=[Thu, 05 Jan 2012 13:36:08 -0300] EXECUTE loopback/2500-b set(ignore_early_media=true) 2012-01-05 13:36:08.541517 [DEBUG] mod_dptools.c:1286 loopback/2500-b SET [ignore_early_media]=[true] 2012-01-05 13:36:08.541517 [DEBUG] switch_core_session.c:2133 Application callcenter Requires media! pre_answering channel loopback/2500-b 2012-01-05 13:36:08.541517 [NOTICE] mod_loopback.c:760 Pre-Answer loopback/2500-a! 2012-01-05 13:36:08.541517 [DEBUG] switch_channel.c:2930 (loopback/2500-a) Callstate Change RINGING -> EARLY 2012-01-05 13:36:08.541517 [DEBUG] switch_core_session.c:729 Send signal loopback/2500-b [BREAK] 2012-01-05 13:36:08.541517 [DEBUG] mod_loopback.c:475 loopback/2500-b CHANNEL KILL 2012-01-05 13:36:08.541517 [NOTICE] switch_core_session.c:2135 Pre-Answer loopback/2500-b! 2012-01-05 13:36:08.541517 [DEBUG] switch_channel.c:2930 (loopback/2500-b) Callstate Change RINGING -> EARLY EXECUTE loopback/2500-b callcenter(click2call) 2012-01-05 13:36:08.541517 [DEBUG] switch_channel.c:3188 (loopback/2500-a) Callstate Change EARLY -> ACTIVE 2012-01-05 13:36:08.541517 [NOTICE] mod_loopback.c:755 Channel [loopback/2500-a] has been answered 2012-01-05 13:36:08.541517 [DEBUG] switch_core_session.c:729 Send signal loopback/2500-b [BREAK] 2012-01-05 13:36:08.541517 [DEBUG] mod_loopback.c:475 loopback/2500-b CHANNEL KILL 2012-01-05 13:36:08.541517 [DEBUG] switch_ivr_originate.c:3266 Originate Resulted in Success: [loopback/2500-a] 2012-01-05 13:36:08.541517 [DEBUG] switch_channel.c:3188 (loopback/2500-b) Callstate Change EARLY -> ACTIVE 2012-01-05 13:36:08.541517 [INFO] switch_channel.c:2708 loopback/2500-a Flipping CID from "" <0000000000> to "Outbound Call" <XML> On Jan 5, 2012, at 4:17 AM, Oliver Schenk wrote:
Also, maybe I should be doing something like this:
sofia/gateway/mygatewayname/1091234567 '&managed(ivrAppName)'
instead of:
sofia/internal/1091234567@192.168.x.x '&managed(ivrAppName)'
but, I don't really have the CISCO configured as a gateway, nor do I know how really...probably not on the right track there.
On Thu, Jan 5, 2012 at 3:06 PM, Oliver Schenk <olimonkey@gmail.com> wrote:
*bump*
So I think maybe the way I'm doing the originate is the problem? In my call string I'm creating a connection directly from the CISCO (192.168.x.x) to the managed application, which may be why it starts playing straight away?
Maybe I should be originating a call first and then only once I know the other side has picked up will I bridge the call to the IVR managed application.
Problem is I dunno how to tell whether the other person has picked up (or even if the cisco is going to tell me) and I don't know how to do things to a call once it has been established.
I'm currently reading the Dialplan wiki page, hoping to get something out of it there.
Cheers
Oliver
On Tue, Jan 3, 2012 at 11:46 AM, Oliver Schenk <olimonkey@gmail.com> wrote:
I've been battling while creating an IVR using FreeSWITCH mod_managed and connecting through a CISCO 2811. Most things now work quite well, but I am having a few issues with the way the system answers calls (or doesn't answer calls...).
I have FreeSWITCH running as a windows service on Windows Server 2008, which is connected via LAN to a CISCO 2811 with a 4 port FXO card, which is then connected to a POTS phone line.
Take the following scenario:
1. Managed .NET application creates a call string and uses ESL to talk to freeswitch and originate a call:
string callstring = "{bridge_answer_timeout=20,ignore_early_media=true,call_timeout=20}sofia/internal/1091234567@192.168.x.x '&managed(ivrAppName)'"; eslConnection.API("originate", callstring);
where 192.168.x.x is the CISCO IP.
2. The CISCO sees that the phone number (1091234567) starts with a 1 so it uses FXO port 1 and strips the 1 and uses the remaining phone number (091234567) to make the call.
3. My phone rings, I pick up and I can hear my IVR playing.
These are my current problems:
- IVR starts playing before I even pick up the phone. This means that if the system calls a mobile phone and the person doesn't pick up, the IVR will start playing and eventually the mobile phone will divert to voice mail. Obviously I then get a missed call and an sms saying I have a new voice mail, which is annoying. Instead I would like it to KNOW that no one has picked up, but I don't know how to do this. Somehow the CISCO needs to be able to tell FreeSWITCH that the call has not yet been answered. For some reason however as soon as the CISCO starts calling FreeSWITCH thinks the call is already connected. It doesn't know that the CISCO is actually still ringing. Maybe I'm doing originate the wrong way or something ...
- The phone only rings for about 10 seconds before hanging up. I've tried "call_timeout", "bridge_answer_timeout". I've also tried setting CISCO "ring number". Nothing works, my phone still only rings for about 10 seconds. I don't know if this is a FreeSWITCH issue or a CISCO issue. I'm leaning towards CISCO, because FreeSWITCH IVR just starts playing even if no one answers the phone.
CISCO Config for relevant FXO port:
voice service voip allow-connections h323 to h323 allow-connections h323 to sip allow-connections sip to h323 allow-connections sip to sip no supplementary-service h450.2 no supplementary-service h450.3 supplementary-service h450.12 no supplementary-service sip moved-temporarily no supplementary-service sip refer fax protocol cisco sip registrar server expires max 3600 min 3600 no update-callerid no call service stop
voice-port 0/3/2 output attenuation -3 no comfort-noise cptone AU impedance complex1 caller-id enable ! dial-peer voice 100 pots preference 1 destination-pattern 1T port 0/3/2 !
Many Thanks,
Oliver
_________________________________________________________________________ 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
Thanks for the help so far. Here is a pastebin of FreeSWITCH output: http://pastebin.com/i6Qgc7ws Notice how the "has been answered" log message comes immediately (within a few milliseconds) after the call was originated. I think this would suggest that the CISCO is immediately sending a 200 OK, as you suggested. I also turned on CISCO debugging, but I'm just trying to figure out how to get the information regarding SIP messages back to Freeswitch. I'll run the test again and see if I can get some useful CISCO debug. Which "debug ccsip" commands are relevant to what I want for the CISCO SIP debugging? Thanks! 2012/1/6 Gustavo Mársico <gustavomarsico@gmail.com>:
I think I've a similar problem related to callcenter app. When I made an originate like this:
originate loopback/2500/default/XML &bridge(user/2001)
2500 is an extension that leads to a callcenter application. In this case, we dial first to the queue and when an agent answered we call to the customer. As far as I know When the A-leg reaches to the queue, without selecting an agent, the call is automatically sent to the B-leg. As far as I see, there is a pre-answer method that fs needs to send the media to A-leg. In order to try to avoid this, I tried using ignore_early_media=true as part of the originate in A-leg and/or B-leg, with no luck.
originate {ignore_early_media=true}loopback/2500/default/XML &bridge({ignore_early_media=true}user/2001)
Dialplan: loopback/2500-b Regex (PASS) [CallCenter_Click2Call] destination_number(2500) =~ /^(2500)$/ break=on-false Dialplan: loopback/2500-b Action set(ignore_early_media=true) Dialplan: loopback/2500-b Action callcenter(click2call) 2012-01-05 13:36:08.541517 [DEBUG] switch_core_state_machine.c:154 (loopback/2500-b) State Change CS_ROUTING -> CS_EXECUTE 2012-01-05 13:36:08.541517 [DEBUG] switch_core_session.c:1180 Send signal loopback/2500-b [BREAK] 2012-01-05 13:36:08.541517 [DEBUG] mod_loopback.c:475 loopback/2500-b CHANNEL KILL 2012-01-05 13:36:08.541517 [DEBUG] switch_core_state_machine.c:410 (loopback/2500-b) State ROUTING going to sleep 2012-01-05 13:36:08.541517 [DEBUG] switch_core_state_machine.c:362 (loopback/2500-b) Running State Change CS_EXECUTE 2012-01-05 13:36:08.541517 [DEBUG] switch_core_state_machine.c:417 (loopback/2500-b) State EXECUTE 2012-01-05 13:36:08.541517 [DEBUG] mod_loopback.c:375 loopback/2500-b CHANNEL EXECUTE 2012-01-05 13:36:08.541517 [DEBUG] switch_core_state_machine.c:192 loopback/2500-b Standard EXECUTE EXECUTE loopback/2500-b set(open=true) 2012-01-05 13:36:08.541517 [DEBUG] mod_dptools.c:1286 loopback/2500-b SET [open]=[true] EXECUTE loopback/2500-b hash(insert/10.8.0.70-spymap/0000000000/fef7d864-b3c7-407c-a6e1-94386642bfbb) EXECUTE loopback/2500-b hash(insert/10.8.0.70-last_dial/0000000000/2500) EXECUTE loopback/2500-b hash(insert/10.8.0.70-last_dial/global/fef7d864-b3c7-407c-a6e1-94386642bfbb) EXECUTE loopback/2500-b set(RFC2822_DATE=Thu, 05 Jan 2012 13:36:08 -0300) 2012-01-05 13:36:08.541517 [DEBUG] mod_dptools.c:1286 loopback/2500-b SET [RFC2822_DATE]=[Thu, 05 Jan 2012 13:36:08 -0300] EXECUTE loopback/2500-b set(ignore_early_media=true) 2012-01-05 13:36:08.541517 [DEBUG] mod_dptools.c:1286 loopback/2500-b SET [ignore_early_media]=[true] 2012-01-05 13:36:08.541517 [DEBUG] switch_core_session.c:2133 Application callcenter Requires media! pre_answering channel loopback/2500-b 2012-01-05 13:36:08.541517 [NOTICE] mod_loopback.c:760 Pre-Answer loopback/2500-a! 2012-01-05 13:36:08.541517 [DEBUG] switch_channel.c:2930 (loopback/2500-a) Callstate Change RINGING -> EARLY 2012-01-05 13:36:08.541517 [DEBUG] switch_core_session.c:729 Send signal loopback/2500-b [BREAK] 2012-01-05 13:36:08.541517 [DEBUG] mod_loopback.c:475 loopback/2500-b CHANNEL KILL 2012-01-05 13:36:08.541517 [NOTICE] switch_core_session.c:2135 Pre-Answer loopback/2500-b! 2012-01-05 13:36:08.541517 [DEBUG] switch_channel.c:2930 (loopback/2500-b) Callstate Change RINGING -> EARLY EXECUTE loopback/2500-b callcenter(click2call) 2012-01-05 13:36:08.541517 [DEBUG] switch_channel.c:3188 (loopback/2500-a) Callstate Change EARLY -> ACTIVE 2012-01-05 13:36:08.541517 [NOTICE] mod_loopback.c:755 Channel [loopback/2500-a] has been answered 2012-01-05 13:36:08.541517 [DEBUG] switch_core_session.c:729 Send signal loopback/2500-b [BREAK] 2012-01-05 13:36:08.541517 [DEBUG] mod_loopback.c:475 loopback/2500-b CHANNEL KILL 2012-01-05 13:36:08.541517 [DEBUG] switch_ivr_originate.c:3266 Originate Resulted in Success: [loopback/2500-a] 2012-01-05 13:36:08.541517 [DEBUG] switch_channel.c:3188 (loopback/2500-b) Callstate Change EARLY -> ACTIVE 2012-01-05 13:36:08.541517 [INFO] switch_channel.c:2708 loopback/2500-a Flipping CID from "" <0000000000> to "Outbound Call" <XML>
On Jan 5, 2012, at 4:17 AM, Oliver Schenk wrote:
Also, maybe I should be doing something like this:
sofia/gateway/mygatewayname/1091234567 '&managed(ivrAppName)'
instead of:
sofia/internal/1091234567@192.168.x.x '&managed(ivrAppName)'
but, I don't really have the CISCO configured as a gateway, nor do I know how really...probably not on the right track there.
On Thu, Jan 5, 2012 at 3:06 PM, Oliver Schenk <olimonkey@gmail.com> wrote:
*bump*
So I think maybe the way I'm doing the originate is the problem? In my call string I'm creating a connection directly from the CISCO (192.168.x.x) to the managed application, which may be why it starts playing straight away?
Maybe I should be originating a call first and then only once I know the other side has picked up will I bridge the call to the IVR managed application.
Problem is I dunno how to tell whether the other person has picked up (or even if the cisco is going to tell me) and I don't know how to do things to a call once it has been established.
I'm currently reading the Dialplan wiki page, hoping to get something out of it there.
Cheers
Oliver
On Tue, Jan 3, 2012 at 11:46 AM, Oliver Schenk <olimonkey@gmail.com> wrote:
I've been battling while creating an IVR using FreeSWITCH mod_managed and connecting through a CISCO 2811. Most things now work quite well, but I am having a few issues with the way the system answers calls (or doesn't answer calls...).
I have FreeSWITCH running as a windows service on Windows Server 2008, which is connected via LAN to a CISCO 2811 with a 4 port FXO card, which is then connected to a POTS phone line.
Take the following scenario:
1. Managed .NET application creates a call string and uses ESL to talk to freeswitch and originate a call:
string callstring = "{bridge_answer_timeout=20,ignore_early_media=true,call_timeout=20}sofia/internal/1091234567@192.168.x.x '&managed(ivrAppName)'"; eslConnection.API("originate", callstring);
where 192.168.x.x is the CISCO IP.
2. The CISCO sees that the phone number (1091234567) starts with a 1 so it uses FXO port 1 and strips the 1 and uses the remaining phone number (091234567) to make the call.
3. My phone rings, I pick up and I can hear my IVR playing.
These are my current problems:
- IVR starts playing before I even pick up the phone. This means that if the system calls a mobile phone and the person doesn't pick up, the IVR will start playing and eventually the mobile phone will divert to voice mail. Obviously I then get a missed call and an sms saying I have a new voice mail, which is annoying. Instead I would like it to KNOW that no one has picked up, but I don't know how to do this. Somehow the CISCO needs to be able to tell FreeSWITCH that the call has not yet been answered. For some reason however as soon as the CISCO starts calling FreeSWITCH thinks the call is already connected. It doesn't know that the CISCO is actually still ringing. Maybe I'm doing originate the wrong way or something ...
- The phone only rings for about 10 seconds before hanging up. I've tried "call_timeout", "bridge_answer_timeout". I've also tried setting CISCO "ring number". Nothing works, my phone still only rings for about 10 seconds. I don't know if this is a FreeSWITCH issue or a CISCO issue. I'm leaning towards CISCO, because FreeSWITCH IVR just starts playing even if no one answers the phone.
CISCO Config for relevant FXO port:
voice service voip allow-connections h323 to h323 allow-connections h323 to sip allow-connections sip to h323 allow-connections sip to sip no supplementary-service h450.2 no supplementary-service h450.3 supplementary-service h450.12 no supplementary-service sip moved-temporarily no supplementary-service sip refer fax protocol cisco sip registrar server expires max 3600 min 3600 no update-callerid no call service stop
voice-port 0/3/2 output attenuation -3 no comfort-noise cptone AU impedance complex1 caller-id enable ! dial-peer voice 100 pots preference 1 destination-pattern 1T port 0/3/2 !
Many Thanks,
Oliver
_________________________________________________________________________ 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
By the way: I tried {ignore_early_media=true} as well, but as I think we determined, my problem is probably with the CISCO telling FS that the call has been answered when really it hasn't yet. On Fri, Jan 6, 2012 at 8:01 AM, Oliver Schenk <olimonkey@gmail.com> wrote:
Thanks for the help so far.
Here is a pastebin of FreeSWITCH output: http://pastebin.com/i6Qgc7ws
Notice how the "has been answered" log message comes immediately (within a few milliseconds) after the call was originated. I think this would suggest that the CISCO is immediately sending a 200 OK, as you suggested. I also turned on CISCO debugging, but I'm just trying to figure out how to get the information regarding SIP messages back to Freeswitch. I'll run the test again and see if I can get some useful CISCO debug.
Which "debug ccsip" commands are relevant to what I want for the CISCO SIP debugging?
Thanks!
2012/1/6 Gustavo Mársico <gustavomarsico@gmail.com>:
I think I've a similar problem related to callcenter app. When I made an originate like this:
originate loopback/2500/default/XML &bridge(user/2001)
2500 is an extension that leads to a callcenter application. In this case, we dial first to the queue and when an agent answered we call to the customer. As far as I know When the A-leg reaches to the queue, without selecting an agent, the call is automatically sent to the B-leg. As far as I see, there is a pre-answer method that fs needs to send the media to A-leg. In order to try to avoid this, I tried using ignore_early_media=true as part of the originate in A-leg and/or B-leg, with no luck.
originate {ignore_early_media=true}loopback/2500/default/XML &bridge({ignore_early_media=true}user/2001)
Dialplan: loopback/2500-b Regex (PASS) [CallCenter_Click2Call] destination_number(2500) =~ /^(2500)$/ break=on-false Dialplan: loopback/2500-b Action set(ignore_early_media=true) Dialplan: loopback/2500-b Action callcenter(click2call) 2012-01-05 13:36:08.541517 [DEBUG] switch_core_state_machine.c:154 (loopback/2500-b) State Change CS_ROUTING -> CS_EXECUTE 2012-01-05 13:36:08.541517 [DEBUG] switch_core_session.c:1180 Send signal loopback/2500-b [BREAK] 2012-01-05 13:36:08.541517 [DEBUG] mod_loopback.c:475 loopback/2500-b CHANNEL KILL 2012-01-05 13:36:08.541517 [DEBUG] switch_core_state_machine.c:410 (loopback/2500-b) State ROUTING going to sleep 2012-01-05 13:36:08.541517 [DEBUG] switch_core_state_machine.c:362 (loopback/2500-b) Running State Change CS_EXECUTE 2012-01-05 13:36:08.541517 [DEBUG] switch_core_state_machine.c:417 (loopback/2500-b) State EXECUTE 2012-01-05 13:36:08.541517 [DEBUG] mod_loopback.c:375 loopback/2500-b CHANNEL EXECUTE 2012-01-05 13:36:08.541517 [DEBUG] switch_core_state_machine.c:192 loopback/2500-b Standard EXECUTE EXECUTE loopback/2500-b set(open=true) 2012-01-05 13:36:08.541517 [DEBUG] mod_dptools.c:1286 loopback/2500-b SET [open]=[true] EXECUTE loopback/2500-b hash(insert/10.8.0.70-spymap/0000000000/fef7d864-b3c7-407c-a6e1-94386642bfbb) EXECUTE loopback/2500-b hash(insert/10.8.0.70-last_dial/0000000000/2500) EXECUTE loopback/2500-b hash(insert/10.8.0.70-last_dial/global/fef7d864-b3c7-407c-a6e1-94386642bfbb) EXECUTE loopback/2500-b set(RFC2822_DATE=Thu, 05 Jan 2012 13:36:08 -0300) 2012-01-05 13:36:08.541517 [DEBUG] mod_dptools.c:1286 loopback/2500-b SET [RFC2822_DATE]=[Thu, 05 Jan 2012 13:36:08 -0300] EXECUTE loopback/2500-b set(ignore_early_media=true) 2012-01-05 13:36:08.541517 [DEBUG] mod_dptools.c:1286 loopback/2500-b SET [ignore_early_media]=[true] 2012-01-05 13:36:08.541517 [DEBUG] switch_core_session.c:2133 Application callcenter Requires media! pre_answering channel loopback/2500-b 2012-01-05 13:36:08.541517 [NOTICE] mod_loopback.c:760 Pre-Answer loopback/2500-a! 2012-01-05 13:36:08.541517 [DEBUG] switch_channel.c:2930 (loopback/2500-a) Callstate Change RINGING -> EARLY 2012-01-05 13:36:08.541517 [DEBUG] switch_core_session.c:729 Send signal loopback/2500-b [BREAK] 2012-01-05 13:36:08.541517 [DEBUG] mod_loopback.c:475 loopback/2500-b CHANNEL KILL 2012-01-05 13:36:08.541517 [NOTICE] switch_core_session.c:2135 Pre-Answer loopback/2500-b! 2012-01-05 13:36:08.541517 [DEBUG] switch_channel.c:2930 (loopback/2500-b) Callstate Change RINGING -> EARLY EXECUTE loopback/2500-b callcenter(click2call) 2012-01-05 13:36:08.541517 [DEBUG] switch_channel.c:3188 (loopback/2500-a) Callstate Change EARLY -> ACTIVE 2012-01-05 13:36:08.541517 [NOTICE] mod_loopback.c:755 Channel [loopback/2500-a] has been answered 2012-01-05 13:36:08.541517 [DEBUG] switch_core_session.c:729 Send signal loopback/2500-b [BREAK] 2012-01-05 13:36:08.541517 [DEBUG] mod_loopback.c:475 loopback/2500-b CHANNEL KILL 2012-01-05 13:36:08.541517 [DEBUG] switch_ivr_originate.c:3266 Originate Resulted in Success: [loopback/2500-a] 2012-01-05 13:36:08.541517 [DEBUG] switch_channel.c:3188 (loopback/2500-b) Callstate Change EARLY -> ACTIVE 2012-01-05 13:36:08.541517 [INFO] switch_channel.c:2708 loopback/2500-a Flipping CID from "" <0000000000> to "Outbound Call" <XML>
On Jan 5, 2012, at 4:17 AM, Oliver Schenk wrote:
Also, maybe I should be doing something like this:
sofia/gateway/mygatewayname/1091234567 '&managed(ivrAppName)'
instead of:
sofia/internal/1091234567@192.168.x.x '&managed(ivrAppName)'
but, I don't really have the CISCO configured as a gateway, nor do I know how really...probably not on the right track there.
On Thu, Jan 5, 2012 at 3:06 PM, Oliver Schenk <olimonkey@gmail.com> wrote:
*bump*
So I think maybe the way I'm doing the originate is the problem? In my call string I'm creating a connection directly from the CISCO (192.168.x.x) to the managed application, which may be why it starts playing straight away?
Maybe I should be originating a call first and then only once I know the other side has picked up will I bridge the call to the IVR managed application.
Problem is I dunno how to tell whether the other person has picked up (or even if the cisco is going to tell me) and I don't know how to do things to a call once it has been established.
I'm currently reading the Dialplan wiki page, hoping to get something out of it there.
Cheers
Oliver
On Tue, Jan 3, 2012 at 11:46 AM, Oliver Schenk <olimonkey@gmail.com> wrote:
I've been battling while creating an IVR using FreeSWITCH mod_managed and connecting through a CISCO 2811. Most things now work quite well, but I am having a few issues with the way the system answers calls (or doesn't answer calls...).
I have FreeSWITCH running as a windows service on Windows Server 2008, which is connected via LAN to a CISCO 2811 with a 4 port FXO card, which is then connected to a POTS phone line.
Take the following scenario:
1. Managed .NET application creates a call string and uses ESL to talk to freeswitch and originate a call:
string callstring = "{bridge_answer_timeout=20,ignore_early_media=true,call_timeout=20}sofia/internal/1091234567@192.168.x.x '&managed(ivrAppName)'"; eslConnection.API("originate", callstring);
where 192.168.x.x is the CISCO IP.
2. The CISCO sees that the phone number (1091234567) starts with a 1 so it uses FXO port 1 and strips the 1 and uses the remaining phone number (091234567) to make the call.
3. My phone rings, I pick up and I can hear my IVR playing.
These are my current problems:
- IVR starts playing before I even pick up the phone. This means that if the system calls a mobile phone and the person doesn't pick up, the IVR will start playing and eventually the mobile phone will divert to voice mail. Obviously I then get a missed call and an sms saying I have a new voice mail, which is annoying. Instead I would like it to KNOW that no one has picked up, but I don't know how to do this. Somehow the CISCO needs to be able to tell FreeSWITCH that the call has not yet been answered. For some reason however as soon as the CISCO starts calling FreeSWITCH thinks the call is already connected. It doesn't know that the CISCO is actually still ringing. Maybe I'm doing originate the wrong way or something ...
- The phone only rings for about 10 seconds before hanging up. I've tried "call_timeout", "bridge_answer_timeout". I've also tried setting CISCO "ring number". Nothing works, my phone still only rings for about 10 seconds. I don't know if this is a FreeSWITCH issue or a CISCO issue. I'm leaning towards CISCO, because FreeSWITCH IVR just starts playing even if no one answers the phone.
CISCO Config for relevant FXO port:
voice service voip allow-connections h323 to h323 allow-connections h323 to sip allow-connections sip to h323 allow-connections sip to sip no supplementary-service h450.2 no supplementary-service h450.3 supplementary-service h450.12 no supplementary-service sip moved-temporarily no supplementary-service sip refer fax protocol cisco sip registrar server expires max 3600 min 3600 no update-callerid no call service stop
voice-port 0/3/2 output attenuation -3 no comfort-noise cptone AU impedance complex1 caller-id enable ! dial-peer voice 100 pots preference 1 destination-pattern 1T port 0/3/2 !
Many Thanks,
Oliver
_________________________________________________________________________ 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
I just noticed something else, if I don't pick up the phone at all. The IVR just keeps playing until the menu timeout kicks in. So here is a CISCO SIP log: http://pastebin.com/Y9sYkuxi The FS server is 192.168.x.50 and the CISCO is 192.168.x.1. I hope the CISCO log is readable, it's a bit long because I just did "debug ccsip all". In this test I didn't bother picking up the phone at all, but I can see that FS answered anyway and the IVR kept playing until it timed out. I'm not an expert, but here is what I picked out of it: At 00:08:10 we get a Received: "INVITE sip:109212xxxx@192.168.x.1 SIP/2.0" the further down at the same timestamp we get Sent: "SIP/2.0 100 Trying" At 00:08:13 we get a Sent: "SIP/2.0 183 Session Progress" At 00:18:13 we get a Sent: "SIP/2.0 200 OK" Then at the same timestamp we get: Received: "ACK sip:109212xxxx@192.168.x.1:5060 SIP/2.0" Once the IVR times out at 00:09:16 we get Received: "BYE sip:109212xxxx@192.168.x.1:5060 SIP/2.0" And then the reply right after Sent: "SIP/2.0 200 OK" So I think you were right, the CISCO is sending back an "OK" 3 seconds after the "INVITE" is received. The part that is beyond my field of expertise so far is WHY? Thanks, Oliver On Fri, Jan 6, 2012 at 8:04 AM, Oliver Schenk <olimonkey@gmail.com> wrote:
By the way:
I tried {ignore_early_media=true} as well, but as I think we determined, my problem is probably with the CISCO telling FS that the call has been answered when really it hasn't yet.
On Fri, Jan 6, 2012 at 8:01 AM, Oliver Schenk <olimonkey@gmail.com> wrote:
Thanks for the help so far.
Here is a pastebin of FreeSWITCH output: http://pastebin.com/i6Qgc7ws
Notice how the "has been answered" log message comes immediately (within a few milliseconds) after the call was originated. I think this would suggest that the CISCO is immediately sending a 200 OK, as you suggested. I also turned on CISCO debugging, but I'm just trying to figure out how to get the information regarding SIP messages back to Freeswitch. I'll run the test again and see if I can get some useful CISCO debug.
Which "debug ccsip" commands are relevant to what I want for the CISCO SIP debugging?
Thanks!
2012/1/6 Gustavo Mársico <gustavomarsico@gmail.com>:
I think I've a similar problem related to callcenter app. When I made an originate like this:
originate loopback/2500/default/XML &bridge(user/2001)
2500 is an extension that leads to a callcenter application. In this case, we dial first to the queue and when an agent answered we call to the customer. As far as I know When the A-leg reaches to the queue, without selecting an agent, the call is automatically sent to the B-leg. As far as I see, there is a pre-answer method that fs needs to send the media to A-leg. In order to try to avoid this, I tried using ignore_early_media=true as part of the originate in A-leg and/or B-leg, with no luck.
originate {ignore_early_media=true}loopback/2500/default/XML &bridge({ignore_early_media=true}user/2001)
Dialplan: loopback/2500-b Regex (PASS) [CallCenter_Click2Call] destination_number(2500) =~ /^(2500)$/ break=on-false Dialplan: loopback/2500-b Action set(ignore_early_media=true) Dialplan: loopback/2500-b Action callcenter(click2call) 2012-01-05 13:36:08.541517 [DEBUG] switch_core_state_machine.c:154 (loopback/2500-b) State Change CS_ROUTING -> CS_EXECUTE 2012-01-05 13:36:08.541517 [DEBUG] switch_core_session.c:1180 Send signal loopback/2500-b [BREAK] 2012-01-05 13:36:08.541517 [DEBUG] mod_loopback.c:475 loopback/2500-b CHANNEL KILL 2012-01-05 13:36:08.541517 [DEBUG] switch_core_state_machine.c:410 (loopback/2500-b) State ROUTING going to sleep 2012-01-05 13:36:08.541517 [DEBUG] switch_core_state_machine.c:362 (loopback/2500-b) Running State Change CS_EXECUTE 2012-01-05 13:36:08.541517 [DEBUG] switch_core_state_machine.c:417 (loopback/2500-b) State EXECUTE 2012-01-05 13:36:08.541517 [DEBUG] mod_loopback.c:375 loopback/2500-b CHANNEL EXECUTE 2012-01-05 13:36:08.541517 [DEBUG] switch_core_state_machine.c:192 loopback/2500-b Standard EXECUTE EXECUTE loopback/2500-b set(open=true) 2012-01-05 13:36:08.541517 [DEBUG] mod_dptools.c:1286 loopback/2500-b SET [open]=[true] EXECUTE loopback/2500-b hash(insert/10.8.0.70-spymap/0000000000/fef7d864-b3c7-407c-a6e1-94386642bfbb) EXECUTE loopback/2500-b hash(insert/10.8.0.70-last_dial/0000000000/2500) EXECUTE loopback/2500-b hash(insert/10.8.0.70-last_dial/global/fef7d864-b3c7-407c-a6e1-94386642bfbb) EXECUTE loopback/2500-b set(RFC2822_DATE=Thu, 05 Jan 2012 13:36:08 -0300) 2012-01-05 13:36:08.541517 [DEBUG] mod_dptools.c:1286 loopback/2500-b SET [RFC2822_DATE]=[Thu, 05 Jan 2012 13:36:08 -0300] EXECUTE loopback/2500-b set(ignore_early_media=true) 2012-01-05 13:36:08.541517 [DEBUG] mod_dptools.c:1286 loopback/2500-b SET [ignore_early_media]=[true] 2012-01-05 13:36:08.541517 [DEBUG] switch_core_session.c:2133 Application callcenter Requires media! pre_answering channel loopback/2500-b 2012-01-05 13:36:08.541517 [NOTICE] mod_loopback.c:760 Pre-Answer loopback/2500-a! 2012-01-05 13:36:08.541517 [DEBUG] switch_channel.c:2930 (loopback/2500-a) Callstate Change RINGING -> EARLY 2012-01-05 13:36:08.541517 [DEBUG] switch_core_session.c:729 Send signal loopback/2500-b [BREAK] 2012-01-05 13:36:08.541517 [DEBUG] mod_loopback.c:475 loopback/2500-b CHANNEL KILL 2012-01-05 13:36:08.541517 [NOTICE] switch_core_session.c:2135 Pre-Answer loopback/2500-b! 2012-01-05 13:36:08.541517 [DEBUG] switch_channel.c:2930 (loopback/2500-b) Callstate Change RINGING -> EARLY EXECUTE loopback/2500-b callcenter(click2call) 2012-01-05 13:36:08.541517 [DEBUG] switch_channel.c:3188 (loopback/2500-a) Callstate Change EARLY -> ACTIVE 2012-01-05 13:36:08.541517 [NOTICE] mod_loopback.c:755 Channel [loopback/2500-a] has been answered 2012-01-05 13:36:08.541517 [DEBUG] switch_core_session.c:729 Send signal loopback/2500-b [BREAK] 2012-01-05 13:36:08.541517 [DEBUG] mod_loopback.c:475 loopback/2500-b CHANNEL KILL 2012-01-05 13:36:08.541517 [DEBUG] switch_ivr_originate.c:3266 Originate Resulted in Success: [loopback/2500-a] 2012-01-05 13:36:08.541517 [DEBUG] switch_channel.c:3188 (loopback/2500-b) Callstate Change EARLY -> ACTIVE 2012-01-05 13:36:08.541517 [INFO] switch_channel.c:2708 loopback/2500-a Flipping CID from "" <0000000000> to "Outbound Call" <XML>
On Jan 5, 2012, at 4:17 AM, Oliver Schenk wrote:
Also, maybe I should be doing something like this:
sofia/gateway/mygatewayname/1091234567 '&managed(ivrAppName)'
instead of:
sofia/internal/1091234567@192.168.x.x '&managed(ivrAppName)'
but, I don't really have the CISCO configured as a gateway, nor do I know how really...probably not on the right track there.
On Thu, Jan 5, 2012 at 3:06 PM, Oliver Schenk <olimonkey@gmail.com> wrote:
*bump*
So I think maybe the way I'm doing the originate is the problem? In my call string I'm creating a connection directly from the CISCO (192.168.x.x) to the managed application, which may be why it starts playing straight away?
Maybe I should be originating a call first and then only once I know the other side has picked up will I bridge the call to the IVR managed application.
Problem is I dunno how to tell whether the other person has picked up (or even if the cisco is going to tell me) and I don't know how to do things to a call once it has been established.
I'm currently reading the Dialplan wiki page, hoping to get something out of it there.
Cheers
Oliver
On Tue, Jan 3, 2012 at 11:46 AM, Oliver Schenk <olimonkey@gmail.com> wrote:
I've been battling while creating an IVR using FreeSWITCH mod_managed and connecting through a CISCO 2811. Most things now work quite well, but I am having a few issues with the way the system answers calls (or doesn't answer calls...).
I have FreeSWITCH running as a windows service on Windows Server 2008, which is connected via LAN to a CISCO 2811 with a 4 port FXO card, which is then connected to a POTS phone line.
Take the following scenario:
1. Managed .NET application creates a call string and uses ESL to talk to freeswitch and originate a call:
string callstring = "{bridge_answer_timeout=20,ignore_early_media=true,call_timeout=20}sofia/internal/1091234567@192.168.x.x '&managed(ivrAppName)'"; eslConnection.API("originate", callstring);
where 192.168.x.x is the CISCO IP.
2. The CISCO sees that the phone number (1091234567) starts with a 1 so it uses FXO port 1 and strips the 1 and uses the remaining phone number (091234567) to make the call.
3. My phone rings, I pick up and I can hear my IVR playing.
These are my current problems:
- IVR starts playing before I even pick up the phone. This means that if the system calls a mobile phone and the person doesn't pick up, the IVR will start playing and eventually the mobile phone will divert to voice mail. Obviously I then get a missed call and an sms saying I have a new voice mail, which is annoying. Instead I would like it to KNOW that no one has picked up, but I don't know how to do this. Somehow the CISCO needs to be able to tell FreeSWITCH that the call has not yet been answered. For some reason however as soon as the CISCO starts calling FreeSWITCH thinks the call is already connected. It doesn't know that the CISCO is actually still ringing. Maybe I'm doing originate the wrong way or something ...
- The phone only rings for about 10 seconds before hanging up. I've tried "call_timeout", "bridge_answer_timeout". I've also tried setting CISCO "ring number". Nothing works, my phone still only rings for about 10 seconds. I don't know if this is a FreeSWITCH issue or a CISCO issue. I'm leaning towards CISCO, because FreeSWITCH IVR just starts playing even if no one answers the phone.
CISCO Config for relevant FXO port:
voice service voip allow-connections h323 to h323 allow-connections h323 to sip allow-connections sip to h323 allow-connections sip to sip no supplementary-service h450.2 no supplementary-service h450.3 supplementary-service h450.12 no supplementary-service sip moved-temporarily no supplementary-service sip refer fax protocol cisco sip registrar server expires max 3600 min 3600 no update-callerid no call service stop
voice-port 0/3/2 output attenuation -3 no comfort-noise cptone AU impedance complex1 caller-id enable ! dial-peer voice 100 pots preference 1 destination-pattern 1T port 0/3/2 !
Many Thanks,
Oliver
_________________________________________________________________________ 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
Shouldn't there be a 180 RINGING somewhere in there? On Fri, Jan 6, 2012 at 8:25 AM, Oliver Schenk <olimonkey@gmail.com> wrote:
I just noticed something else, if I don't pick up the phone at all. The IVR just keeps playing until the menu timeout kicks in.
So here is a CISCO SIP log: http://pastebin.com/Y9sYkuxi
The FS server is 192.168.x.50 and the CISCO is 192.168.x.1. I hope the CISCO log is readable, it's a bit long because I just did "debug ccsip all".
In this test I didn't bother picking up the phone at all, but I can see that FS answered anyway and the IVR kept playing until it timed out. I'm not an expert, but here is what I picked out of it:
At 00:08:10 we get a Received: "INVITE sip:109212xxxx@192.168.x.1 SIP/2.0"
the further down at the same timestamp we get Sent: "SIP/2.0 100 Trying"
At 00:08:13 we get a Sent: "SIP/2.0 183 Session Progress"
At 00:18:13 we get a Sent: "SIP/2.0 200 OK"
Then at the same timestamp we get: Received: "ACK sip:109212xxxx@192.168.x.1:5060 SIP/2.0"
Once the IVR times out at 00:09:16 we get Received: "BYE sip:109212xxxx@192.168.x.1:5060 SIP/2.0"
And then the reply right after Sent: "SIP/2.0 200 OK"
So I think you were right, the CISCO is sending back an "OK" 3 seconds after the "INVITE" is received.
The part that is beyond my field of expertise so far is WHY?
Thanks,
Oliver
On Fri, Jan 6, 2012 at 8:04 AM, Oliver Schenk <olimonkey@gmail.com> wrote:
By the way:
I tried {ignore_early_media=true} as well, but as I think we determined, my problem is probably with the CISCO telling FS that the call has been answered when really it hasn't yet.
On Fri, Jan 6, 2012 at 8:01 AM, Oliver Schenk <olimonkey@gmail.com> wrote:
Thanks for the help so far.
Here is a pastebin of FreeSWITCH output: http://pastebin.com/i6Qgc7ws
Notice how the "has been answered" log message comes immediately (within a few milliseconds) after the call was originated. I think this would suggest that the CISCO is immediately sending a 200 OK, as you suggested. I also turned on CISCO debugging, but I'm just trying to figure out how to get the information regarding SIP messages back to Freeswitch. I'll run the test again and see if I can get some useful CISCO debug.
Which "debug ccsip" commands are relevant to what I want for the CISCO SIP debugging?
Thanks!
2012/1/6 Gustavo Mársico <gustavomarsico@gmail.com>:
I think I've a similar problem related to callcenter app. When I made an originate like this:
originate loopback/2500/default/XML &bridge(user/2001)
2500 is an extension that leads to a callcenter application. In this case, we dial first to the queue and when an agent answered we call to the customer. As far as I know When the A-leg reaches to the queue, without selecting an agent, the call is automatically sent to the B-leg. As far as I see, there is a pre-answer method that fs needs to send the media to A-leg. In order to try to avoid this, I tried using ignore_early_media=true as part of the originate in A-leg and/or B-leg, with no luck.
originate {ignore_early_media=true}loopback/2500/default/XML &bridge({ignore_early_media=true}user/2001)
Dialplan: loopback/2500-b Regex (PASS) [CallCenter_Click2Call] destination_number(2500) =~ /^(2500)$/ break=on-false Dialplan: loopback/2500-b Action set(ignore_early_media=true) Dialplan: loopback/2500-b Action callcenter(click2call) 2012-01-05 13:36:08.541517 [DEBUG] switch_core_state_machine.c:154 (loopback/2500-b) State Change CS_ROUTING -> CS_EXECUTE 2012-01-05 13:36:08.541517 [DEBUG] switch_core_session.c:1180 Send signal loopback/2500-b [BREAK] 2012-01-05 13:36:08.541517 [DEBUG] mod_loopback.c:475 loopback/2500-b CHANNEL KILL 2012-01-05 13:36:08.541517 [DEBUG] switch_core_state_machine.c:410 (loopback/2500-b) State ROUTING going to sleep 2012-01-05 13:36:08.541517 [DEBUG] switch_core_state_machine.c:362 (loopback/2500-b) Running State Change CS_EXECUTE 2012-01-05 13:36:08.541517 [DEBUG] switch_core_state_machine.c:417 (loopback/2500-b) State EXECUTE 2012-01-05 13:36:08.541517 [DEBUG] mod_loopback.c:375 loopback/2500-b CHANNEL EXECUTE 2012-01-05 13:36:08.541517 [DEBUG] switch_core_state_machine.c:192 loopback/2500-b Standard EXECUTE EXECUTE loopback/2500-b set(open=true) 2012-01-05 13:36:08.541517 [DEBUG] mod_dptools.c:1286 loopback/2500-b SET [open]=[true] EXECUTE loopback/2500-b hash(insert/10.8.0.70-spymap/0000000000/fef7d864-b3c7-407c-a6e1-94386642bfbb) EXECUTE loopback/2500-b hash(insert/10.8.0.70-last_dial/0000000000/2500) EXECUTE loopback/2500-b hash(insert/10.8.0.70-last_dial/global/fef7d864-b3c7-407c-a6e1-94386642bfbb) EXECUTE loopback/2500-b set(RFC2822_DATE=Thu, 05 Jan 2012 13:36:08 -0300) 2012-01-05 13:36:08.541517 [DEBUG] mod_dptools.c:1286 loopback/2500-b SET [RFC2822_DATE]=[Thu, 05 Jan 2012 13:36:08 -0300] EXECUTE loopback/2500-b set(ignore_early_media=true) 2012-01-05 13:36:08.541517 [DEBUG] mod_dptools.c:1286 loopback/2500-b SET [ignore_early_media]=[true] 2012-01-05 13:36:08.541517 [DEBUG] switch_core_session.c:2133 Application callcenter Requires media! pre_answering channel loopback/2500-b 2012-01-05 13:36:08.541517 [NOTICE] mod_loopback.c:760 Pre-Answer loopback/2500-a! 2012-01-05 13:36:08.541517 [DEBUG] switch_channel.c:2930 (loopback/2500-a) Callstate Change RINGING -> EARLY 2012-01-05 13:36:08.541517 [DEBUG] switch_core_session.c:729 Send signal loopback/2500-b [BREAK] 2012-01-05 13:36:08.541517 [DEBUG] mod_loopback.c:475 loopback/2500-b CHANNEL KILL 2012-01-05 13:36:08.541517 [NOTICE] switch_core_session.c:2135 Pre-Answer loopback/2500-b! 2012-01-05 13:36:08.541517 [DEBUG] switch_channel.c:2930 (loopback/2500-b) Callstate Change RINGING -> EARLY EXECUTE loopback/2500-b callcenter(click2call) 2012-01-05 13:36:08.541517 [DEBUG] switch_channel.c:3188 (loopback/2500-a) Callstate Change EARLY -> ACTIVE 2012-01-05 13:36:08.541517 [NOTICE] mod_loopback.c:755 Channel [loopback/2500-a] has been answered 2012-01-05 13:36:08.541517 [DEBUG] switch_core_session.c:729 Send signal loopback/2500-b [BREAK] 2012-01-05 13:36:08.541517 [DEBUG] mod_loopback.c:475 loopback/2500-b CHANNEL KILL 2012-01-05 13:36:08.541517 [DEBUG] switch_ivr_originate.c:3266 Originate Resulted in Success: [loopback/2500-a] 2012-01-05 13:36:08.541517 [DEBUG] switch_channel.c:3188 (loopback/2500-b) Callstate Change EARLY -> ACTIVE 2012-01-05 13:36:08.541517 [INFO] switch_channel.c:2708 loopback/2500-a Flipping CID from "" <0000000000> to "Outbound Call" <XML>
On Jan 5, 2012, at 4:17 AM, Oliver Schenk wrote:
Also, maybe I should be doing something like this:
sofia/gateway/mygatewayname/1091234567 '&managed(ivrAppName)'
instead of:
sofia/internal/1091234567@192.168.x.x '&managed(ivrAppName)'
but, I don't really have the CISCO configured as a gateway, nor do I know how really...probably not on the right track there.
On Thu, Jan 5, 2012 at 3:06 PM, Oliver Schenk <olimonkey@gmail.com> wrote:
*bump*
So I think maybe the way I'm doing the originate is the problem? In my call string I'm creating a connection directly from the CISCO (192.168.x.x) to the managed application, which may be why it starts playing straight away?
Maybe I should be originating a call first and then only once I know the other side has picked up will I bridge the call to the IVR managed application.
Problem is I dunno how to tell whether the other person has picked up (or even if the cisco is going to tell me) and I don't know how to do things to a call once it has been established.
I'm currently reading the Dialplan wiki page, hoping to get something out of it there.
Cheers
Oliver
On Tue, Jan 3, 2012 at 11:46 AM, Oliver Schenk <olimonkey@gmail.com> wrote: > I've been battling while creating an IVR using FreeSWITCH mod_managed > and connecting through a CISCO 2811. Most things now work quite well, > but I am having a few issues with the way the system answers calls (or > doesn't answer calls...). > > I have FreeSWITCH running as a windows service on Windows Server 2008, > which is connected via LAN to a CISCO 2811 with a 4 port FXO card, > which is then connected to a POTS phone line. > > > Take the following scenario: > > 1. Managed .NET application creates a call string and uses ESL to talk > to freeswitch and originate a call: > > string callstring = > "{bridge_answer_timeout=20,ignore_early_media=true,call_timeout=20}sofia/internal/1091234567@192.168.x.x > '&managed(ivrAppName)'"; > eslConnection.API("originate", callstring); > > where 192.168.x.x is the CISCO IP. > > 2. The CISCO sees that the phone number (1091234567) starts with a 1 > so it uses FXO port 1 and strips the 1 and uses the remaining phone > number (091234567) to make the call. > > 3. My phone rings, I pick up and I can hear my IVR playing. > > > > These are my current problems: > > - IVR starts playing before I even pick up the phone. This means that > if the system calls a mobile phone and the person doesn't pick up, the > IVR will start playing and eventually the mobile phone will divert to > voice mail. Obviously I then get a missed call and an sms saying I > have a new voice mail, which is annoying. Instead I would like it to > KNOW that no one has picked up, but I don't know how to do this. > Somehow the CISCO needs to be able to tell FreeSWITCH that the call > has not yet been answered. For some reason however as soon as the > CISCO starts calling FreeSWITCH thinks the call is already connected. > It doesn't know that the CISCO is actually still ringing. Maybe I'm > doing originate the wrong way or something ... > > - The phone only rings for about 10 seconds before hanging up. I've > tried "call_timeout", "bridge_answer_timeout". I've also tried setting > CISCO "ring number". Nothing works, my phone still only rings for > about 10 seconds. I don't know if this is a FreeSWITCH issue or a > CISCO issue. I'm leaning towards CISCO, because FreeSWITCH IVR just > starts playing even if no one answers the phone. > > > > > > CISCO Config for relevant FXO port: > > voice service voip > allow-connections h323 to h323 > allow-connections h323 to sip > allow-connections sip to h323 > allow-connections sip to sip > no supplementary-service h450.2 > no supplementary-service h450.3 > supplementary-service h450.12 > no supplementary-service sip moved-temporarily > no supplementary-service sip refer > fax protocol cisco > sip > registrar server expires max 3600 min 3600 > no update-callerid > no call service stop > > voice-port 0/3/2 > output attenuation -3 > no comfort-noise > cptone AU > impedance complex1 > caller-id enable > ! > dial-peer voice 100 pots > preference 1 > destination-pattern 1T > port 0/3/2 > ! > > > > Many Thanks, > > Oliver
_________________________________________________________________________ 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
Thats what the 183 is.. 180 vs 183 are kinda sketchy in some devices.. 180 is usually RINGING (generate ringback locally) while a 183 has media... aka early media and usually provides ringback inband. /b On Jan 5, 2012, at 7:13 PM, Oliver Schenk wrote:
Shouldn't there be a 180 RINGING somewhere in there?
On Fri, Jan 6, 2012 at 8:25 AM, Oliver Schenk <olimonkey@gmail.com> wrote:
I just noticed something else, if I don't pick up the phone at all. The IVR just keeps playing until the menu timeout kicks in.
So here is a CISCO SIP log: http://pastebin.com/Y9sYkuxi
The FS server is 192.168.x.50 and the CISCO is 192.168.x.1. I hope the CISCO log is readable, it's a bit long because I just did "debug ccsip all".
In this test I didn't bother picking up the phone at all, but I can see that FS answered anyway and the IVR kept playing until it timed out. I'm not an expert, but here is what I picked out of it:
At 00:08:10 we get a Received: "INVITE sip:109212xxxx@192.168.x.1 SIP/2.0"
the further down at the same timestamp we get Sent: "SIP/2.0 100 Trying"
At 00:08:13 we get a Sent: "SIP/2.0 183 Session Progress"
At 00:18:13 we get a Sent: "SIP/2.0 200 OK"
Then at the same timestamp we get: Received: "ACK sip:109212xxxx@192.168.x.1:5060 SIP/2.0"
Once the IVR times out at 00:09:16 we get Received: "BYE sip:109212xxxx@192.168.x.1:5060 SIP/2.0"
And then the reply right after Sent: "SIP/2.0 200 OK"
So I think you were right, the CISCO is sending back an "OK" 3 seconds after the "INVITE" is received.
The part that is beyond my field of expertise so far is WHY?
Thanks,
Oliver
On Fri, Jan 6, 2012 at 8:04 AM, Oliver Schenk <olimonkey@gmail.com> wrote:
By the way:
I tried {ignore_early_media=true} as well, but as I think we determined, my problem is probably with the CISCO telling FS that the call has been answered when really it hasn't yet.
On Fri, Jan 6, 2012 at 8:01 AM, Oliver Schenk <olimonkey@gmail.com> wrote:
Thanks for the help so far.
Here is a pastebin of FreeSWITCH output: http://pastebin.com/i6Qgc7ws
Notice how the "has been answered" log message comes immediately (within a few milliseconds) after the call was originated. I think this would suggest that the CISCO is immediately sending a 200 OK, as you suggested. I also turned on CISCO debugging, but I'm just trying to figure out how to get the information regarding SIP messages back to Freeswitch. I'll run the test again and see if I can get some useful CISCO debug.
Which "debug ccsip" commands are relevant to what I want for the CISCO SIP debugging?
Thanks!
2012/1/6 Gustavo Mársico <gustavomarsico@gmail.com>:
I think I've a similar problem related to callcenter app. When I made an originate like this:
originate loopback/2500/default/XML &bridge(user/2001)
2500 is an extension that leads to a callcenter application. In this case, we dial first to the queue and when an agent answered we call to the customer. As far as I know When the A-leg reaches to the queue, without selecting an agent, the call is automatically sent to the B-leg. As far as I see, there is a pre-answer method that fs needs to send the media to A-leg. In order to try to avoid this, I tried using ignore_early_media=true as part of the originate in A-leg and/or B-leg, with no luck.
originate {ignore_early_media=true}loopback/2500/default/XML &bridge({ignore_early_media=true}user/2001)
Dialplan: loopback/2500-b Regex (PASS) [CallCenter_Click2Call] destination_number(2500) =~ /^(2500)$/ break=on-false Dialplan: loopback/2500-b Action set(ignore_early_media=true) Dialplan: loopback/2500-b Action callcenter(click2call) 2012-01-05 13:36:08.541517 [DEBUG] switch_core_state_machine.c:154 (loopback/2500-b) State Change CS_ROUTING -> CS_EXECUTE 2012-01-05 13:36:08.541517 [DEBUG] switch_core_session.c:1180 Send signal loopback/2500-b [BREAK] 2012-01-05 13:36:08.541517 [DEBUG] mod_loopback.c:475 loopback/2500-b CHANNEL KILL 2012-01-05 13:36:08.541517 [DEBUG] switch_core_state_machine.c:410 (loopback/2500-b) State ROUTING going to sleep 2012-01-05 13:36:08.541517 [DEBUG] switch_core_state_machine.c:362 (loopback/2500-b) Running State Change CS_EXECUTE 2012-01-05 13:36:08.541517 [DEBUG] switch_core_state_machine.c:417 (loopback/2500-b) State EXECUTE 2012-01-05 13:36:08.541517 [DEBUG] mod_loopback.c:375 loopback/2500-b CHANNEL EXECUTE 2012-01-05 13:36:08.541517 [DEBUG] switch_core_state_machine.c:192 loopback/2500-b Standard EXECUTE EXECUTE loopback/2500-b set(open=true) 2012-01-05 13:36:08.541517 [DEBUG] mod_dptools.c:1286 loopback/2500-b SET [open]=[true] EXECUTE loopback/2500-b hash(insert/10.8.0.70-spymap/0000000000/fef7d864-b3c7-407c-a6e1-94386642bfbb) EXECUTE loopback/2500-b hash(insert/10.8.0.70-last_dial/0000000000/2500) EXECUTE loopback/2500-b hash(insert/10.8.0.70-last_dial/global/fef7d864-b3c7-407c-a6e1-94386642bfbb) EXECUTE loopback/2500-b set(RFC2822_DATE=Thu, 05 Jan 2012 13:36:08 -0300) 2012-01-05 13:36:08.541517 [DEBUG] mod_dptools.c:1286 loopback/2500-b SET [RFC2822_DATE]=[Thu, 05 Jan 2012 13:36:08 -0300] EXECUTE loopback/2500-b set(ignore_early_media=true) 2012-01-05 13:36:08.541517 [DEBUG] mod_dptools.c:1286 loopback/2500-b SET [ignore_early_media]=[true] 2012-01-05 13:36:08.541517 [DEBUG] switch_core_session.c:2133 Application callcenter Requires media! pre_answering channel loopback/2500-b 2012-01-05 13:36:08.541517 [NOTICE] mod_loopback.c:760 Pre-Answer loopback/2500-a! 2012-01-05 13:36:08.541517 [DEBUG] switch_channel.c:2930 (loopback/2500-a) Callstate Change RINGING -> EARLY 2012-01-05 13:36:08.541517 [DEBUG] switch_core_session.c:729 Send signal loopback/2500-b [BREAK] 2012-01-05 13:36:08.541517 [DEBUG] mod_loopback.c:475 loopback/2500-b CHANNEL KILL 2012-01-05 13:36:08.541517 [NOTICE] switch_core_session.c:2135 Pre-Answer loopback/2500-b! 2012-01-05 13:36:08.541517 [DEBUG] switch_channel.c:2930 (loopback/2500-b) Callstate Change RINGING -> EARLY EXECUTE loopback/2500-b callcenter(click2call) 2012-01-05 13:36:08.541517 [DEBUG] switch_channel.c:3188 (loopback/2500-a) Callstate Change EARLY -> ACTIVE 2012-01-05 13:36:08.541517 [NOTICE] mod_loopback.c:755 Channel [loopback/2500-a] has been answered 2012-01-05 13:36:08.541517 [DEBUG] switch_core_session.c:729 Send signal loopback/2500-b [BREAK] 2012-01-05 13:36:08.541517 [DEBUG] mod_loopback.c:475 loopback/2500-b CHANNEL KILL 2012-01-05 13:36:08.541517 [DEBUG] switch_ivr_originate.c:3266 Originate Resulted in Success: [loopback/2500-a] 2012-01-05 13:36:08.541517 [DEBUG] switch_channel.c:3188 (loopback/2500-b) Callstate Change EARLY -> ACTIVE 2012-01-05 13:36:08.541517 [INFO] switch_channel.c:2708 loopback/2500-a Flipping CID from "" <0000000000> to "Outbound Call" <XML>
On Jan 5, 2012, at 4:17 AM, Oliver Schenk wrote:
Also, maybe I should be doing something like this:
sofia/gateway/mygatewayname/1091234567 '&managed(ivrAppName)'
instead of:
sofia/internal/1091234567@192.168.x.x '&managed(ivrAppName)'
but, I don't really have the CISCO configured as a gateway, nor do I know how really...probably not on the right track there.
On Thu, Jan 5, 2012 at 3:06 PM, Oliver Schenk <olimonkey@gmail.com> wrote: > *bump* > > > So I think maybe the way I'm doing the originate is the problem? In my > call string I'm creating a connection directly from the CISCO > (192.168.x.x) to the managed application, which may be why it starts > playing straight away? > > Maybe I should be originating a call first and then only once I know > the other side has picked up will I bridge the call to the IVR managed > application. > > Problem is I dunno how to tell whether the other person has picked up > (or even if the cisco is going to tell me) and I don't know how to do > things to a call once it has been established. > > > I'm currently reading the Dialplan wiki page, hoping to get something > out of it there. > > > Cheers > > Oliver > > > On Tue, Jan 3, 2012 at 11:46 AM, Oliver Schenk <olimonkey@gmail.com> wrote: >> I've been battling while creating an IVR using FreeSWITCH mod_managed >> and connecting through a CISCO 2811. Most things now work quite well, >> but I am having a few issues with the way the system answers calls (or >> doesn't answer calls...). >> >> I have FreeSWITCH running as a windows service on Windows Server 2008, >> which is connected via LAN to a CISCO 2811 with a 4 port FXO card, >> which is then connected to a POTS phone line. >> >> >> Take the following scenario: >> >> 1. Managed .NET application creates a call string and uses ESL to talk >> to freeswitch and originate a call: >> >> string callstring = >> "{bridge_answer_timeout=20,ignore_early_media=true,call_timeout=20}sofia/internal/1091234567@192.168.x.x >> '&managed(ivrAppName)'"; >> eslConnection.API("originate", callstring); >> >> where 192.168.x.x is the CISCO IP. >> >> 2. The CISCO sees that the phone number (1091234567) starts with a 1 >> so it uses FXO port 1 and strips the 1 and uses the remaining phone >> number (091234567) to make the call. >> >> 3. My phone rings, I pick up and I can hear my IVR playing. >> >> >> >> These are my current problems: >> >> - IVR starts playing before I even pick up the phone. This means that >> if the system calls a mobile phone and the person doesn't pick up, the >> IVR will start playing and eventually the mobile phone will divert to >> voice mail. Obviously I then get a missed call and an sms saying I >> have a new voice mail, which is annoying. Instead I would like it to >> KNOW that no one has picked up, but I don't know how to do this. >> Somehow the CISCO needs to be able to tell FreeSWITCH that the call >> has not yet been answered. For some reason however as soon as the >> CISCO starts calling FreeSWITCH thinks the call is already connected. >> It doesn't know that the CISCO is actually still ringing. Maybe I'm >> doing originate the wrong way or something ... >> >> - The phone only rings for about 10 seconds before hanging up. I've >> tried "call_timeout", "bridge_answer_timeout". I've also tried setting >> CISCO "ring number". Nothing works, my phone still only rings for >> about 10 seconds. I don't know if this is a FreeSWITCH issue or a >> CISCO issue. I'm leaning towards CISCO, because FreeSWITCH IVR just >> starts playing even if no one answers the phone. >> >> >> >> >> >> CISCO Config for relevant FXO port: >> >> voice service voip >> allow-connections h323 to h323 >> allow-connections h323 to sip >> allow-connections sip to h323 >> allow-connections sip to sip >> no supplementary-service h450.2 >> no supplementary-service h450.3 >> supplementary-service h450.12 >> no supplementary-service sip moved-temporarily >> no supplementary-service sip refer >> fax protocol cisco >> sip >> registrar server expires max 3600 min 3600 >> no update-callerid >> no call service stop >> >> voice-port 0/3/2 >> output attenuation -3 >> no comfort-noise >> cptone AU >> impedance complex1 >> caller-id enable >> ! >> dial-peer voice 100 pots >> preference 1 >> destination-pattern 1T >> port 0/3/2 >> ! >> >> >> >> Many Thanks, >> >> Oliver
_________________________________________________________________________ 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
-- Brian West FreeSWITCH Solutions, LLC Phone: +1 (918) 420-9266 Fax: +1 (918) 420-9267 brian@freeswitch.org http://www.freeswitch.org
I've tried looking at disable-early-media configuration command, but that didn't work and I doubt that has anything to do with the CISCO sending a 200 OK right after a 183 SESSION PROGRESS. On Fri, Jan 6, 2012 at 9:20 AM, Brian West <brian@freeswitch.org> wrote:
Thats what the 183 is.. 180 vs 183 are kinda sketchy in some devices.. 180 is usually RINGING (generate ringback locally) while a 183 has media... aka early media and usually provides ringback inband.
/b
On Jan 5, 2012, at 7:13 PM, Oliver Schenk wrote:
Shouldn't there be a 180 RINGING somewhere in there?
On Fri, Jan 6, 2012 at 8:25 AM, Oliver Schenk <olimonkey@gmail.com> wrote:
I just noticed something else, if I don't pick up the phone at all.
The IVR just keeps playing until the menu timeout kicks in.
So here is a CISCO SIP log:
The FS server is 192.168.x.50 and the CISCO is 192.168.x.1.
I hope the CISCO log is readable, it's a bit long because I just did
"debug ccsip all".
In this test I didn't bother picking up the phone at all, but I can
see that FS answered anyway and the IVR kept playing until it timed
out.
I'm not an expert, but here is what I picked out of it:
At 00:08:10 we get a
Received: "INVITE sip:109212xxxx@192.168.x.1 SIP/2.0"
the further down at the same timestamp we get
Sent: "SIP/2.0 100 Trying"
At 00:08:13 we get a
Sent: "SIP/2.0 183 Session Progress"
At 00:18:13 we get a
Sent: "SIP/2.0 200 OK"
Then at the same timestamp we get:
Received: "ACK sip:109212xxxx@192.168.x.1:5060 SIP/2.0"
Once the IVR times out at 00:09:16 we get
Received: "BYE sip:109212xxxx@192.168.x.1:5060 SIP/2.0"
And then the reply right after
Sent: "SIP/2.0 200 OK"
So I think you were right, the CISCO is sending back an "OK" 3 seconds
after the "INVITE" is received.
The part that is beyond my field of expertise so far is WHY?
Thanks,
Oliver
On Fri, Jan 6, 2012 at 8:04 AM, Oliver Schenk <olimonkey@gmail.com> wrote:
By the way:
I tried {ignore_early_media=true} as well, but as I think we
determined, my problem is probably with the CISCO telling FS that the
call has been answered when really it hasn't yet.
On Fri, Jan 6, 2012 at 8:01 AM, Oliver Schenk <olimonkey@gmail.com> wrote:
Thanks for the help so far.
Here is a pastebin of FreeSWITCH output:
Notice how the "has been answered" log message comes immediately
(within a few milliseconds) after the call was originated. I think
this would suggest that the CISCO is immediately sending a 200 OK, as
you suggested. I also turned on CISCO debugging, but I'm just trying
to figure out how to get the information regarding SIP messages back
to Freeswitch. I'll run the test again and see if I can get some
useful CISCO debug.
Which "debug ccsip" commands are relevant to what I want for the CISCO
SIP debugging?
Thanks!
2012/1/6 Gustavo Mársico <gustavomarsico@gmail.com>:
I think I've a similar problem related to callcenter app. When I made an originate like this:
originate loopback/2500/default/XML &bridge(user/2001)
2500 is an extension that leads to a callcenter application. In this case, we dial first to the queue and when an agent answered we call to the customer. As far as I know
When the A-leg reaches to the queue, without selecting an agent, the call is automatically sent to the B-leg. As far as I see, there is a pre-answer method that fs needs to send the media to A-leg.
In order to try to avoid this, I tried using ignore_early_media=true as part of the originate in A-leg and/or B-leg, with no luck.
originate {ignore_early_media=true}loopback/2500/default/XML &bridge({ignore_early_media=true}user/2001)
Dialplan: loopback/2500-b Regex (PASS) [CallCenter_Click2Call] destination_number(2500) =~ /^(2500)$/ break=on-false
Dialplan: loopback/2500-b Action set(ignore_early_media=true)
Dialplan: loopback/2500-b Action callcenter(click2call)
2012-01-05 13:36:08.541517 [DEBUG] switch_core_state_machine.c:154 (loopback/2500-b) State Change CS_ROUTING -> CS_EXECUTE
2012-01-05 13:36:08.541517 [DEBUG] switch_core_session.c:1180 Send signal loopback/2500-b [BREAK]
2012-01-05 13:36:08.541517 [DEBUG] mod_loopback.c:475 loopback/2500-b CHANNEL KILL
2012-01-05 13:36:08.541517 [DEBUG] switch_core_state_machine.c:410 (loopback/2500-b) State ROUTING going to sleep
2012-01-05 13:36:08.541517 [DEBUG] switch_core_state_machine.c:362 (loopback/2500-b) Running State Change CS_EXECUTE
2012-01-05 13:36:08.541517 [DEBUG] switch_core_state_machine.c:417 (loopback/2500-b) State EXECUTE
2012-01-05 13:36:08.541517 [DEBUG] mod_loopback.c:375 loopback/2500-b CHANNEL EXECUTE
2012-01-05 13:36:08.541517 [DEBUG] switch_core_state_machine.c:192 loopback/2500-b Standard EXECUTE
EXECUTE loopback/2500-b set(open=true)
2012-01-05 13:36:08.541517 [DEBUG] mod_dptools.c:1286 loopback/2500-b SET [open]=[true]
EXECUTE loopback/2500-b hash(insert/10.8.0.70-spymap/0000000000/fef7d864-b3c7-407c-a6e1-94386642bfbb)
EXECUTE loopback/2500-b hash(insert/10.8.0.70-last_dial/0000000000/2500)
EXECUTE loopback/2500-b hash(insert/10.8.0.70-last_dial/global/fef7d864-b3c7-407c-a6e1-94386642bfbb)
EXECUTE loopback/2500-b set(RFC2822_DATE=Thu, 05 Jan 2012 13:36:08 -0300)
2012-01-05 13:36:08.541517 [DEBUG] mod_dptools.c:1286 loopback/2500-b SET [RFC2822_DATE]=[Thu, 05 Jan 2012 13:36:08 -0300]
EXECUTE loopback/2500-b set(ignore_early_media=true)
2012-01-05 13:36:08.541517 [DEBUG] mod_dptools.c:1286 loopback/2500-b SET [ignore_early_media]=[true]
2012-01-05 13:36:08.541517 [DEBUG] switch_core_session.c:2133 Application callcenter Requires media! pre_answering channel loopback/2500-b
2012-01-05 13:36:08.541517 [NOTICE] mod_loopback.c:760 Pre-Answer loopback/2500-a!
2012-01-05 13:36:08.541517 [DEBUG] switch_channel.c:2930 (loopback/2500-a) Callstate Change RINGING -> EARLY
2012-01-05 13:36:08.541517 [DEBUG] switch_core_session.c:729 Send signal loopback/2500-b [BREAK]
2012-01-05 13:36:08.541517 [DEBUG] mod_loopback.c:475 loopback/2500-b CHANNEL KILL
2012-01-05 13:36:08.541517 [NOTICE] switch_core_session.c:2135 Pre-Answer loopback/2500-b!
2012-01-05 13:36:08.541517 [DEBUG] switch_channel.c:2930 (loopback/2500-b) Callstate Change RINGING -> EARLY
EXECUTE loopback/2500-b callcenter(click2call)
2012-01-05 13:36:08.541517 [DEBUG] switch_channel.c:3188 (loopback/2500-a) Callstate Change EARLY -> ACTIVE
2012-01-05 13:36:08.541517 [NOTICE] mod_loopback.c:755 Channel [loopback/2500-a] has been answered
2012-01-05 13:36:08.541517 [DEBUG] switch_core_session.c:729 Send signal loopback/2500-b [BREAK]
2012-01-05 13:36:08.541517 [DEBUG] mod_loopback.c:475 loopback/2500-b CHANNEL KILL
2012-01-05 13:36:08.541517 [DEBUG] switch_ivr_originate.c:3266 Originate Resulted in Success: [loopback/2500-a]
2012-01-05 13:36:08.541517 [DEBUG] switch_channel.c:3188 (loopback/2500-b) Callstate Change EARLY -> ACTIVE
2012-01-05 13:36:08.541517 [INFO] switch_channel.c:2708 loopback/2500-a Flipping CID from "" <0000000000> to "Outbound Call" <XML>
On Jan 5, 2012, at 4:17 AM, Oliver Schenk wrote:
Also, maybe I should be doing something like this:
sofia/gateway/mygatewayname/1091234567 '&managed(ivrAppName)'
instead of:
sofia/internal/1091234567@192.168.x.x '&managed(ivrAppName)'
but, I don't really have the CISCO configured as a gateway, nor do I
know how really...probably not on the right track there.
On Thu, Jan 5, 2012 at 3:06 PM, Oliver Schenk <olimonkey@gmail.com> wrote:
*bump*
So I think maybe the way I'm doing the originate is the problem? In my
call string I'm creating a connection directly from the CISCO
(192.168.x.x) to the managed application, which may be why it starts
playing straight away?
Maybe I should be originating a call first and then only once I know
the other side has picked up will I bridge the call to the IVR managed
application.
Problem is I dunno how to tell whether the other person has picked up
(or even if the cisco is going to tell me) and I don't know how to do
things to a call once it has been established.
I'm currently reading the Dialplan wiki page, hoping to get something
out of it there.
Cheers
Oliver
On Tue, Jan 3, 2012 at 11:46 AM, Oliver Schenk <olimonkey@gmail.com> wrote:
I've been battling while creating an IVR using FreeSWITCH mod_managed
and connecting through a CISCO 2811. Most things now work quite well,
but I am having a few issues with the way the system answers calls (or
doesn't answer calls...).
I have FreeSWITCH running as a windows service on Windows Server 2008,
which is connected via LAN to a CISCO 2811 with a 4 port FXO card,
which is then connected to a POTS phone line.
Take the following scenario:
1. Managed .NET application creates a call string and uses ESL to talk
to freeswitch and originate a call:
string callstring =
"{bridge_answer_timeout=20,ignore_early_media=true,call_timeout=20}sofia/internal/1091234567@192.168.x.x
'&managed(ivrAppName)'";
eslConnection.API("originate", callstring);
where 192.168.x.x is the CISCO IP.
2. The CISCO sees that the phone number (1091234567) starts with a 1
so it uses FXO port 1 and strips the 1 and uses the remaining phone
number (091234567) to make the call.
3. My phone rings, I pick up and I can hear my IVR playing.
These are my current problems:
- IVR starts playing before I even pick up the phone. This means that
if the system calls a mobile phone and the person doesn't pick up, the
IVR will start playing and eventually the mobile phone will divert to
voice mail. Obviously I then get a missed call and an sms saying I
have a new voice mail, which is annoying. Instead I would like it to
KNOW that no one has picked up, but I don't know how to do this.
Somehow the CISCO needs to be able to tell FreeSWITCH that the call
has not yet been answered. For some reason however as soon as the
CISCO starts calling FreeSWITCH thinks the call is already connected.
It doesn't know that the CISCO is actually still ringing. Maybe I'm
doing originate the wrong way or something ...
- The phone only rings for about 10 seconds before hanging up. I've
tried "call_timeout", "bridge_answer_timeout". I've also tried setting
CISCO "ring number". Nothing works, my phone still only rings for
about 10 seconds. I don't know if this is a FreeSWITCH issue or a
CISCO issue. I'm leaning towards CISCO, because FreeSWITCH IVR just
starts playing even if no one answers the phone.
CISCO Config for relevant FXO port:
voice service voip
allow-connections h323 to h323
allow-connections h323 to sip
allow-connections sip to h323
allow-connections sip to sip
no supplementary-service h450.2
no supplementary-service h450.3
supplementary-service h450.12
no supplementary-service sip moved-temporarily
no supplementary-service sip refer
fax protocol cisco
sip
registrar server expires max 3600 min 3600
no update-callerid
no call service stop
voice-port 0/3/2
output attenuation -3
no comfort-noise
cptone AU
impedance complex1
caller-id enable
!
dial-peer voice 100 pots
preference 1
destination-pattern 1T
port 0/3/2
!
Many Thanks,
Oliver
_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server
Official FreeSWITCH Sites
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
_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server
Official FreeSWITCH Sites
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
_________________________________________________________________________ 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
-- Brian West FreeSWITCH Solutions, LLC Phone: +1 (918) 420-9266 Fax: +1 (918) 420-9267 brian@freeswitch.org 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
If it sends 200 OK right after 183, this IS the problem. 200 OK means that the call was answered, it should not be sent until the call was actually picked up in the remote end. When 200 OK arrives to FS it will execute your app, and you will start playing the files. Seems to me there is something broken in the Cisco. /Peter ________________________________________ Från: freeswitch-users-bounces@lists.freeswitch.org [freeswitch-users-bounces@lists.freeswitch.org] för Oliver Schenk [olimonkey@gmail.com] Skickat: den 6 januari 2012 06:55 Till: FreeSWITCH Users Help Ämne: Re: [Freeswitch-users] CISCO 2811 Freeswitch IVR I've tried looking at disable-early-media configuration command, but that didn't work and I doubt that has anything to do with the CISCO sending a 200 OK right after a 183 SESSION PROGRESS. On Fri, Jan 6, 2012 at 9:20 AM, Brian West <brian@freeswitch.org> wrote:
Thats what the 183 is.. 180 vs 183 are kinda sketchy in some devices.. 180 is usually RINGING (generate ringback locally) while a 183 has media... aka early media and usually provides ringback inband.
/b
On Jan 5, 2012, at 7:13 PM, Oliver Schenk wrote:
Shouldn't there be a 180 RINGING somewhere in there?
On Fri, Jan 6, 2012 at 8:25 AM, Oliver Schenk <olimonkey@gmail.com> wrote:
I just noticed something else, if I don't pick up the phone at all.
The IVR just keeps playing until the menu timeout kicks in.
So here is a CISCO SIP log:
The FS server is 192.168.x.50 and the CISCO is 192.168.x.1.
I hope the CISCO log is readable, it's a bit long because I just did
"debug ccsip all".
In this test I didn't bother picking up the phone at all, but I can
see that FS answered anyway and the IVR kept playing until it timed
out.
I'm not an expert, but here is what I picked out of it:
At 00:08:10 we get a
Received: "INVITE sip:109212xxxx@192.168.x.1 SIP/2.0"
the further down at the same timestamp we get
Sent: "SIP/2.0 100 Trying"
At 00:08:13 we get a
Sent: "SIP/2.0 183 Session Progress"
At 00:18:13 we get a
Sent: "SIP/2.0 200 OK"
Then at the same timestamp we get:
Received: "ACK sip:109212xxxx@192.168.x.1:5060 SIP/2.0"
Once the IVR times out at 00:09:16 we get
Received: "BYE sip:109212xxxx@192.168.x.1:5060 SIP/2.0"
And then the reply right after
Sent: "SIP/2.0 200 OK"
So I think you were right, the CISCO is sending back an "OK" 3 seconds
after the "INVITE" is received.
The part that is beyond my field of expertise so far is WHY?
Thanks,
Oliver
On Fri, Jan 6, 2012 at 8:04 AM, Oliver Schenk <olimonkey@gmail.com> wrote:
By the way:
I tried {ignore_early_media=true} as well, but as I think we
determined, my problem is probably with the CISCO telling FS that the
call has been answered when really it hasn't yet.
On Fri, Jan 6, 2012 at 8:01 AM, Oliver Schenk <olimonkey@gmail.com> wrote:
Thanks for the help so far.
Here is a pastebin of FreeSWITCH output:
Notice how the "has been answered" log message comes immediately
(within a few milliseconds) after the call was originated. I think
this would suggest that the CISCO is immediately sending a 200 OK, as
you suggested. I also turned on CISCO debugging, but I'm just trying
to figure out how to get the information regarding SIP messages back
to Freeswitch. I'll run the test again and see if I can get some
useful CISCO debug.
Which "debug ccsip" commands are relevant to what I want for the CISCO
SIP debugging?
Thanks!
2012/1/6 Gustavo Mársico <gustavomarsico@gmail.com>:
I think I've a similar problem related to callcenter app. When I made an originate like this:
originate loopback/2500/default/XML &bridge(user/2001)
2500 is an extension that leads to a callcenter application. In this case, we dial first to the queue and when an agent answered we call to the customer. As far as I know
When the A-leg reaches to the queue, without selecting an agent, the call is automatically sent to the B-leg. As far as I see, there is a pre-answer method that fs needs to send the media to A-leg.
In order to try to avoid this, I tried using ignore_early_media=true as part of the originate in A-leg and/or B-leg, with no luck.
originate {ignore_early_media=true}loopback/2500/default/XML &bridge({ignore_early_media=true}user/2001)
Dialplan: loopback/2500-b Regex (PASS) [CallCenter_Click2Call] destination_number(2500) =~ /^(2500)$/ break=on-false
Dialplan: loopback/2500-b Action set(ignore_early_media=true)
Dialplan: loopback/2500-b Action callcenter(click2call)
2012-01-05 13:36:08.541517 [DEBUG] switch_core_state_machine.c:154 (loopback/2500-b) State Change CS_ROUTING -> CS_EXECUTE
2012-01-05 13:36:08.541517 [DEBUG] switch_core_session.c:1180 Send signal loopback/2500-b [BREAK]
2012-01-05 13:36:08.541517 [DEBUG] mod_loopback.c:475 loopback/2500-b CHANNEL KILL
2012-01-05 13:36:08.541517 [DEBUG] switch_core_state_machine.c:410 (loopback/2500-b) State ROUTING going to sleep
2012-01-05 13:36:08.541517 [DEBUG] switch_core_state_machine.c:362 (loopback/2500-b) Running State Change CS_EXECUTE
2012-01-05 13:36:08.541517 [DEBUG] switch_core_state_machine.c:417 (loopback/2500-b) State EXECUTE
2012-01-05 13:36:08.541517 [DEBUG] mod_loopback.c:375 loopback/2500-b CHANNEL EXECUTE
2012-01-05 13:36:08.541517 [DEBUG] switch_core_state_machine.c:192 loopback/2500-b Standard EXECUTE
EXECUTE loopback/2500-b set(open=true)
2012-01-05 13:36:08.541517 [DEBUG] mod_dptools.c:1286 loopback/2500-b SET [open]=[true]
EXECUTE loopback/2500-b hash(insert/10.8.0.70-spymap/0000000000/fef7d864-b3c7-407c-a6e1-94386642bfbb)
EXECUTE loopback/2500-b hash(insert/10.8.0.70-last_dial/0000000000/2500)
EXECUTE loopback/2500-b hash(insert/10.8.0.70-last_dial/global/fef7d864-b3c7-407c-a6e1-94386642bfbb)
EXECUTE loopback/2500-b set(RFC2822_DATE=Thu, 05 Jan 2012 13:36:08 -0300)
2012-01-05 13:36:08.541517 [DEBUG] mod_dptools.c:1286 loopback/2500-b SET [RFC2822_DATE]=[Thu, 05 Jan 2012 13:36:08 -0300]
EXECUTE loopback/2500-b set(ignore_early_media=true)
2012-01-05 13:36:08.541517 [DEBUG] mod_dptools.c:1286 loopback/2500-b SET [ignore_early_media]=[true]
2012-01-05 13:36:08.541517 [DEBUG] switch_core_session.c:2133 Application callcenter Requires media! pre_answering channel loopback/2500-b
2012-01-05 13:36:08.541517 [NOTICE] mod_loopback.c:760 Pre-Answer loopback/2500-a!
2012-01-05 13:36:08.541517 [DEBUG] switch_channel.c:2930 (loopback/2500-a) Callstate Change RINGING -> EARLY
2012-01-05 13:36:08.541517 [DEBUG] switch_core_session.c:729 Send signal loopback/2500-b [BREAK]
2012-01-05 13:36:08.541517 [DEBUG] mod_loopback.c:475 loopback/2500-b CHANNEL KILL
2012-01-05 13:36:08.541517 [NOTICE] switch_core_session.c:2135 Pre-Answer loopback/2500-b!
2012-01-05 13:36:08.541517 [DEBUG] switch_channel.c:2930 (loopback/2500-b) Callstate Change RINGING -> EARLY
EXECUTE loopback/2500-b callcenter(click2call)
2012-01-05 13:36:08.541517 [DEBUG] switch_channel.c:3188 (loopback/2500-a) Callstate Change EARLY -> ACTIVE
2012-01-05 13:36:08.541517 [NOTICE] mod_loopback.c:755 Channel [loopback/2500-a] has been answered
2012-01-05 13:36:08.541517 [DEBUG] switch_core_session.c:729 Send signal loopback/2500-b [BREAK]
2012-01-05 13:36:08.541517 [DEBUG] mod_loopback.c:475 loopback/2500-b CHANNEL KILL
2012-01-05 13:36:08.541517 [DEBUG] switch_ivr_originate.c:3266 Originate Resulted in Success: [loopback/2500-a]
2012-01-05 13:36:08.541517 [DEBUG] switch_channel.c:3188 (loopback/2500-b) Callstate Change EARLY -> ACTIVE
2012-01-05 13:36:08.541517 [INFO] switch_channel.c:2708 loopback/2500-a Flipping CID from "" <0000000000> to "Outbound Call" <XML>
On Jan 5, 2012, at 4:17 AM, Oliver Schenk wrote:
Also, maybe I should be doing something like this:
sofia/gateway/mygatewayname/1091234567 '&managed(ivrAppName)'
instead of:
sofia/internal/1091234567@192.168.x.x '&managed(ivrAppName)'
but, I don't really have the CISCO configured as a gateway, nor do I
know how really...probably not on the right track there.
On Thu, Jan 5, 2012 at 3:06 PM, Oliver Schenk <olimonkey@gmail.com> wrote:
*bump*
So I think maybe the way I'm doing the originate is the problem? In my
call string I'm creating a connection directly from the CISCO
(192.168.x.x) to the managed application, which may be why it starts
playing straight away?
Maybe I should be originating a call first and then only once I know
the other side has picked up will I bridge the call to the IVR managed
application.
Problem is I dunno how to tell whether the other person has picked up
(or even if the cisco is going to tell me) and I don't know how to do
things to a call once it has been established.
I'm currently reading the Dialplan wiki page, hoping to get something
out of it there.
Cheers
Oliver
On Tue, Jan 3, 2012 at 11:46 AM, Oliver Schenk <olimonkey@gmail.com> wrote:
I've been battling while creating an IVR using FreeSWITCH mod_managed
and connecting through a CISCO 2811. Most things now work quite well,
but I am having a few issues with the way the system answers calls (or
doesn't answer calls...).
I have FreeSWITCH running as a windows service on Windows Server 2008,
which is connected via LAN to a CISCO 2811 with a 4 port FXO card,
which is then connected to a POTS phone line.
Take the following scenario:
1. Managed .NET application creates a call string and uses ESL to talk
to freeswitch and originate a call:
string callstring =
"{bridge_answer_timeout=20,ignore_early_media=true,call_timeout=20}sofia/internal/1091234567@192.168.x.x
'&managed(ivrAppName)'";
eslConnection.API("originate", callstring);
where 192.168.x.x is the CISCO IP.
2. The CISCO sees that the phone number (1091234567) starts with a 1
so it uses FXO port 1 and strips the 1 and uses the remaining phone
number (091234567) to make the call.
3. My phone rings, I pick up and I can hear my IVR playing.
These are my current problems:
- IVR starts playing before I even pick up the phone. This means that
if the system calls a mobile phone and the person doesn't pick up, the
IVR will start playing and eventually the mobile phone will divert to
voice mail. Obviously I then get a missed call and an sms saying I
have a new voice mail, which is annoying. Instead I would like it to
KNOW that no one has picked up, but I don't know how to do this.
Somehow the CISCO needs to be able to tell FreeSWITCH that the call
has not yet been answered. For some reason however as soon as the
CISCO starts calling FreeSWITCH thinks the call is already connected.
It doesn't know that the CISCO is actually still ringing. Maybe I'm
doing originate the wrong way or something ...
- The phone only rings for about 10 seconds before hanging up. I've
tried "call_timeout", "bridge_answer_timeout". I've also tried setting
CISCO "ring number". Nothing works, my phone still only rings for
about 10 seconds. I don't know if this is a FreeSWITCH issue or a
CISCO issue. I'm leaning towards CISCO, because FreeSWITCH IVR just
starts playing even if no one answers the phone.
CISCO Config for relevant FXO port:
voice service voip
allow-connections h323 to h323
allow-connections h323 to sip
allow-connections sip to h323
allow-connections sip to sip
no supplementary-service h450.2
no supplementary-service h450.3
supplementary-service h450.12
no supplementary-service sip moved-temporarily
no supplementary-service sip refer
fax protocol cisco
sip
registrar server expires max 3600 min 3600
no update-callerid
no call service stop
voice-port 0/3/2
output attenuation -3
no comfort-noise
cptone AU
impedance complex1
caller-id enable
!
dial-peer voice 100 pots
preference 1
destination-pattern 1T
port 0/3/2
!
Many Thanks,
Oliver
_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server
Official FreeSWITCH Sites
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
_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server
Official FreeSWITCH Sites
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
_________________________________________________________________________ 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
-- Brian West FreeSWITCH Solutions, LLC Phone: +1 (918) 420-9266 Fax: +1 (918) 420-9267 brian@freeswitch.org 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:4f068c9f32761270174137!
Because I'm using an FXO card with voice, I added something to my CISCO conf. Many others had the same thing: voice-port 0/3/0 ... supervisory disconnect dualtone mid-call supervisory answer dualtone <---- ADDED THIS ONE ... Once I added this, the FS output now just showed the following while the phone was ringing: 2012-01-05 16:19:31.644440 [NOTICE] switch_channel.c:816 New Channel sofia/internal/109212xxxx@192.168.x.x [69e3f13d-1e2a-409e-97a4-b5526ea6e4ec] 2012-01-05 16:19:35.124882 [INFO] sofia.c:740 sofia/internal/109212xxxx@192.168.x.x Update Callee ID to "Outbound Call" <109212xxxx> 2012-01-05 16:19:35.126883 [NOTICE] sofia_glue.c:3793 Pre-Answer sofia/internal/109212xxxx@192.168.x.x! Where as previous it would show the above and also show the following: 2012-01-05 16:19:35.127883 [INFO] switch_channel.c:2456 sofia/internal/109212xxxx@192.168.x.x Flipping CID from "" <0000000000> to "Outbound Call" <109212xxxx> 2012-01-05 16:19:35.137384 [INFO] sofia.c:740 sofia/internal/109212xxxx@192.168.x.x Update Callee ID to "109212xxxx" <1092122856> 2012-01-05 16:19:35.138384 [NOTICE] sofia.c:5296 Channel [sofia/internal/109212xxxx@192.168.x.x] has been answered BUT, the IVR still started playing even before I pick up the phone. Hmmmm.....so why is FS still starting the managed application when the call has not been answered yet. Are we all sure that the managed application should not be executed until the call "has been answered" shows up in the log file? Will have to keep testing on monday as I don't have access to the CISCO from where i am now. I'll have to see whether the CISCO changes had any impact on the times at which the SIP messages are sent back and forth. Especially the 200 OK message. Thanks again for help, maybe getting somewhere now...... Oliver On Fri, Jan 6, 2012 at 4:20 PM, Peter Olsson <peter.olsson@visionutveckling.se> wrote:
If it sends 200 OK right after 183, this IS the problem.
200 OK means that the call was answered, it should not be sent until the call was actually picked up in the remote end. When 200 OK arrives to FS it will execute your app, and you will start playing the files.
Seems to me there is something broken in the Cisco.
/Peter
________________________________________ Från: freeswitch-users-bounces@lists.freeswitch.org [freeswitch-users-bounces@lists.freeswitch.org] för Oliver Schenk [olimonkey@gmail.com] Skickat: den 6 januari 2012 06:55 Till: FreeSWITCH Users Help Ämne: Re: [Freeswitch-users] CISCO 2811 Freeswitch IVR
I've tried looking at disable-early-media configuration command, but that didn't work and I doubt that has anything to do with the CISCO sending a 200 OK right after a 183 SESSION PROGRESS.
On Fri, Jan 6, 2012 at 9:20 AM, Brian West <brian@freeswitch.org> wrote:
Thats what the 183 is.. 180 vs 183 are kinda sketchy in some devices.. 180 is usually RINGING (generate ringback locally) while a 183 has media... aka early media and usually provides ringback inband.
/b
On Jan 5, 2012, at 7:13 PM, Oliver Schenk wrote:
Shouldn't there be a 180 RINGING somewhere in there?
On Fri, Jan 6, 2012 at 8:25 AM, Oliver Schenk <olimonkey@gmail.com> wrote:
I just noticed something else, if I don't pick up the phone at all.
The IVR just keeps playing until the menu timeout kicks in.
So here is a CISCO SIP log:
The FS server is 192.168.x.50 and the CISCO is 192.168.x.1.
I hope the CISCO log is readable, it's a bit long because I just did
"debug ccsip all".
In this test I didn't bother picking up the phone at all, but I can
see that FS answered anyway and the IVR kept playing until it timed
out.
I'm not an expert, but here is what I picked out of it:
At 00:08:10 we get a
Received: "INVITE sip:109212xxxx@192.168.x.1 SIP/2.0"
the further down at the same timestamp we get
Sent: "SIP/2.0 100 Trying"
At 00:08:13 we get a
Sent: "SIP/2.0 183 Session Progress"
At 00:18:13 we get a
Sent: "SIP/2.0 200 OK"
Then at the same timestamp we get:
Received: "ACK sip:109212xxxx@192.168.x.1:5060 SIP/2.0"
Once the IVR times out at 00:09:16 we get
Received: "BYE sip:109212xxxx@192.168.x.1:5060 SIP/2.0"
And then the reply right after
Sent: "SIP/2.0 200 OK"
So I think you were right, the CISCO is sending back an "OK" 3 seconds
after the "INVITE" is received.
The part that is beyond my field of expertise so far is WHY?
Thanks,
Oliver
On Fri, Jan 6, 2012 at 8:04 AM, Oliver Schenk <olimonkey@gmail.com> wrote:
By the way:
I tried {ignore_early_media=true} as well, but as I think we
determined, my problem is probably with the CISCO telling FS that the
call has been answered when really it hasn't yet.
On Fri, Jan 6, 2012 at 8:01 AM, Oliver Schenk <olimonkey@gmail.com> wrote:
Thanks for the help so far.
Here is a pastebin of FreeSWITCH output:
Notice how the "has been answered" log message comes immediately
(within a few milliseconds) after the call was originated. I think
this would suggest that the CISCO is immediately sending a 200 OK, as
you suggested. I also turned on CISCO debugging, but I'm just trying
to figure out how to get the information regarding SIP messages back
to Freeswitch. I'll run the test again and see if I can get some
useful CISCO debug.
Which "debug ccsip" commands are relevant to what I want for the CISCO
SIP debugging?
Thanks!
2012/1/6 Gustavo Mársico <gustavomarsico@gmail.com>:
I think I've a similar problem related to callcenter app. When I made an originate like this:
originate loopback/2500/default/XML &bridge(user/2001)
2500 is an extension that leads to a callcenter application. In this case, we dial first to the queue and when an agent answered we call to the customer. As far as I know
When the A-leg reaches to the queue, without selecting an agent, the call is automatically sent to the B-leg. As far as I see, there is a pre-answer method that fs needs to send the media to A-leg.
In order to try to avoid this, I tried using ignore_early_media=true as part of the originate in A-leg and/or B-leg, with no luck.
originate {ignore_early_media=true}loopback/2500/default/XML &bridge({ignore_early_media=true}user/2001)
Dialplan: loopback/2500-b Regex (PASS) [CallCenter_Click2Call] destination_number(2500) =~ /^(2500)$/ break=on-false
Dialplan: loopback/2500-b Action set(ignore_early_media=true)
Dialplan: loopback/2500-b Action callcenter(click2call)
2012-01-05 13:36:08.541517 [DEBUG] switch_core_state_machine.c:154 (loopback/2500-b) State Change CS_ROUTING -> CS_EXECUTE
2012-01-05 13:36:08.541517 [DEBUG] switch_core_session.c:1180 Send signal loopback/2500-b [BREAK]
2012-01-05 13:36:08.541517 [DEBUG] mod_loopback.c:475 loopback/2500-b CHANNEL KILL
2012-01-05 13:36:08.541517 [DEBUG] switch_core_state_machine.c:410 (loopback/2500-b) State ROUTING going to sleep
2012-01-05 13:36:08.541517 [DEBUG] switch_core_state_machine.c:362 (loopback/2500-b) Running State Change CS_EXECUTE
2012-01-05 13:36:08.541517 [DEBUG] switch_core_state_machine.c:417 (loopback/2500-b) State EXECUTE
2012-01-05 13:36:08.541517 [DEBUG] mod_loopback.c:375 loopback/2500-b CHANNEL EXECUTE
2012-01-05 13:36:08.541517 [DEBUG] switch_core_state_machine.c:192 loopback/2500-b Standard EXECUTE
EXECUTE loopback/2500-b set(open=true)
2012-01-05 13:36:08.541517 [DEBUG] mod_dptools.c:1286 loopback/2500-b SET [open]=[true]
EXECUTE loopback/2500-b hash(insert/10.8.0.70-spymap/0000000000/fef7d864-b3c7-407c-a6e1-94386642bfbb)
EXECUTE loopback/2500-b hash(insert/10.8.0.70-last_dial/0000000000/2500)
EXECUTE loopback/2500-b hash(insert/10.8.0.70-last_dial/global/fef7d864-b3c7-407c-a6e1-94386642bfbb)
EXECUTE loopback/2500-b set(RFC2822_DATE=Thu, 05 Jan 2012 13:36:08 -0300)
2012-01-05 13:36:08.541517 [DEBUG] mod_dptools.c:1286 loopback/2500-b SET [RFC2822_DATE]=[Thu, 05 Jan 2012 13:36:08 -0300]
EXECUTE loopback/2500-b set(ignore_early_media=true)
2012-01-05 13:36:08.541517 [DEBUG] mod_dptools.c:1286 loopback/2500-b SET [ignore_early_media]=[true]
2012-01-05 13:36:08.541517 [DEBUG] switch_core_session.c:2133 Application callcenter Requires media! pre_answering channel loopback/2500-b
2012-01-05 13:36:08.541517 [NOTICE] mod_loopback.c:760 Pre-Answer loopback/2500-a!
2012-01-05 13:36:08.541517 [DEBUG] switch_channel.c:2930 (loopback/2500-a) Callstate Change RINGING -> EARLY
2012-01-05 13:36:08.541517 [DEBUG] switch_core_session.c:729 Send signal loopback/2500-b [BREAK]
2012-01-05 13:36:08.541517 [DEBUG] mod_loopback.c:475 loopback/2500-b CHANNEL KILL
2012-01-05 13:36:08.541517 [NOTICE] switch_core_session.c:2135 Pre-Answer loopback/2500-b!
2012-01-05 13:36:08.541517 [DEBUG] switch_channel.c:2930 (loopback/2500-b) Callstate Change RINGING -> EARLY
EXECUTE loopback/2500-b callcenter(click2call)
2012-01-05 13:36:08.541517 [DEBUG] switch_channel.c:3188 (loopback/2500-a) Callstate Change EARLY -> ACTIVE
2012-01-05 13:36:08.541517 [NOTICE] mod_loopback.c:755 Channel [loopback/2500-a] has been answered
2012-01-05 13:36:08.541517 [DEBUG] switch_core_session.c:729 Send signal loopback/2500-b [BREAK]
2012-01-05 13:36:08.541517 [DEBUG] mod_loopback.c:475 loopback/2500-b CHANNEL KILL
2012-01-05 13:36:08.541517 [DEBUG] switch_ivr_originate.c:3266 Originate Resulted in Success: [loopback/2500-a]
2012-01-05 13:36:08.541517 [DEBUG] switch_channel.c:3188 (loopback/2500-b) Callstate Change EARLY -> ACTIVE
2012-01-05 13:36:08.541517 [INFO] switch_channel.c:2708 loopback/2500-a Flipping CID from "" <0000000000> to "Outbound Call" <XML>
On Jan 5, 2012, at 4:17 AM, Oliver Schenk wrote:
Also, maybe I should be doing something like this:
sofia/gateway/mygatewayname/1091234567 '&managed(ivrAppName)'
instead of:
sofia/internal/1091234567@192.168.x.x '&managed(ivrAppName)'
but, I don't really have the CISCO configured as a gateway, nor do I
know how really...probably not on the right track there.
On Thu, Jan 5, 2012 at 3:06 PM, Oliver Schenk <olimonkey@gmail.com> wrote:
*bump*
So I think maybe the way I'm doing the originate is the problem? In my
call string I'm creating a connection directly from the CISCO
(192.168.x.x) to the managed application, which may be why it starts
playing straight away?
Maybe I should be originating a call first and then only once I know
the other side has picked up will I bridge the call to the IVR managed
application.
Problem is I dunno how to tell whether the other person has picked up
(or even if the cisco is going to tell me) and I don't know how to do
things to a call once it has been established.
I'm currently reading the Dialplan wiki page, hoping to get something
out of it there.
Cheers
Oliver
On Tue, Jan 3, 2012 at 11:46 AM, Oliver Schenk <olimonkey@gmail.com> wrote:
I've been battling while creating an IVR using FreeSWITCH mod_managed
and connecting through a CISCO 2811. Most things now work quite well,
but I am having a few issues with the way the system answers calls (or
doesn't answer calls...).
I have FreeSWITCH running as a windows service on Windows Server 2008,
which is connected via LAN to a CISCO 2811 with a 4 port FXO card,
which is then connected to a POTS phone line.
Take the following scenario:
1. Managed .NET application creates a call string and uses ESL to talk
to freeswitch and originate a call:
string callstring =
"{bridge_answer_timeout=20,ignore_early_media=true,call_timeout=20}sofia/internal/1091234567@192.168.x.x
'&managed(ivrAppName)'";
eslConnection.API("originate", callstring);
where 192.168.x.x is the CISCO IP.
2. The CISCO sees that the phone number (1091234567) starts with a 1
so it uses FXO port 1 and strips the 1 and uses the remaining phone
number (091234567) to make the call.
3. My phone rings, I pick up and I can hear my IVR playing.
These are my current problems:
- IVR starts playing before I even pick up the phone. This means that
if the system calls a mobile phone and the person doesn't pick up, the
IVR will start playing and eventually the mobile phone will divert to
voice mail. Obviously I then get a missed call and an sms saying I
have a new voice mail, which is annoying. Instead I would like it to
KNOW that no one has picked up, but I don't know how to do this.
Somehow the CISCO needs to be able to tell FreeSWITCH that the call
has not yet been answered. For some reason however as soon as the
CISCO starts calling FreeSWITCH thinks the call is already connected.
It doesn't know that the CISCO is actually still ringing. Maybe I'm
doing originate the wrong way or something ...
- The phone only rings for about 10 seconds before hanging up. I've
tried "call_timeout", "bridge_answer_timeout". I've also tried setting
CISCO "ring number". Nothing works, my phone still only rings for
about 10 seconds. I don't know if this is a FreeSWITCH issue or a
CISCO issue. I'm leaning towards CISCO, because FreeSWITCH IVR just
starts playing even if no one answers the phone.
CISCO Config for relevant FXO port:
voice service voip
allow-connections h323 to h323
allow-connections h323 to sip
allow-connections sip to h323
allow-connections sip to sip
no supplementary-service h450.2
no supplementary-service h450.3
supplementary-service h450.12
no supplementary-service sip moved-temporarily
no supplementary-service sip refer
fax protocol cisco
sip
registrar server expires max 3600 min 3600
no update-callerid
no call service stop
voice-port 0/3/2
output attenuation -3
no comfort-noise
cptone AU
impedance complex1
caller-id enable
!
dial-peer voice 100 pots
preference 1
destination-pattern 1T
port 0/3/2
!
Many Thanks,
Oliver
_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server
Official FreeSWITCH Sites
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
_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server
Official FreeSWITCH Sites
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
_________________________________________________________________________ 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
-- Brian West FreeSWITCH Solutions, LLC Phone: +1 (918) 420-9266 Fax: +1 (918) 420-9267 brian@freeswitch.org 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:4f068c9f32761270174137!
_________________________________________________________________________ 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
Are you still using ignore_early_media=true - this must be set for this to work correctly. You will see a EXECUTE log line when FS executes the application, with ignore_early_media enabled it shouldn't execute until the call has been answered. I just tried it myself, and it works as expected. Example "originate {ignore_early_media=true}sofia/internal/number@host &park()" Park application is only executed after the call was answered. /Peter ________________________________________ Från: freeswitch-users-bounces@lists.freeswitch.org [freeswitch-users-bounces@lists.freeswitch.org] för Oliver Schenk [olimonkey@gmail.com] Skickat: den 6 januari 2012 12:04 Till: FreeSWITCH Users Help Ämne: Re: [Freeswitch-users] CISCO 2811 Freeswitch IVR Because I'm using an FXO card with voice, I added something to my CISCO conf. Many others had the same thing: voice-port 0/3/0 ... supervisory disconnect dualtone mid-call supervisory answer dualtone <---- ADDED THIS ONE ... Once I added this, the FS output now just showed the following while the phone was ringing: 2012-01-05 16:19:31.644440 [NOTICE] switch_channel.c:816 New Channel sofia/internal/109212xxxx@192.168.x.x [69e3f13d-1e2a-409e-97a4-b5526ea6e4ec] 2012-01-05 16:19:35.124882 [INFO] sofia.c:740 sofia/internal/109212xxxx@192.168.x.x Update Callee ID to "Outbound Call" <109212xxxx> 2012-01-05 16:19:35.126883 [NOTICE] sofia_glue.c:3793 Pre-Answer sofia/internal/109212xxxx@192.168.x.x! Where as previous it would show the above and also show the following: 2012-01-05 16:19:35.127883 [INFO] switch_channel.c:2456 sofia/internal/109212xxxx@192.168.x.x Flipping CID from "" <0000000000> to "Outbound Call" <109212xxxx> 2012-01-05 16:19:35.137384 [INFO] sofia.c:740 sofia/internal/109212xxxx@192.168.x.x Update Callee ID to "109212xxxx" <1092122856> 2012-01-05 16:19:35.138384 [NOTICE] sofia.c:5296 Channel [sofia/internal/109212xxxx@192.168.x.x] has been answered BUT, the IVR still started playing even before I pick up the phone. Hmmmm.....so why is FS still starting the managed application when the call has not been answered yet. Are we all sure that the managed application should not be executed until the call "has been answered" shows up in the log file? Will have to keep testing on monday as I don't have access to the CISCO from where i am now. I'll have to see whether the CISCO changes had any impact on the times at which the SIP messages are sent back and forth. Especially the 200 OK message. Thanks again for help, maybe getting somewhere now...... Oliver On Fri, Jan 6, 2012 at 4:20 PM, Peter Olsson <peter.olsson@visionutveckling.se> wrote:
If it sends 200 OK right after 183, this IS the problem.
200 OK means that the call was answered, it should not be sent until the call was actually picked up in the remote end. When 200 OK arrives to FS it will execute your app, and you will start playing the files.
Seems to me there is something broken in the Cisco.
/Peter
________________________________________ Från: freeswitch-users-bounces@lists.freeswitch.org [freeswitch-users-bounces@lists.freeswitch.org] för Oliver Schenk [olimonkey@gmail.com] Skickat: den 6 januari 2012 06:55 Till: FreeSWITCH Users Help Ämne: Re: [Freeswitch-users] CISCO 2811 Freeswitch IVR
I've tried looking at disable-early-media configuration command, but that didn't work and I doubt that has anything to do with the CISCO sending a 200 OK right after a 183 SESSION PROGRESS.
On Fri, Jan 6, 2012 at 9:20 AM, Brian West <brian@freeswitch.org> wrote:
Thats what the 183 is.. 180 vs 183 are kinda sketchy in some devices.. 180 is usually RINGING (generate ringback locally) while a 183 has media... aka early media and usually provides ringback inband.
/b
On Jan 5, 2012, at 7:13 PM, Oliver Schenk wrote:
Shouldn't there be a 180 RINGING somewhere in there?
On Fri, Jan 6, 2012 at 8:25 AM, Oliver Schenk <olimonkey@gmail.com> wrote:
I just noticed something else, if I don't pick up the phone at all.
The IVR just keeps playing until the menu timeout kicks in.
So here is a CISCO SIP log:
The FS server is 192.168.x.50 and the CISCO is 192.168.x.1.
I hope the CISCO log is readable, it's a bit long because I just did
"debug ccsip all".
In this test I didn't bother picking up the phone at all, but I can
see that FS answered anyway and the IVR kept playing until it timed
out.
I'm not an expert, but here is what I picked out of it:
At 00:08:10 we get a
Received: "INVITE sip:109212xxxx@192.168.x.1 SIP/2.0"
the further down at the same timestamp we get
Sent: "SIP/2.0 100 Trying"
At 00:08:13 we get a
Sent: "SIP/2.0 183 Session Progress"
At 00:18:13 we get a
Sent: "SIP/2.0 200 OK"
Then at the same timestamp we get:
Received: "ACK sip:109212xxxx@192.168.x.1:5060 SIP/2.0"
Once the IVR times out at 00:09:16 we get
Received: "BYE sip:109212xxxx@192.168.x.1:5060 SIP/2.0"
And then the reply right after
Sent: "SIP/2.0 200 OK"
So I think you were right, the CISCO is sending back an "OK" 3 seconds
after the "INVITE" is received.
The part that is beyond my field of expertise so far is WHY?
Thanks,
Oliver
On Fri, Jan 6, 2012 at 8:04 AM, Oliver Schenk <olimonkey@gmail.com> wrote:
By the way:
I tried {ignore_early_media=true} as well, but as I think we
determined, my problem is probably with the CISCO telling FS that the
call has been answered when really it hasn't yet.
On Fri, Jan 6, 2012 at 8:01 AM, Oliver Schenk <olimonkey@gmail.com> wrote:
Thanks for the help so far.
Here is a pastebin of FreeSWITCH output:
Notice how the "has been answered" log message comes immediately
(within a few milliseconds) after the call was originated. I think
this would suggest that the CISCO is immediately sending a 200 OK, as
you suggested. I also turned on CISCO debugging, but I'm just trying
to figure out how to get the information regarding SIP messages back
to Freeswitch. I'll run the test again and see if I can get some
useful CISCO debug.
Which "debug ccsip" commands are relevant to what I want for the CISCO
SIP debugging?
Thanks!
2012/1/6 Gustavo Mársico <gustavomarsico@gmail.com>:
I think I've a similar problem related to callcenter app. When I made an originate like this:
originate loopback/2500/default/XML &bridge(user/2001)
2500 is an extension that leads to a callcenter application. In this case, we dial first to the queue and when an agent answered we call to the customer. As far as I know
When the A-leg reaches to the queue, without selecting an agent, the call is automatically sent to the B-leg. As far as I see, there is a pre-answer method that fs needs to send the media to A-leg.
In order to try to avoid this, I tried using ignore_early_media=true as part of the originate in A-leg and/or B-leg, with no luck.
originate {ignore_early_media=true}loopback/2500/default/XML &bridge({ignore_early_media=true}user/2001)
Dialplan: loopback/2500-b Regex (PASS) [CallCenter_Click2Call] destination_number(2500) =~ /^(2500)$/ break=on-false
Dialplan: loopback/2500-b Action set(ignore_early_media=true)
Dialplan: loopback/2500-b Action callcenter(click2call)
2012-01-05 13:36:08.541517 [DEBUG] switch_core_state_machine.c:154 (loopback/2500-b) State Change CS_ROUTING -> CS_EXECUTE
2012-01-05 13:36:08.541517 [DEBUG] switch_core_session.c:1180 Send signal loopback/2500-b [BREAK]
2012-01-05 13:36:08.541517 [DEBUG] mod_loopback.c:475 loopback/2500-b CHANNEL KILL
2012-01-05 13:36:08.541517 [DEBUG] switch_core_state_machine.c:410 (loopback/2500-b) State ROUTING going to sleep
2012-01-05 13:36:08.541517 [DEBUG] switch_core_state_machine.c:362 (loopback/2500-b) Running State Change CS_EXECUTE
2012-01-05 13:36:08.541517 [DEBUG] switch_core_state_machine.c:417 (loopback/2500-b) State EXECUTE
2012-01-05 13:36:08.541517 [DEBUG] mod_loopback.c:375 loopback/2500-b CHANNEL EXECUTE
2012-01-05 13:36:08.541517 [DEBUG] switch_core_state_machine.c:192 loopback/2500-b Standard EXECUTE
EXECUTE loopback/2500-b set(open=true)
2012-01-05 13:36:08.541517 [DEBUG] mod_dptools.c:1286 loopback/2500-b SET [open]=[true]
EXECUTE loopback/2500-b hash(insert/10.8.0.70-spymap/0000000000/fef7d864-b3c7-407c-a6e1-94386642bfbb)
EXECUTE loopback/2500-b hash(insert/10.8.0.70-last_dial/0000000000/2500)
EXECUTE loopback/2500-b hash(insert/10.8.0.70-last_dial/global/fef7d864-b3c7-407c-a6e1-94386642bfbb)
EXECUTE loopback/2500-b set(RFC2822_DATE=Thu, 05 Jan 2012 13:36:08 -0300)
2012-01-05 13:36:08.541517 [DEBUG] mod_dptools.c:1286 loopback/2500-b SET [RFC2822_DATE]=[Thu, 05 Jan 2012 13:36:08 -0300]
EXECUTE loopback/2500-b set(ignore_early_media=true)
2012-01-05 13:36:08.541517 [DEBUG] mod_dptools.c:1286 loopback/2500-b SET [ignore_early_media]=[true]
2012-01-05 13:36:08.541517 [DEBUG] switch_core_session.c:2133 Application callcenter Requires media! pre_answering channel loopback/2500-b
2012-01-05 13:36:08.541517 [NOTICE] mod_loopback.c:760 Pre-Answer loopback/2500-a!
2012-01-05 13:36:08.541517 [DEBUG] switch_channel.c:2930 (loopback/2500-a) Callstate Change RINGING -> EARLY
2012-01-05 13:36:08.541517 [DEBUG] switch_core_session.c:729 Send signal loopback/2500-b [BREAK]
2012-01-05 13:36:08.541517 [DEBUG] mod_loopback.c:475 loopback/2500-b CHANNEL KILL
2012-01-05 13:36:08.541517 [NOTICE] switch_core_session.c:2135 Pre-Answer loopback/2500-b!
2012-01-05 13:36:08.541517 [DEBUG] switch_channel.c:2930 (loopback/2500-b) Callstate Change RINGING -> EARLY
EXECUTE loopback/2500-b callcenter(click2call)
2012-01-05 13:36:08.541517 [DEBUG] switch_channel.c:3188 (loopback/2500-a) Callstate Change EARLY -> ACTIVE
2012-01-05 13:36:08.541517 [NOTICE] mod_loopback.c:755 Channel [loopback/2500-a] has been answered
2012-01-05 13:36:08.541517 [DEBUG] switch_core_session.c:729 Send signal loopback/2500-b [BREAK]
2012-01-05 13:36:08.541517 [DEBUG] mod_loopback.c:475 loopback/2500-b CHANNEL KILL
2012-01-05 13:36:08.541517 [DEBUG] switch_ivr_originate.c:3266 Originate Resulted in Success: [loopback/2500-a]
2012-01-05 13:36:08.541517 [DEBUG] switch_channel.c:3188 (loopback/2500-b) Callstate Change EARLY -> ACTIVE
2012-01-05 13:36:08.541517 [INFO] switch_channel.c:2708 loopback/2500-a Flipping CID from "" <0000000000> to "Outbound Call" <XML>
On Jan 5, 2012, at 4:17 AM, Oliver Schenk wrote:
Also, maybe I should be doing something like this:
sofia/gateway/mygatewayname/1091234567 '&managed(ivrAppName)'
instead of:
sofia/internal/1091234567@192.168.x.x '&managed(ivrAppName)'
but, I don't really have the CISCO configured as a gateway, nor do I
know how really...probably not on the right track there.
On Thu, Jan 5, 2012 at 3:06 PM, Oliver Schenk <olimonkey@gmail.com> wrote:
*bump*
So I think maybe the way I'm doing the originate is the problem? In my
call string I'm creating a connection directly from the CISCO
(192.168.x.x) to the managed application, which may be why it starts
playing straight away?
Maybe I should be originating a call first and then only once I know
the other side has picked up will I bridge the call to the IVR managed
application.
Problem is I dunno how to tell whether the other person has picked up
(or even if the cisco is going to tell me) and I don't know how to do
things to a call once it has been established.
I'm currently reading the Dialplan wiki page, hoping to get something
out of it there.
Cheers
Oliver
On Tue, Jan 3, 2012 at 11:46 AM, Oliver Schenk <olimonkey@gmail.com> wrote:
I've been battling while creating an IVR using FreeSWITCH mod_managed
and connecting through a CISCO 2811. Most things now work quite well,
but I am having a few issues with the way the system answers calls (or
doesn't answer calls...).
I have FreeSWITCH running as a windows service on Windows Server 2008,
which is connected via LAN to a CISCO 2811 with a 4 port FXO card,
which is then connected to a POTS phone line.
Take the following scenario:
1. Managed .NET application creates a call string and uses ESL to talk
to freeswitch and originate a call:
string callstring =
"{bridge_answer_timeout=20,ignore_early_media=true,call_timeout=20}sofia/internal/1091234567@192.168.x.x
'&managed(ivrAppName)'";
eslConnection.API("originate", callstring);
where 192.168.x.x is the CISCO IP.
2. The CISCO sees that the phone number (1091234567) starts with a 1
so it uses FXO port 1 and strips the 1 and uses the remaining phone
number (091234567) to make the call.
3. My phone rings, I pick up and I can hear my IVR playing.
These are my current problems:
- IVR starts playing before I even pick up the phone. This means that
if the system calls a mobile phone and the person doesn't pick up, the
IVR will start playing and eventually the mobile phone will divert to
voice mail. Obviously I then get a missed call and an sms saying I
have a new voice mail, which is annoying. Instead I would like it to
KNOW that no one has picked up, but I don't know how to do this.
Somehow the CISCO needs to be able to tell FreeSWITCH that the call
has not yet been answered. For some reason however as soon as the
CISCO starts calling FreeSWITCH thinks the call is already connected.
It doesn't know that the CISCO is actually still ringing. Maybe I'm
doing originate the wrong way or something ...
- The phone only rings for about 10 seconds before hanging up. I've
tried "call_timeout", "bridge_answer_timeout". I've also tried setting
CISCO "ring number". Nothing works, my phone still only rings for
about 10 seconds. I don't know if this is a FreeSWITCH issue or a
CISCO issue. I'm leaning towards CISCO, because FreeSWITCH IVR just
starts playing even if no one answers the phone.
CISCO Config for relevant FXO port:
voice service voip
allow-connections h323 to h323
allow-connections h323 to sip
allow-connections sip to h323
allow-connections sip to sip
no supplementary-service h450.2
no supplementary-service h450.3
supplementary-service h450.12
no supplementary-service sip moved-temporarily
no supplementary-service sip refer
fax protocol cisco
sip
registrar server expires max 3600 min 3600
no update-callerid
no call service stop
voice-port 0/3/2
output attenuation -3
no comfort-noise
cptone AU
impedance complex1
caller-id enable
!
dial-peer voice 100 pots
preference 1
destination-pattern 1T
port 0/3/2
!
Many Thanks,
Oliver
_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server
Official FreeSWITCH Sites
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
_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server
Official FreeSWITCH Sites
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
_________________________________________________________________________ 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
-- Brian West FreeSWITCH Solutions, LLC Phone: +1 (918) 420-9266 Fax: +1 (918) 420-9267 brian@freeswitch.org 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:4f06d49b32762089563979!
No, at the time I was no longer using "ignore_early_media= true", because initially it didn't work. I was actually thinking of putting this property back in again, thanks a lot! I'll try it first thing Monday. With regard to EXECUTE log line, either I don't have the right level of logging turned on or something else is going on, because I've never seen any such log entries before with my managed application; yet my IVR app definitely does get executed. I don't think I have the DEBUG logging output level turned on so that could explain it... Thanks all, Oliver On Fri, Jan 6, 2012 at 11:21 PM, Peter Olsson <peter.olsson@visionutveckling.se> wrote:
Are you still using ignore_early_media=true - this must be set for this to work correctly.
You will see a EXECUTE log line when FS executes the application, with ignore_early_media enabled it shouldn't execute until the call has been answered. I just tried it myself, and it works as expected.
Example "originate {ignore_early_media=true}sofia/internal/number@host &park()"
Park application is only executed after the call was answered.
/Peter
________________________________________ Från: freeswitch-users-bounces@lists.freeswitch.org [freeswitch-users-bounces@lists.freeswitch.org] för Oliver Schenk [olimonkey@gmail.com] Skickat: den 6 januari 2012 12:04 Till: FreeSWITCH Users Help Ämne: Re: [Freeswitch-users] CISCO 2811 Freeswitch IVR
Because I'm using an FXO card with voice, I added something to my CISCO conf. Many others had the same thing:
voice-port 0/3/0 ... supervisory disconnect dualtone mid-call supervisory answer dualtone <---- ADDED THIS ONE ...
Once I added this, the FS output now just showed the following while the phone was ringing:
2012-01-05 16:19:31.644440 [NOTICE] switch_channel.c:816 New Channel sofia/internal/109212xxxx@192.168.x.x [69e3f13d-1e2a-409e-97a4-b5526ea6e4ec] 2012-01-05 16:19:35.124882 [INFO] sofia.c:740 sofia/internal/109212xxxx@192.168.x.x Update Callee ID to "Outbound Call" <109212xxxx> 2012-01-05 16:19:35.126883 [NOTICE] sofia_glue.c:3793 Pre-Answer sofia/internal/109212xxxx@192.168.x.x!
Where as previous it would show the above and also show the following:
2012-01-05 16:19:35.127883 [INFO] switch_channel.c:2456 sofia/internal/109212xxxx@192.168.x.x Flipping CID from "" <0000000000> to "Outbound Call" <109212xxxx> 2012-01-05 16:19:35.137384 [INFO] sofia.c:740 sofia/internal/109212xxxx@192.168.x.x Update Callee ID to "109212xxxx" <1092122856> 2012-01-05 16:19:35.138384 [NOTICE] sofia.c:5296 Channel [sofia/internal/109212xxxx@192.168.x.x] has been answered
BUT, the IVR still started playing even before I pick up the phone. Hmmmm.....so why is FS still starting the managed application when the call has not been answered yet. Are we all sure that the managed application should not be executed until the call "has been answered" shows up in the log file?
Will have to keep testing on monday as I don't have access to the CISCO from where i am now. I'll have to see whether the CISCO changes had any impact on the times at which the SIP messages are sent back and forth. Especially the 200 OK message.
Thanks again for help, maybe getting somewhere now......
Oliver
On Fri, Jan 6, 2012 at 4:20 PM, Peter Olsson <peter.olsson@visionutveckling.se> wrote:
If it sends 200 OK right after 183, this IS the problem.
200 OK means that the call was answered, it should not be sent until the call was actually picked up in the remote end. When 200 OK arrives to FS it will execute your app, and you will start playing the files.
Seems to me there is something broken in the Cisco.
/Peter
________________________________________ Från: freeswitch-users-bounces@lists.freeswitch.org [freeswitch-users-bounces@lists.freeswitch.org] för Oliver Schenk [olimonkey@gmail.com] Skickat: den 6 januari 2012 06:55 Till: FreeSWITCH Users Help Ämne: Re: [Freeswitch-users] CISCO 2811 Freeswitch IVR
I've tried looking at disable-early-media configuration command, but that didn't work and I doubt that has anything to do with the CISCO sending a 200 OK right after a 183 SESSION PROGRESS.
On Fri, Jan 6, 2012 at 9:20 AM, Brian West <brian@freeswitch.org> wrote:
Thats what the 183 is.. 180 vs 183 are kinda sketchy in some devices.. 180 is usually RINGING (generate ringback locally) while a 183 has media... aka early media and usually provides ringback inband.
/b
On Jan 5, 2012, at 7:13 PM, Oliver Schenk wrote:
Shouldn't there be a 180 RINGING somewhere in there?
On Fri, Jan 6, 2012 at 8:25 AM, Oliver Schenk <olimonkey@gmail.com> wrote:
I just noticed something else, if I don't pick up the phone at all.
The IVR just keeps playing until the menu timeout kicks in.
So here is a CISCO SIP log:
The FS server is 192.168.x.50 and the CISCO is 192.168.x.1.
I hope the CISCO log is readable, it's a bit long because I just did
"debug ccsip all".
In this test I didn't bother picking up the phone at all, but I can
see that FS answered anyway and the IVR kept playing until it timed
out.
I'm not an expert, but here is what I picked out of it:
At 00:08:10 we get a
Received: "INVITE sip:109212xxxx@192.168.x.1 SIP/2.0"
the further down at the same timestamp we get
Sent: "SIP/2.0 100 Trying"
At 00:08:13 we get a
Sent: "SIP/2.0 183 Session Progress"
At 00:18:13 we get a
Sent: "SIP/2.0 200 OK"
Then at the same timestamp we get:
Received: "ACK sip:109212xxxx@192.168.x.1:5060 SIP/2.0"
Once the IVR times out at 00:09:16 we get
Received: "BYE sip:109212xxxx@192.168.x.1:5060 SIP/2.0"
And then the reply right after
Sent: "SIP/2.0 200 OK"
So I think you were right, the CISCO is sending back an "OK" 3 seconds
after the "INVITE" is received.
The part that is beyond my field of expertise so far is WHY?
Thanks,
Oliver
On Fri, Jan 6, 2012 at 8:04 AM, Oliver Schenk <olimonkey@gmail.com> wrote:
By the way:
I tried {ignore_early_media=true} as well, but as I think we
determined, my problem is probably with the CISCO telling FS that the
call has been answered when really it hasn't yet.
On Fri, Jan 6, 2012 at 8:01 AM, Oliver Schenk <olimonkey@gmail.com> wrote:
Thanks for the help so far.
Here is a pastebin of FreeSWITCH output:
Notice how the "has been answered" log message comes immediately
(within a few milliseconds) after the call was originated. I think
this would suggest that the CISCO is immediately sending a 200 OK, as
you suggested. I also turned on CISCO debugging, but I'm just trying
to figure out how to get the information regarding SIP messages back
to Freeswitch. I'll run the test again and see if I can get some
useful CISCO debug.
Which "debug ccsip" commands are relevant to what I want for the CISCO
SIP debugging?
Thanks!
2012/1/6 Gustavo Mársico <gustavomarsico@gmail.com>:
I think I've a similar problem related to callcenter app. When I made an originate like this:
originate loopback/2500/default/XML &bridge(user/2001)
2500 is an extension that leads to a callcenter application. In this case, we dial first to the queue and when an agent answered we call to the customer. As far as I know
When the A-leg reaches to the queue, without selecting an agent, the call is automatically sent to the B-leg. As far as I see, there is a pre-answer method that fs needs to send the media to A-leg.
In order to try to avoid this, I tried using ignore_early_media=true as part of the originate in A-leg and/or B-leg, with no luck.
originate {ignore_early_media=true}loopback/2500/default/XML &bridge({ignore_early_media=true}user/2001)
Dialplan: loopback/2500-b Regex (PASS) [CallCenter_Click2Call] destination_number(2500) =~ /^(2500)$/ break=on-false
Dialplan: loopback/2500-b Action set(ignore_early_media=true)
Dialplan: loopback/2500-b Action callcenter(click2call)
2012-01-05 13:36:08.541517 [DEBUG] switch_core_state_machine.c:154 (loopback/2500-b) State Change CS_ROUTING -> CS_EXECUTE
2012-01-05 13:36:08.541517 [DEBUG] switch_core_session.c:1180 Send signal loopback/2500-b [BREAK]
2012-01-05 13:36:08.541517 [DEBUG] mod_loopback.c:475 loopback/2500-b CHANNEL KILL
2012-01-05 13:36:08.541517 [DEBUG] switch_core_state_machine.c:410 (loopback/2500-b) State ROUTING going to sleep
2012-01-05 13:36:08.541517 [DEBUG] switch_core_state_machine.c:362 (loopback/2500-b) Running State Change CS_EXECUTE
2012-01-05 13:36:08.541517 [DEBUG] switch_core_state_machine.c:417 (loopback/2500-b) State EXECUTE
2012-01-05 13:36:08.541517 [DEBUG] mod_loopback.c:375 loopback/2500-b CHANNEL EXECUTE
2012-01-05 13:36:08.541517 [DEBUG] switch_core_state_machine.c:192 loopback/2500-b Standard EXECUTE
EXECUTE loopback/2500-b set(open=true)
2012-01-05 13:36:08.541517 [DEBUG] mod_dptools.c:1286 loopback/2500-b SET [open]=[true]
EXECUTE loopback/2500-b hash(insert/10.8.0.70-spymap/0000000000/fef7d864-b3c7-407c-a6e1-94386642bfbb)
EXECUTE loopback/2500-b hash(insert/10.8.0.70-last_dial/0000000000/2500)
EXECUTE loopback/2500-b hash(insert/10.8.0.70-last_dial/global/fef7d864-b3c7-407c-a6e1-94386642bfbb)
EXECUTE loopback/2500-b set(RFC2822_DATE=Thu, 05 Jan 2012 13:36:08 -0300)
2012-01-05 13:36:08.541517 [DEBUG] mod_dptools.c:1286 loopback/2500-b SET [RFC2822_DATE]=[Thu, 05 Jan 2012 13:36:08 -0300]
EXECUTE loopback/2500-b set(ignore_early_media=true)
2012-01-05 13:36:08.541517 [DEBUG] mod_dptools.c:1286 loopback/2500-b SET [ignore_early_media]=[true]
2012-01-05 13:36:08.541517 [DEBUG] switch_core_session.c:2133 Application callcenter Requires media! pre_answering channel loopback/2500-b
2012-01-05 13:36:08.541517 [NOTICE] mod_loopback.c:760 Pre-Answer loopback/2500-a!
2012-01-05 13:36:08.541517 [DEBUG] switch_channel.c:2930 (loopback/2500-a) Callstate Change RINGING -> EARLY
2012-01-05 13:36:08.541517 [DEBUG] switch_core_session.c:729 Send signal loopback/2500-b [BREAK]
2012-01-05 13:36:08.541517 [DEBUG] mod_loopback.c:475 loopback/2500-b CHANNEL KILL
2012-01-05 13:36:08.541517 [NOTICE] switch_core_session.c:2135 Pre-Answer loopback/2500-b!
2012-01-05 13:36:08.541517 [DEBUG] switch_channel.c:2930 (loopback/2500-b) Callstate Change RINGING -> EARLY
EXECUTE loopback/2500-b callcenter(click2call)
2012-01-05 13:36:08.541517 [DEBUG] switch_channel.c:3188 (loopback/2500-a) Callstate Change EARLY -> ACTIVE
2012-01-05 13:36:08.541517 [NOTICE] mod_loopback.c:755 Channel [loopback/2500-a] has been answered
2012-01-05 13:36:08.541517 [DEBUG] switch_core_session.c:729 Send signal loopback/2500-b [BREAK]
2012-01-05 13:36:08.541517 [DEBUG] mod_loopback.c:475 loopback/2500-b CHANNEL KILL
2012-01-05 13:36:08.541517 [DEBUG] switch_ivr_originate.c:3266 Originate Resulted in Success: [loopback/2500-a]
2012-01-05 13:36:08.541517 [DEBUG] switch_channel.c:3188 (loopback/2500-b) Callstate Change EARLY -> ACTIVE
2012-01-05 13:36:08.541517 [INFO] switch_channel.c:2708 loopback/2500-a Flipping CID from "" <0000000000> to "Outbound Call" <XML>
On Jan 5, 2012, at 4:17 AM, Oliver Schenk wrote:
Also, maybe I should be doing something like this:
sofia/gateway/mygatewayname/1091234567 '&managed(ivrAppName)'
instead of:
sofia/internal/1091234567@192.168.x.x '&managed(ivrAppName)'
but, I don't really have the CISCO configured as a gateway, nor do I
know how really...probably not on the right track there.
On Thu, Jan 5, 2012 at 3:06 PM, Oliver Schenk <olimonkey@gmail.com> wrote:
*bump*
So I think maybe the way I'm doing the originate is the problem? In my
call string I'm creating a connection directly from the CISCO
(192.168.x.x) to the managed application, which may be why it starts
playing straight away?
Maybe I should be originating a call first and then only once I know
the other side has picked up will I bridge the call to the IVR managed
application.
Problem is I dunno how to tell whether the other person has picked up
(or even if the cisco is going to tell me) and I don't know how to do
things to a call once it has been established.
I'm currently reading the Dialplan wiki page, hoping to get something
out of it there.
Cheers
Oliver
On Tue, Jan 3, 2012 at 11:46 AM, Oliver Schenk <olimonkey@gmail.com> wrote:
I've been battling while creating an IVR using FreeSWITCH mod_managed
and connecting through a CISCO 2811. Most things now work quite well,
but I am having a few issues with the way the system answers calls (or
doesn't answer calls...).
I have FreeSWITCH running as a windows service on Windows Server 2008,
which is connected via LAN to a CISCO 2811 with a 4 port FXO card,
which is then connected to a POTS phone line.
Take the following scenario:
1. Managed .NET application creates a call string and uses ESL to talk
to freeswitch and originate a call:
string callstring =
"{bridge_answer_timeout=20,ignore_early_media=true,call_timeout=20}sofia/internal/1091234567@192.168.x.x
'&managed(ivrAppName)'";
eslConnection.API("originate", callstring);
where 192.168.x.x is the CISCO IP.
2. The CISCO sees that the phone number (1091234567) starts with a 1
so it uses FXO port 1 and strips the 1 and uses the remaining phone
number (091234567) to make the call.
3. My phone rings, I pick up and I can hear my IVR playing.
These are my current problems:
- IVR starts playing before I even pick up the phone. This means that
if the system calls a mobile phone and the person doesn't pick up, the
IVR will start playing and eventually the mobile phone will divert to
voice mail. Obviously I then get a missed call and an sms saying I
have a new voice mail, which is annoying. Instead I would like it to
KNOW that no one has picked up, but I don't know how to do this.
Somehow the CISCO needs to be able to tell FreeSWITCH that the call
has not yet been answered. For some reason however as soon as the
CISCO starts calling FreeSWITCH thinks the call is already connected.
It doesn't know that the CISCO is actually still ringing. Maybe I'm
doing originate the wrong way or something ...
- The phone only rings for about 10 seconds before hanging up. I've
tried "call_timeout", "bridge_answer_timeout". I've also tried setting
CISCO "ring number". Nothing works, my phone still only rings for
about 10 seconds. I don't know if this is a FreeSWITCH issue or a
CISCO issue. I'm leaning towards CISCO, because FreeSWITCH IVR just
starts playing even if no one answers the phone.
CISCO Config for relevant FXO port:
voice service voip
allow-connections h323 to h323
allow-connections h323 to sip
allow-connections sip to h323
allow-connections sip to sip
no supplementary-service h450.2
no supplementary-service h450.3
supplementary-service h450.12
no supplementary-service sip moved-temporarily
no supplementary-service sip refer
fax protocol cisco
sip
registrar server expires max 3600 min 3600
no update-callerid
no call service stop
voice-port 0/3/2
output attenuation -3
no comfort-noise
cptone AU
impedance complex1
caller-id enable
!
dial-peer voice 100 pots
preference 1
destination-pattern 1T
port 0/3/2
!
Many Thanks,
Oliver
_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server
Official FreeSWITCH Sites
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
_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server
Official FreeSWITCH Sites
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
_________________________________________________________________________ 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
-- Brian West FreeSWITCH Solutions, LLC Phone: +1 (918) 420-9266 Fax: +1 (918) 420-9267 brian@freeswitch.org 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:4f06d49b32762089563979!
_________________________________________________________________________ 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
Alright, so I tried to set ignore_early_media=true, but the phone isn't being answered at all anymore. So i went back to the CISCO and turned on debugging. I'm now getting a different sequence of events. I still get: INVITE from FS 100 TRYING from CISCO 183 SESSION PROGRESS from CISCO then, when I pick up the phone I get: 503 SERVICE UNAVAILABLE from CISCO ACK from FS I wonder what's going on now. I'll have to play around with the "supervisiory answer dual-tone". CISCO voice-port config: voice-port 0/3/0 supervisory disconnect dualtone mid-call supervisory answer dualtone output attenuation -3 no comfort-noise cptone AU timeouts call-disconnect 5 timeouts wait-release 5 connection plar opx 1001 impedance complex1 caller-id enable Cheers, Oliver On Sat, Jan 7, 2012 at 9:28 AM, Oliver Schenk <olimonkey@gmail.com> wrote:
No, at the time I was no longer using "ignore_early_media= true", because initially it didn't work. I was actually thinking of putting this property back in again, thanks a lot! I'll try it first thing Monday.
With regard to EXECUTE log line, either I don't have the right level of logging turned on or something else is going on, because I've never seen any such log entries before with my managed application; yet my IVR app definitely does get executed. I don't think I have the DEBUG logging output level turned on so that could explain it...
Thanks all,
Oliver
On Fri, Jan 6, 2012 at 11:21 PM, Peter Olsson <peter.olsson@visionutveckling.se> wrote:
Are you still using ignore_early_media=true - this must be set for this to work correctly.
You will see a EXECUTE log line when FS executes the application, with ignore_early_media enabled it shouldn't execute until the call has been answered. I just tried it myself, and it works as expected.
Example "originate {ignore_early_media=true}sofia/internal/number@host &park()"
Park application is only executed after the call was answered.
/Peter
________________________________________ Från: freeswitch-users-bounces@lists.freeswitch.org [freeswitch-users-bounces@lists.freeswitch.org] för Oliver Schenk [olimonkey@gmail.com] Skickat: den 6 januari 2012 12:04 Till: FreeSWITCH Users Help Ämne: Re: [Freeswitch-users] CISCO 2811 Freeswitch IVR
Because I'm using an FXO card with voice, I added something to my CISCO conf. Many others had the same thing:
voice-port 0/3/0 ... supervisory disconnect dualtone mid-call supervisory answer dualtone <---- ADDED THIS ONE ...
Once I added this, the FS output now just showed the following while the phone was ringing:
2012-01-05 16:19:31.644440 [NOTICE] switch_channel.c:816 New Channel sofia/internal/109212xxxx@192.168.x.x [69e3f13d-1e2a-409e-97a4-b5526ea6e4ec] 2012-01-05 16:19:35.124882 [INFO] sofia.c:740 sofia/internal/109212xxxx@192.168.x.x Update Callee ID to "Outbound Call" <109212xxxx> 2012-01-05 16:19:35.126883 [NOTICE] sofia_glue.c:3793 Pre-Answer sofia/internal/109212xxxx@192.168.x.x!
Where as previous it would show the above and also show the following:
2012-01-05 16:19:35.127883 [INFO] switch_channel.c:2456 sofia/internal/109212xxxx@192.168.x.x Flipping CID from "" <0000000000> to "Outbound Call" <109212xxxx> 2012-01-05 16:19:35.137384 [INFO] sofia.c:740 sofia/internal/109212xxxx@192.168.x.x Update Callee ID to "109212xxxx" <1092122856> 2012-01-05 16:19:35.138384 [NOTICE] sofia.c:5296 Channel [sofia/internal/109212xxxx@192.168.x.x] has been answered
BUT, the IVR still started playing even before I pick up the phone. Hmmmm.....so why is FS still starting the managed application when the call has not been answered yet. Are we all sure that the managed application should not be executed until the call "has been answered" shows up in the log file?
Will have to keep testing on monday as I don't have access to the CISCO from where i am now. I'll have to see whether the CISCO changes had any impact on the times at which the SIP messages are sent back and forth. Especially the 200 OK message.
Thanks again for help, maybe getting somewhere now......
Oliver
On Fri, Jan 6, 2012 at 4:20 PM, Peter Olsson <peter.olsson@visionutveckling.se> wrote:
If it sends 200 OK right after 183, this IS the problem.
200 OK means that the call was answered, it should not be sent until the call was actually picked up in the remote end. When 200 OK arrives to FS it will execute your app, and you will start playing the files.
Seems to me there is something broken in the Cisco.
/Peter
________________________________________ Från: freeswitch-users-bounces@lists.freeswitch.org [freeswitch-users-bounces@lists.freeswitch.org] för Oliver Schenk [olimonkey@gmail.com] Skickat: den 6 januari 2012 06:55 Till: FreeSWITCH Users Help Ämne: Re: [Freeswitch-users] CISCO 2811 Freeswitch IVR
I've tried looking at disable-early-media configuration command, but that didn't work and I doubt that has anything to do with the CISCO sending a 200 OK right after a 183 SESSION PROGRESS.
On Fri, Jan 6, 2012 at 9:20 AM, Brian West <brian@freeswitch.org> wrote:
Thats what the 183 is.. 180 vs 183 are kinda sketchy in some devices.. 180 is usually RINGING (generate ringback locally) while a 183 has media... aka early media and usually provides ringback inband.
/b
On Jan 5, 2012, at 7:13 PM, Oliver Schenk wrote:
Shouldn't there be a 180 RINGING somewhere in there?
On Fri, Jan 6, 2012 at 8:25 AM, Oliver Schenk <olimonkey@gmail.com> wrote:
I just noticed something else, if I don't pick up the phone at all.
The IVR just keeps playing until the menu timeout kicks in.
So here is a CISCO SIP log:
The FS server is 192.168.x.50 and the CISCO is 192.168.x.1.
I hope the CISCO log is readable, it's a bit long because I just did
"debug ccsip all".
In this test I didn't bother picking up the phone at all, but I can
see that FS answered anyway and the IVR kept playing until it timed
out.
I'm not an expert, but here is what I picked out of it:
At 00:08:10 we get a
Received: "INVITE sip:109212xxxx@192.168.x.1 SIP/2.0"
the further down at the same timestamp we get
Sent: "SIP/2.0 100 Trying"
At 00:08:13 we get a
Sent: "SIP/2.0 183 Session Progress"
At 00:18:13 we get a
Sent: "SIP/2.0 200 OK"
Then at the same timestamp we get:
Received: "ACK sip:109212xxxx@192.168.x.1:5060 SIP/2.0"
Once the IVR times out at 00:09:16 we get
Received: "BYE sip:109212xxxx@192.168.x.1:5060 SIP/2.0"
And then the reply right after
Sent: "SIP/2.0 200 OK"
So I think you were right, the CISCO is sending back an "OK" 3 seconds
after the "INVITE" is received.
The part that is beyond my field of expertise so far is WHY?
Thanks,
Oliver
On Fri, Jan 6, 2012 at 8:04 AM, Oliver Schenk <olimonkey@gmail.com> wrote:
By the way:
I tried {ignore_early_media=true} as well, but as I think we
determined, my problem is probably with the CISCO telling FS that the
call has been answered when really it hasn't yet.
On Fri, Jan 6, 2012 at 8:01 AM, Oliver Schenk <olimonkey@gmail.com> wrote:
Thanks for the help so far.
Here is a pastebin of FreeSWITCH output:
Notice how the "has been answered" log message comes immediately
(within a few milliseconds) after the call was originated. I think
this would suggest that the CISCO is immediately sending a 200 OK, as
you suggested. I also turned on CISCO debugging, but I'm just trying
to figure out how to get the information regarding SIP messages back
to Freeswitch. I'll run the test again and see if I can get some
useful CISCO debug.
Which "debug ccsip" commands are relevant to what I want for the CISCO
SIP debugging?
Thanks!
2012/1/6 Gustavo Mársico <gustavomarsico@gmail.com>:
I think I've a similar problem related to callcenter app. When I made an originate like this:
originate loopback/2500/default/XML &bridge(user/2001)
2500 is an extension that leads to a callcenter application. In this case, we dial first to the queue and when an agent answered we call to the customer. As far as I know
When the A-leg reaches to the queue, without selecting an agent, the call is automatically sent to the B-leg. As far as I see, there is a pre-answer method that fs needs to send the media to A-leg.
In order to try to avoid this, I tried using ignore_early_media=true as part of the originate in A-leg and/or B-leg, with no luck.
originate {ignore_early_media=true}loopback/2500/default/XML &bridge({ignore_early_media=true}user/2001)
Dialplan: loopback/2500-b Regex (PASS) [CallCenter_Click2Call] destination_number(2500) =~ /^(2500)$/ break=on-false
Dialplan: loopback/2500-b Action set(ignore_early_media=true)
Dialplan: loopback/2500-b Action callcenter(click2call)
2012-01-05 13:36:08.541517 [DEBUG] switch_core_state_machine.c:154 (loopback/2500-b) State Change CS_ROUTING -> CS_EXECUTE
2012-01-05 13:36:08.541517 [DEBUG] switch_core_session.c:1180 Send signal loopback/2500-b [BREAK]
2012-01-05 13:36:08.541517 [DEBUG] mod_loopback.c:475 loopback/2500-b CHANNEL KILL
2012-01-05 13:36:08.541517 [DEBUG] switch_core_state_machine.c:410 (loopback/2500-b) State ROUTING going to sleep
2012-01-05 13:36:08.541517 [DEBUG] switch_core_state_machine.c:362 (loopback/2500-b) Running State Change CS_EXECUTE
2012-01-05 13:36:08.541517 [DEBUG] switch_core_state_machine.c:417 (loopback/2500-b) State EXECUTE
2012-01-05 13:36:08.541517 [DEBUG] mod_loopback.c:375 loopback/2500-b CHANNEL EXECUTE
2012-01-05 13:36:08.541517 [DEBUG] switch_core_state_machine.c:192 loopback/2500-b Standard EXECUTE
EXECUTE loopback/2500-b set(open=true)
2012-01-05 13:36:08.541517 [DEBUG] mod_dptools.c:1286 loopback/2500-b SET [open]=[true]
EXECUTE loopback/2500-b hash(insert/10.8.0.70-spymap/0000000000/fef7d864-b3c7-407c-a6e1-94386642bfbb)
EXECUTE loopback/2500-b hash(insert/10.8.0.70-last_dial/0000000000/2500)
EXECUTE loopback/2500-b hash(insert/10.8.0.70-last_dial/global/fef7d864-b3c7-407c-a6e1-94386642bfbb)
EXECUTE loopback/2500-b set(RFC2822_DATE=Thu, 05 Jan 2012 13:36:08 -0300)
2012-01-05 13:36:08.541517 [DEBUG] mod_dptools.c:1286 loopback/2500-b SET [RFC2822_DATE]=[Thu, 05 Jan 2012 13:36:08 -0300]
EXECUTE loopback/2500-b set(ignore_early_media=true)
2012-01-05 13:36:08.541517 [DEBUG] mod_dptools.c:1286 loopback/2500-b SET [ignore_early_media]=[true]
2012-01-05 13:36:08.541517 [DEBUG] switch_core_session.c:2133 Application callcenter Requires media! pre_answering channel loopback/2500-b
2012-01-05 13:36:08.541517 [NOTICE] mod_loopback.c:760 Pre-Answer loopback/2500-a!
2012-01-05 13:36:08.541517 [DEBUG] switch_channel.c:2930 (loopback/2500-a) Callstate Change RINGING -> EARLY
2012-01-05 13:36:08.541517 [DEBUG] switch_core_session.c:729 Send signal loopback/2500-b [BREAK]
2012-01-05 13:36:08.541517 [DEBUG] mod_loopback.c:475 loopback/2500-b CHANNEL KILL
2012-01-05 13:36:08.541517 [NOTICE] switch_core_session.c:2135 Pre-Answer loopback/2500-b!
2012-01-05 13:36:08.541517 [DEBUG] switch_channel.c:2930 (loopback/2500-b) Callstate Change RINGING -> EARLY
EXECUTE loopback/2500-b callcenter(click2call)
2012-01-05 13:36:08.541517 [DEBUG] switch_channel.c:3188 (loopback/2500-a) Callstate Change EARLY -> ACTIVE
2012-01-05 13:36:08.541517 [NOTICE] mod_loopback.c:755 Channel [loopback/2500-a] has been answered
2012-01-05 13:36:08.541517 [DEBUG] switch_core_session.c:729 Send signal loopback/2500-b [BREAK]
2012-01-05 13:36:08.541517 [DEBUG] mod_loopback.c:475 loopback/2500-b CHANNEL KILL
2012-01-05 13:36:08.541517 [DEBUG] switch_ivr_originate.c:3266 Originate Resulted in Success: [loopback/2500-a]
2012-01-05 13:36:08.541517 [DEBUG] switch_channel.c:3188 (loopback/2500-b) Callstate Change EARLY -> ACTIVE
2012-01-05 13:36:08.541517 [INFO] switch_channel.c:2708 loopback/2500-a Flipping CID from "" <0000000000> to "Outbound Call" <XML>
On Jan 5, 2012, at 4:17 AM, Oliver Schenk wrote:
Also, maybe I should be doing something like this:
sofia/gateway/mygatewayname/1091234567 '&managed(ivrAppName)'
instead of:
sofia/internal/1091234567@192.168.x.x '&managed(ivrAppName)'
but, I don't really have the CISCO configured as a gateway, nor do I
know how really...probably not on the right track there.
On Thu, Jan 5, 2012 at 3:06 PM, Oliver Schenk <olimonkey@gmail.com> wrote:
*bump*
So I think maybe the way I'm doing the originate is the problem? In my
call string I'm creating a connection directly from the CISCO
(192.168.x.x) to the managed application, which may be why it starts
playing straight away?
Maybe I should be originating a call first and then only once I know
the other side has picked up will I bridge the call to the IVR managed
application.
Problem is I dunno how to tell whether the other person has picked up
(or even if the cisco is going to tell me) and I don't know how to do
things to a call once it has been established.
I'm currently reading the Dialplan wiki page, hoping to get something
out of it there.
Cheers
Oliver
On Tue, Jan 3, 2012 at 11:46 AM, Oliver Schenk <olimonkey@gmail.com> wrote:
I've been battling while creating an IVR using FreeSWITCH mod_managed
and connecting through a CISCO 2811. Most things now work quite well,
but I am having a few issues with the way the system answers calls (or
doesn't answer calls...).
I have FreeSWITCH running as a windows service on Windows Server 2008,
which is connected via LAN to a CISCO 2811 with a 4 port FXO card,
which is then connected to a POTS phone line.
Take the following scenario:
1. Managed .NET application creates a call string and uses ESL to talk
to freeswitch and originate a call:
string callstring =
"{bridge_answer_timeout=20,ignore_early_media=true,call_timeout=20}sofia/internal/1091234567@192.168.x.x
'&managed(ivrAppName)'";
eslConnection.API("originate", callstring);
where 192.168.x.x is the CISCO IP.
2. The CISCO sees that the phone number (1091234567) starts with a 1
so it uses FXO port 1 and strips the 1 and uses the remaining phone
number (091234567) to make the call.
3. My phone rings, I pick up and I can hear my IVR playing.
These are my current problems:
- IVR starts playing before I even pick up the phone. This means that
if the system calls a mobile phone and the person doesn't pick up, the
IVR will start playing and eventually the mobile phone will divert to
voice mail. Obviously I then get a missed call and an sms saying I
have a new voice mail, which is annoying. Instead I would like it to
KNOW that no one has picked up, but I don't know how to do this.
Somehow the CISCO needs to be able to tell FreeSWITCH that the call
has not yet been answered. For some reason however as soon as the
CISCO starts calling FreeSWITCH thinks the call is already connected.
It doesn't know that the CISCO is actually still ringing. Maybe I'm
doing originate the wrong way or something ...
- The phone only rings for about 10 seconds before hanging up. I've
tried "call_timeout", "bridge_answer_timeout". I've also tried setting
CISCO "ring number". Nothing works, my phone still only rings for
about 10 seconds. I don't know if this is a FreeSWITCH issue or a
CISCO issue. I'm leaning towards CISCO, because FreeSWITCH IVR just
starts playing even if no one answers the phone.
CISCO Config for relevant FXO port:
voice service voip
allow-connections h323 to h323
allow-connections h323 to sip
allow-connections sip to h323
allow-connections sip to sip
no supplementary-service h450.2
no supplementary-service h450.3
supplementary-service h450.12
no supplementary-service sip moved-temporarily
no supplementary-service sip refer
fax protocol cisco
sip
registrar server expires max 3600 min 3600
no update-callerid
no call service stop
voice-port 0/3/2
output attenuation -3
no comfort-noise
cptone AU
impedance complex1
caller-id enable
!
dial-peer voice 100 pots
preference 1
destination-pattern 1T
port 0/3/2
!
Many Thanks,
Oliver
_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server
Official FreeSWITCH Sites
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
_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server
Official FreeSWITCH Sites
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
_________________________________________________________________________ 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
-- Brian West FreeSWITCH Solutions, LLC Phone: +1 (918) 420-9266 Fax: +1 (918) 420-9267 brian@freeswitch.org 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:4f06d49b32762089563979!
_________________________________________________________________________ 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
I had this in my call string: {sip_cid_type=rpid,ignore_early_media=true} Which caused the 503 Service Unavailble error. The CISCO had some errors just prior to the 503 message: Jan 9 01:30:36: //152/4620425F81D5/SIP/Info/ccsip_indicate_rt_packet_stats: Processing stats for callid=152, proc_id=9 Jan 9 01:30:38: //152/4620425F81D5/SIP/Media/sipSPIUpdateRtpSession: stun is disabled for stream:47110C14 Jan 9 01:30:38: //152/4620425F81D5/SIP/Info/ccsip_call_statistics: Requesting stats for callid=152 Jan 9 01:30:38: //152/4620425F81D5/SIP/Info/ccsip_call_statistics: Stats request failed for callid=152, dstCallID=153, rc=-7 Jan 9 01:30:38: //-1/xxxxxxxxxxxx/SIP/Event/sipSPIEventInfo: Queued event from SIP SPI : SIPSPI_EV_CC_CALL_DISCONNECT Jan 9 01:30:38: //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event: ccsip_spi_get_msg_type returned: 3 for event 7 Jan 9 01:30:38: //152/4620425F81D5/SIP/Info/act_recdinvite_disconnect: Performing disconnect Something to do with "Stats request failed for callid". Which then causes a "SIPSPI_EV_CC_CALL_DISCONNECT" event. So what I did is I removed "sip_cid_type=rpid" from my call string. Now, when I pick up the phone I just get a bit of noise, but nothing else. The CISCO does not send any SIP messages at all. It's as if it doesn't even know I picked up the phone. Does that mean the dualtone answer supervision setting in the CISCO is not working? After I hang up the phone I get: CANCEL from FS (probably due to call timeout) then the CISCO sends OK then 487 Request Cancelled then ACK from FS Output in FS just prior to my phone ringing is: 2012-01-09 11:16:03.637084 [NOTICE] switch_channel.c:816 New Channel sofia/internal/1092122856@192.168.255.1 [042f895c-4a34-4295-b250-0291a0f8b91b] 2012-01-09 11:16:07.128527 [INFO] sofia.c:740 sofia/internal/1092122856@192.168.255.1 Update Callee ID to "Outbound Call" <1092122856> 2012-01-09 11:16:07.128527 [NOTICE] sofia_glue.c:3793 Pre-Answer sofia/internal/1092122856@192.168.255.1! When I pick up the phone there is obviously no further output because the CISCO hasn't detected the pickup. Hmmmm!!! Still doing my head in. Anyone? lol On Mon, Jan 9, 2012 at 9:33 AM, Oliver Schenk <olimonkey@gmail.com> wrote:
Alright, so I tried to set ignore_early_media=true, but the phone isn't being answered at all anymore. So i went back to the CISCO and turned on debugging. I'm now getting a different sequence of events.
I still get:
INVITE from FS 100 TRYING from CISCO 183 SESSION PROGRESS from CISCO
then, when I pick up the phone I get:
503 SERVICE UNAVAILABLE from CISCO ACK from FS
I wonder what's going on now.
I'll have to play around with the "supervisiory answer dual-tone".
CISCO voice-port config:
voice-port 0/3/0 supervisory disconnect dualtone mid-call supervisory answer dualtone output attenuation -3 no comfort-noise cptone AU timeouts call-disconnect 5 timeouts wait-release 5 connection plar opx 1001 impedance complex1 caller-id enable
Cheers,
Oliver
On Sat, Jan 7, 2012 at 9:28 AM, Oliver Schenk <olimonkey@gmail.com> wrote:
No, at the time I was no longer using "ignore_early_media= true", because initially it didn't work. I was actually thinking of putting this property back in again, thanks a lot! I'll try it first thing Monday.
With regard to EXECUTE log line, either I don't have the right level of logging turned on or something else is going on, because I've never seen any such log entries before with my managed application; yet my IVR app definitely does get executed. I don't think I have the DEBUG logging output level turned on so that could explain it...
Thanks all,
Oliver
On Fri, Jan 6, 2012 at 11:21 PM, Peter Olsson <peter.olsson@visionutveckling.se> wrote:
Are you still using ignore_early_media=true - this must be set for this to work correctly.
You will see a EXECUTE log line when FS executes the application, with ignore_early_media enabled it shouldn't execute until the call has been answered. I just tried it myself, and it works as expected.
Example "originate {ignore_early_media=true}sofia/internal/number@host &park()"
Park application is only executed after the call was answered.
/Peter
________________________________________ Från: freeswitch-users-bounces@lists.freeswitch.org [freeswitch-users-bounces@lists.freeswitch.org] för Oliver Schenk [olimonkey@gmail.com] Skickat: den 6 januari 2012 12:04 Till: FreeSWITCH Users Help Ämne: Re: [Freeswitch-users] CISCO 2811 Freeswitch IVR
Because I'm using an FXO card with voice, I added something to my CISCO conf. Many others had the same thing:
voice-port 0/3/0 ... supervisory disconnect dualtone mid-call supervisory answer dualtone <---- ADDED THIS ONE ...
Once I added this, the FS output now just showed the following while the phone was ringing:
2012-01-05 16:19:31.644440 [NOTICE] switch_channel.c:816 New Channel sofia/internal/109212xxxx@192.168.x.x [69e3f13d-1e2a-409e-97a4-b5526ea6e4ec] 2012-01-05 16:19:35.124882 [INFO] sofia.c:740 sofia/internal/109212xxxx@192.168.x.x Update Callee ID to "Outbound Call" <109212xxxx> 2012-01-05 16:19:35.126883 [NOTICE] sofia_glue.c:3793 Pre-Answer sofia/internal/109212xxxx@192.168.x.x!
Where as previous it would show the above and also show the following:
2012-01-05 16:19:35.127883 [INFO] switch_channel.c:2456 sofia/internal/109212xxxx@192.168.x.x Flipping CID from "" <0000000000> to "Outbound Call" <109212xxxx> 2012-01-05 16:19:35.137384 [INFO] sofia.c:740 sofia/internal/109212xxxx@192.168.x.x Update Callee ID to "109212xxxx" <1092122856> 2012-01-05 16:19:35.138384 [NOTICE] sofia.c:5296 Channel [sofia/internal/109212xxxx@192.168.x.x] has been answered
BUT, the IVR still started playing even before I pick up the phone. Hmmmm.....so why is FS still starting the managed application when the call has not been answered yet. Are we all sure that the managed application should not be executed until the call "has been answered" shows up in the log file?
Will have to keep testing on monday as I don't have access to the CISCO from where i am now. I'll have to see whether the CISCO changes had any impact on the times at which the SIP messages are sent back and forth. Especially the 200 OK message.
Thanks again for help, maybe getting somewhere now......
Oliver
On Fri, Jan 6, 2012 at 4:20 PM, Peter Olsson <peter.olsson@visionutveckling.se> wrote:
If it sends 200 OK right after 183, this IS the problem.
200 OK means that the call was answered, it should not be sent until the call was actually picked up in the remote end. When 200 OK arrives to FS it will execute your app, and you will start playing the files.
Seems to me there is something broken in the Cisco.
/Peter
________________________________________ Från: freeswitch-users-bounces@lists.freeswitch.org [freeswitch-users-bounces@lists.freeswitch.org] för Oliver Schenk [olimonkey@gmail.com] Skickat: den 6 januari 2012 06:55 Till: FreeSWITCH Users Help Ämne: Re: [Freeswitch-users] CISCO 2811 Freeswitch IVR
I've tried looking at disable-early-media configuration command, but that didn't work and I doubt that has anything to do with the CISCO sending a 200 OK right after a 183 SESSION PROGRESS.
On Fri, Jan 6, 2012 at 9:20 AM, Brian West <brian@freeswitch.org> wrote:
Thats what the 183 is.. 180 vs 183 are kinda sketchy in some devices.. 180 is usually RINGING (generate ringback locally) while a 183 has media... aka early media and usually provides ringback inband.
/b
On Jan 5, 2012, at 7:13 PM, Oliver Schenk wrote:
Shouldn't there be a 180 RINGING somewhere in there?
On Fri, Jan 6, 2012 at 8:25 AM, Oliver Schenk <olimonkey@gmail.com> wrote:
I just noticed something else, if I don't pick up the phone at all.
The IVR just keeps playing until the menu timeout kicks in.
So here is a CISCO SIP log:
The FS server is 192.168.x.50 and the CISCO is 192.168.x.1.
I hope the CISCO log is readable, it's a bit long because I just did
"debug ccsip all".
In this test I didn't bother picking up the phone at all, but I can
see that FS answered anyway and the IVR kept playing until it timed
out.
I'm not an expert, but here is what I picked out of it:
At 00:08:10 we get a
Received: "INVITE sip:109212xxxx@192.168.x.1 SIP/2.0"
the further down at the same timestamp we get
Sent: "SIP/2.0 100 Trying"
At 00:08:13 we get a
Sent: "SIP/2.0 183 Session Progress"
At 00:18:13 we get a
Sent: "SIP/2.0 200 OK"
Then at the same timestamp we get:
Received: "ACK sip:109212xxxx@192.168.x.1:5060 SIP/2.0"
Once the IVR times out at 00:09:16 we get
Received: "BYE sip:109212xxxx@192.168.x.1:5060 SIP/2.0"
And then the reply right after
Sent: "SIP/2.0 200 OK"
So I think you were right, the CISCO is sending back an "OK" 3 seconds
after the "INVITE" is received.
The part that is beyond my field of expertise so far is WHY?
Thanks,
Oliver
On Fri, Jan 6, 2012 at 8:04 AM, Oliver Schenk <olimonkey@gmail.com> wrote:
By the way:
I tried {ignore_early_media=true} as well, but as I think we
determined, my problem is probably with the CISCO telling FS that the
call has been answered when really it hasn't yet.
On Fri, Jan 6, 2012 at 8:01 AM, Oliver Schenk <olimonkey@gmail.com> wrote:
Thanks for the help so far.
Here is a pastebin of FreeSWITCH output:
Notice how the "has been answered" log message comes immediately
(within a few milliseconds) after the call was originated. I think
this would suggest that the CISCO is immediately sending a 200 OK, as
you suggested. I also turned on CISCO debugging, but I'm just trying
to figure out how to get the information regarding SIP messages back
to Freeswitch. I'll run the test again and see if I can get some
useful CISCO debug.
Which "debug ccsip" commands are relevant to what I want for the CISCO
SIP debugging?
Thanks!
2012/1/6 Gustavo Mársico <gustavomarsico@gmail.com>:
I think I've a similar problem related to callcenter app. When I made an originate like this:
originate loopback/2500/default/XML &bridge(user/2001)
2500 is an extension that leads to a callcenter application. In this case, we dial first to the queue and when an agent answered we call to the customer. As far as I know
When the A-leg reaches to the queue, without selecting an agent, the call is automatically sent to the B-leg. As far as I see, there is a pre-answer method that fs needs to send the media to A-leg.
In order to try to avoid this, I tried using ignore_early_media=true as part of the originate in A-leg and/or B-leg, with no luck.
originate {ignore_early_media=true}loopback/2500/default/XML &bridge({ignore_early_media=true}user/2001)
Dialplan: loopback/2500-b Regex (PASS) [CallCenter_Click2Call] destination_number(2500) =~ /^(2500)$/ break=on-false
Dialplan: loopback/2500-b Action set(ignore_early_media=true)
Dialplan: loopback/2500-b Action callcenter(click2call)
2012-01-05 13:36:08.541517 [DEBUG] switch_core_state_machine.c:154 (loopback/2500-b) State Change CS_ROUTING -> CS_EXECUTE
2012-01-05 13:36:08.541517 [DEBUG] switch_core_session.c:1180 Send signal loopback/2500-b [BREAK]
2012-01-05 13:36:08.541517 [DEBUG] mod_loopback.c:475 loopback/2500-b CHANNEL KILL
2012-01-05 13:36:08.541517 [DEBUG] switch_core_state_machine.c:410 (loopback/2500-b) State ROUTING going to sleep
2012-01-05 13:36:08.541517 [DEBUG] switch_core_state_machine.c:362 (loopback/2500-b) Running State Change CS_EXECUTE
2012-01-05 13:36:08.541517 [DEBUG] switch_core_state_machine.c:417 (loopback/2500-b) State EXECUTE
2012-01-05 13:36:08.541517 [DEBUG] mod_loopback.c:375 loopback/2500-b CHANNEL EXECUTE
2012-01-05 13:36:08.541517 [DEBUG] switch_core_state_machine.c:192 loopback/2500-b Standard EXECUTE
EXECUTE loopback/2500-b set(open=true)
2012-01-05 13:36:08.541517 [DEBUG] mod_dptools.c:1286 loopback/2500-b SET [open]=[true]
EXECUTE loopback/2500-b hash(insert/10.8.0.70-spymap/0000000000/fef7d864-b3c7-407c-a6e1-94386642bfbb)
EXECUTE loopback/2500-b hash(insert/10.8.0.70-last_dial/0000000000/2500)
EXECUTE loopback/2500-b hash(insert/10.8.0.70-last_dial/global/fef7d864-b3c7-407c-a6e1-94386642bfbb)
EXECUTE loopback/2500-b set(RFC2822_DATE=Thu, 05 Jan 2012 13:36:08 -0300)
2012-01-05 13:36:08.541517 [DEBUG] mod_dptools.c:1286 loopback/2500-b SET [RFC2822_DATE]=[Thu, 05 Jan 2012 13:36:08 -0300]
EXECUTE loopback/2500-b set(ignore_early_media=true)
2012-01-05 13:36:08.541517 [DEBUG] mod_dptools.c:1286 loopback/2500-b SET [ignore_early_media]=[true]
2012-01-05 13:36:08.541517 [DEBUG] switch_core_session.c:2133 Application callcenter Requires media! pre_answering channel loopback/2500-b
2012-01-05 13:36:08.541517 [NOTICE] mod_loopback.c:760 Pre-Answer loopback/2500-a!
2012-01-05 13:36:08.541517 [DEBUG] switch_channel.c:2930 (loopback/2500-a) Callstate Change RINGING -> EARLY
2012-01-05 13:36:08.541517 [DEBUG] switch_core_session.c:729 Send signal loopback/2500-b [BREAK]
2012-01-05 13:36:08.541517 [DEBUG] mod_loopback.c:475 loopback/2500-b CHANNEL KILL
2012-01-05 13:36:08.541517 [NOTICE] switch_core_session.c:2135 Pre-Answer loopback/2500-b!
2012-01-05 13:36:08.541517 [DEBUG] switch_channel.c:2930 (loopback/2500-b) Callstate Change RINGING -> EARLY
EXECUTE loopback/2500-b callcenter(click2call)
2012-01-05 13:36:08.541517 [DEBUG] switch_channel.c:3188 (loopback/2500-a) Callstate Change EARLY -> ACTIVE
2012-01-05 13:36:08.541517 [NOTICE] mod_loopback.c:755 Channel [loopback/2500-a] has been answered
2012-01-05 13:36:08.541517 [DEBUG] switch_core_session.c:729 Send signal loopback/2500-b [BREAK]
2012-01-05 13:36:08.541517 [DEBUG] mod_loopback.c:475 loopback/2500-b CHANNEL KILL
2012-01-05 13:36:08.541517 [DEBUG] switch_ivr_originate.c:3266 Originate Resulted in Success: [loopback/2500-a]
2012-01-05 13:36:08.541517 [DEBUG] switch_channel.c:3188 (loopback/2500-b) Callstate Change EARLY -> ACTIVE
2012-01-05 13:36:08.541517 [INFO] switch_channel.c:2708 loopback/2500-a Flipping CID from "" <0000000000> to "Outbound Call" <XML>
On Jan 5, 2012, at 4:17 AM, Oliver Schenk wrote:
Also, maybe I should be doing something like this:
sofia/gateway/mygatewayname/1091234567 '&managed(ivrAppName)'
instead of:
sofia/internal/1091234567@192.168.x.x '&managed(ivrAppName)'
but, I don't really have the CISCO configured as a gateway, nor do I
know how really...probably not on the right track there.
On Thu, Jan 5, 2012 at 3:06 PM, Oliver Schenk <olimonkey@gmail.com> wrote:
*bump*
So I think maybe the way I'm doing the originate is the problem? In my
call string I'm creating a connection directly from the CISCO
(192.168.x.x) to the managed application, which may be why it starts
playing straight away?
Maybe I should be originating a call first and then only once I know
the other side has picked up will I bridge the call to the IVR managed
application.
Problem is I dunno how to tell whether the other person has picked up
(or even if the cisco is going to tell me) and I don't know how to do
things to a call once it has been established.
I'm currently reading the Dialplan wiki page, hoping to get something
out of it there.
Cheers
Oliver
On Tue, Jan 3, 2012 at 11:46 AM, Oliver Schenk <olimonkey@gmail.com> wrote:
I've been battling while creating an IVR using FreeSWITCH mod_managed
and connecting through a CISCO 2811. Most things now work quite well,
but I am having a few issues with the way the system answers calls (or
doesn't answer calls...).
I have FreeSWITCH running as a windows service on Windows Server 2008,
which is connected via LAN to a CISCO 2811 with a 4 port FXO card,
which is then connected to a POTS phone line.
Take the following scenario:
1. Managed .NET application creates a call string and uses ESL to talk
to freeswitch and originate a call:
string callstring =
"{bridge_answer_timeout=20,ignore_early_media=true,call_timeout=20}sofia/internal/1091234567@192.168.x.x
'&managed(ivrAppName)'";
eslConnection.API("originate", callstring);
where 192.168.x.x is the CISCO IP.
2. The CISCO sees that the phone number (1091234567) starts with a 1
so it uses FXO port 1 and strips the 1 and uses the remaining phone
number (091234567) to make the call.
3. My phone rings, I pick up and I can hear my IVR playing.
These are my current problems:
- IVR starts playing before I even pick up the phone. This means that
if the system calls a mobile phone and the person doesn't pick up, the
IVR will start playing and eventually the mobile phone will divert to
voice mail. Obviously I then get a missed call and an sms saying I
have a new voice mail, which is annoying. Instead I would like it to
KNOW that no one has picked up, but I don't know how to do this.
Somehow the CISCO needs to be able to tell FreeSWITCH that the call
has not yet been answered. For some reason however as soon as the
CISCO starts calling FreeSWITCH thinks the call is already connected.
It doesn't know that the CISCO is actually still ringing. Maybe I'm
doing originate the wrong way or something ...
- The phone only rings for about 10 seconds before hanging up. I've
tried "call_timeout", "bridge_answer_timeout". I've also tried setting
CISCO "ring number". Nothing works, my phone still only rings for
about 10 seconds. I don't know if this is a FreeSWITCH issue or a
CISCO issue. I'm leaning towards CISCO, because FreeSWITCH IVR just
starts playing even if no one answers the phone.
CISCO Config for relevant FXO port:
voice service voip
allow-connections h323 to h323
allow-connections h323 to sip
allow-connections sip to h323
allow-connections sip to sip
no supplementary-service h450.2
no supplementary-service h450.3
supplementary-service h450.12
no supplementary-service sip moved-temporarily
no supplementary-service sip refer
fax protocol cisco
sip
registrar server expires max 3600 min 3600
no update-callerid
no call service stop
voice-port 0/3/2
output attenuation -3
no comfort-noise
cptone AU
impedance complex1
caller-id enable
!
dial-peer voice 100 pots
preference 1
destination-pattern 1T
port 0/3/2
!
Many Thanks,
Oliver
_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server
Official FreeSWITCH Sites
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
_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server
Official FreeSWITCH Sites
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
_________________________________________________________________________ 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
-- Brian West FreeSWITCH Solutions, LLC Phone: +1 (918) 420-9266 Fax: +1 (918) 420-9267 brian@freeswitch.org 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:4f06d49b32762089563979!
_________________________________________________________________________ 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
Ok, this is starting to become 100% CISCO issue so I might have to move this topic to a CISCO forum instead. I played around with a few CISCO parameters. I added this to the voice port: voice-port 0/3/2 supervisory disconnect dualtone mid-call supervisory answer dualtone no battery-reversal Funny thing happens now. When I answer the call I have to make a noise into the phone before the CISCO actually picks up! I just had to shake my head there...and start bashing my head against the keyboard. Wouldn't that be funny... Instruction Manual: "if you hear nothing, please snap your fingers into the phone receiver and you'll hear the IVR start playing." So anyway, I tried to set: supervisory answer dualtone to supervisory answer dualtone sensitivity high That didn't make any difference. So next I added: no comfort-noise That didn't make any difference. Then I tried: battery-reversal answer As soon as I do that the CISCO once again causes FS to start playing the IVR before I even pick up the phone. So back to square one. Starting to run out of options here... On Mon, Jan 9, 2012 at 11:19 AM, Oliver Schenk <olimonkey@gmail.com> wrote:
I had this in my call string:
{sip_cid_type=rpid,ignore_early_media=true}
Which caused the 503 Service Unavailble error. The CISCO had some errors just prior to the 503 message:
Jan 9 01:30:36: //152/4620425F81D5/SIP/Info/ccsip_indicate_rt_packet_stats: Processing stats for callid=152, proc_id=9 Jan 9 01:30:38: //152/4620425F81D5/SIP/Media/sipSPIUpdateRtpSession: stun is disabled for stream:47110C14 Jan 9 01:30:38: //152/4620425F81D5/SIP/Info/ccsip_call_statistics: Requesting stats for callid=152 Jan 9 01:30:38: //152/4620425F81D5/SIP/Info/ccsip_call_statistics: Stats request failed for callid=152, dstCallID=153, rc=-7 Jan 9 01:30:38: //-1/xxxxxxxxxxxx/SIP/Event/sipSPIEventInfo: Queued event from SIP SPI : SIPSPI_EV_CC_CALL_DISCONNECT Jan 9 01:30:38: //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event: ccsip_spi_get_msg_type returned: 3 for event 7 Jan 9 01:30:38: //152/4620425F81D5/SIP/Info/act_recdinvite_disconnect: Performing disconnect
Something to do with "Stats request failed for callid". Which then causes a "SIPSPI_EV_CC_CALL_DISCONNECT" event.
So what I did is I removed "sip_cid_type=rpid" from my call string.
Now, when I pick up the phone I just get a bit of noise, but nothing else. The CISCO does not send any SIP messages at all. It's as if it doesn't even know I picked up the phone. Does that mean the dualtone answer supervision setting in the CISCO is not working?
After I hang up the phone I get:
CANCEL from FS (probably due to call timeout) then the CISCO sends OK then 487 Request Cancelled then ACK from FS
Output in FS just prior to my phone ringing is:
2012-01-09 11:16:03.637084 [NOTICE] switch_channel.c:816 New Channel sofia/internal/1092122856@192.168.255.1 [042f895c-4a34-4295-b250-0291a0f8b91b] 2012-01-09 11:16:07.128527 [INFO] sofia.c:740 sofia/internal/1092122856@192.168.255.1 Update Callee ID to "Outbound Call" <1092122856> 2012-01-09 11:16:07.128527 [NOTICE] sofia_glue.c:3793 Pre-Answer sofia/internal/1092122856@192.168.255.1!
When I pick up the phone there is obviously no further output because the CISCO hasn't detected the pickup.
Hmmmm!!! Still doing my head in.
Anyone? lol
On Mon, Jan 9, 2012 at 9:33 AM, Oliver Schenk <olimonkey@gmail.com> wrote:
Alright, so I tried to set ignore_early_media=true, but the phone isn't being answered at all anymore. So i went back to the CISCO and turned on debugging. I'm now getting a different sequence of events.
I still get:
INVITE from FS 100 TRYING from CISCO 183 SESSION PROGRESS from CISCO
then, when I pick up the phone I get:
503 SERVICE UNAVAILABLE from CISCO ACK from FS
I wonder what's going on now.
I'll have to play around with the "supervisiory answer dual-tone".
CISCO voice-port config:
voice-port 0/3/0 supervisory disconnect dualtone mid-call supervisory answer dualtone output attenuation -3 no comfort-noise cptone AU timeouts call-disconnect 5 timeouts wait-release 5 connection plar opx 1001 impedance complex1 caller-id enable
Cheers,
Oliver
On Sat, Jan 7, 2012 at 9:28 AM, Oliver Schenk <olimonkey@gmail.com> wrote:
No, at the time I was no longer using "ignore_early_media= true", because initially it didn't work. I was actually thinking of putting this property back in again, thanks a lot! I'll try it first thing Monday.
With regard to EXECUTE log line, either I don't have the right level of logging turned on or something else is going on, because I've never seen any such log entries before with my managed application; yet my IVR app definitely does get executed. I don't think I have the DEBUG logging output level turned on so that could explain it...
Thanks all,
Oliver
On Fri, Jan 6, 2012 at 11:21 PM, Peter Olsson <peter.olsson@visionutveckling.se> wrote:
Are you still using ignore_early_media=true - this must be set for this to work correctly.
You will see a EXECUTE log line when FS executes the application, with ignore_early_media enabled it shouldn't execute until the call has been answered. I just tried it myself, and it works as expected.
Example "originate {ignore_early_media=true}sofia/internal/number@host &park()"
Park application is only executed after the call was answered.
/Peter
________________________________________ Från: freeswitch-users-bounces@lists.freeswitch.org [freeswitch-users-bounces@lists.freeswitch.org] för Oliver Schenk [olimonkey@gmail.com] Skickat: den 6 januari 2012 12:04 Till: FreeSWITCH Users Help Ämne: Re: [Freeswitch-users] CISCO 2811 Freeswitch IVR
Because I'm using an FXO card with voice, I added something to my CISCO conf. Many others had the same thing:
voice-port 0/3/0 ... supervisory disconnect dualtone mid-call supervisory answer dualtone <---- ADDED THIS ONE ...
Once I added this, the FS output now just showed the following while the phone was ringing:
2012-01-05 16:19:31.644440 [NOTICE] switch_channel.c:816 New Channel sofia/internal/109212xxxx@192.168.x.x [69e3f13d-1e2a-409e-97a4-b5526ea6e4ec] 2012-01-05 16:19:35.124882 [INFO] sofia.c:740 sofia/internal/109212xxxx@192.168.x.x Update Callee ID to "Outbound Call" <109212xxxx> 2012-01-05 16:19:35.126883 [NOTICE] sofia_glue.c:3793 Pre-Answer sofia/internal/109212xxxx@192.168.x.x!
Where as previous it would show the above and also show the following:
2012-01-05 16:19:35.127883 [INFO] switch_channel.c:2456 sofia/internal/109212xxxx@192.168.x.x Flipping CID from "" <0000000000> to "Outbound Call" <109212xxxx> 2012-01-05 16:19:35.137384 [INFO] sofia.c:740 sofia/internal/109212xxxx@192.168.x.x Update Callee ID to "109212xxxx" <1092122856> 2012-01-05 16:19:35.138384 [NOTICE] sofia.c:5296 Channel [sofia/internal/109212xxxx@192.168.x.x] has been answered
BUT, the IVR still started playing even before I pick up the phone. Hmmmm.....so why is FS still starting the managed application when the call has not been answered yet. Are we all sure that the managed application should not be executed until the call "has been answered" shows up in the log file?
Will have to keep testing on monday as I don't have access to the CISCO from where i am now. I'll have to see whether the CISCO changes had any impact on the times at which the SIP messages are sent back and forth. Especially the 200 OK message.
Thanks again for help, maybe getting somewhere now......
Oliver
On Fri, Jan 6, 2012 at 4:20 PM, Peter Olsson <peter.olsson@visionutveckling.se> wrote:
If it sends 200 OK right after 183, this IS the problem.
200 OK means that the call was answered, it should not be sent until the call was actually picked up in the remote end. When 200 OK arrives to FS it will execute your app, and you will start playing the files.
Seems to me there is something broken in the Cisco.
/Peter
________________________________________ Från: freeswitch-users-bounces@lists.freeswitch.org [freeswitch-users-bounces@lists.freeswitch.org] för Oliver Schenk [olimonkey@gmail.com] Skickat: den 6 januari 2012 06:55 Till: FreeSWITCH Users Help Ämne: Re: [Freeswitch-users] CISCO 2811 Freeswitch IVR
I've tried looking at disable-early-media configuration command, but that didn't work and I doubt that has anything to do with the CISCO sending a 200 OK right after a 183 SESSION PROGRESS.
On Fri, Jan 6, 2012 at 9:20 AM, Brian West <brian@freeswitch.org> wrote:
Thats what the 183 is.. 180 vs 183 are kinda sketchy in some devices.. 180 is usually RINGING (generate ringback locally) while a 183 has media... aka early media and usually provides ringback inband.
/b
On Jan 5, 2012, at 7:13 PM, Oliver Schenk wrote:
Shouldn't there be a 180 RINGING somewhere in there?
On Fri, Jan 6, 2012 at 8:25 AM, Oliver Schenk <olimonkey@gmail.com> wrote:
I just noticed something else, if I don't pick up the phone at all.
The IVR just keeps playing until the menu timeout kicks in.
So here is a CISCO SIP log:
The FS server is 192.168.x.50 and the CISCO is 192.168.x.1.
I hope the CISCO log is readable, it's a bit long because I just did
"debug ccsip all".
In this test I didn't bother picking up the phone at all, but I can
see that FS answered anyway and the IVR kept playing until it timed
out.
I'm not an expert, but here is what I picked out of it:
At 00:08:10 we get a
Received: "INVITE sip:109212xxxx@192.168.x.1 SIP/2.0"
the further down at the same timestamp we get
Sent: "SIP/2.0 100 Trying"
At 00:08:13 we get a
Sent: "SIP/2.0 183 Session Progress"
At 00:18:13 we get a
Sent: "SIP/2.0 200 OK"
Then at the same timestamp we get:
Received: "ACK sip:109212xxxx@192.168.x.1:5060 SIP/2.0"
Once the IVR times out at 00:09:16 we get
Received: "BYE sip:109212xxxx@192.168.x.1:5060 SIP/2.0"
And then the reply right after
Sent: "SIP/2.0 200 OK"
So I think you were right, the CISCO is sending back an "OK" 3 seconds
after the "INVITE" is received.
The part that is beyond my field of expertise so far is WHY?
Thanks,
Oliver
On Fri, Jan 6, 2012 at 8:04 AM, Oliver Schenk <olimonkey@gmail.com> wrote:
By the way:
I tried {ignore_early_media=true} as well, but as I think we
determined, my problem is probably with the CISCO telling FS that the
call has been answered when really it hasn't yet.
On Fri, Jan 6, 2012 at 8:01 AM, Oliver Schenk <olimonkey@gmail.com> wrote:
Thanks for the help so far.
Here is a pastebin of FreeSWITCH output:
Notice how the "has been answered" log message comes immediately
(within a few milliseconds) after the call was originated. I think
this would suggest that the CISCO is immediately sending a 200 OK, as
you suggested. I also turned on CISCO debugging, but I'm just trying
to figure out how to get the information regarding SIP messages back
to Freeswitch. I'll run the test again and see if I can get some
useful CISCO debug.
Which "debug ccsip" commands are relevant to what I want for the CISCO
SIP debugging?
Thanks!
2012/1/6 Gustavo Mársico <gustavomarsico@gmail.com>:
I think I've a similar problem related to callcenter app. When I made an originate like this:
originate loopback/2500/default/XML &bridge(user/2001)
2500 is an extension that leads to a callcenter application. In this case, we dial first to the queue and when an agent answered we call to the customer. As far as I know
When the A-leg reaches to the queue, without selecting an agent, the call is automatically sent to the B-leg. As far as I see, there is a pre-answer method that fs needs to send the media to A-leg.
In order to try to avoid this, I tried using ignore_early_media=true as part of the originate in A-leg and/or B-leg, with no luck.
originate {ignore_early_media=true}loopback/2500/default/XML &bridge({ignore_early_media=true}user/2001)
Dialplan: loopback/2500-b Regex (PASS) [CallCenter_Click2Call] destination_number(2500) =~ /^(2500)$/ break=on-false
Dialplan: loopback/2500-b Action set(ignore_early_media=true)
Dialplan: loopback/2500-b Action callcenter(click2call)
2012-01-05 13:36:08.541517 [DEBUG] switch_core_state_machine.c:154 (loopback/2500-b) State Change CS_ROUTING -> CS_EXECUTE
2012-01-05 13:36:08.541517 [DEBUG] switch_core_session.c:1180 Send signal loopback/2500-b [BREAK]
2012-01-05 13:36:08.541517 [DEBUG] mod_loopback.c:475 loopback/2500-b CHANNEL KILL
2012-01-05 13:36:08.541517 [DEBUG] switch_core_state_machine.c:410 (loopback/2500-b) State ROUTING going to sleep
2012-01-05 13:36:08.541517 [DEBUG] switch_core_state_machine.c:362 (loopback/2500-b) Running State Change CS_EXECUTE
2012-01-05 13:36:08.541517 [DEBUG] switch_core_state_machine.c:417 (loopback/2500-b) State EXECUTE
2012-01-05 13:36:08.541517 [DEBUG] mod_loopback.c:375 loopback/2500-b CHANNEL EXECUTE
2012-01-05 13:36:08.541517 [DEBUG] switch_core_state_machine.c:192 loopback/2500-b Standard EXECUTE
EXECUTE loopback/2500-b set(open=true)
2012-01-05 13:36:08.541517 [DEBUG] mod_dptools.c:1286 loopback/2500-b SET [open]=[true]
EXECUTE loopback/2500-b hash(insert/10.8.0.70-spymap/0000000000/fef7d864-b3c7-407c-a6e1-94386642bfbb)
EXECUTE loopback/2500-b hash(insert/10.8.0.70-last_dial/0000000000/2500)
EXECUTE loopback/2500-b hash(insert/10.8.0.70-last_dial/global/fef7d864-b3c7-407c-a6e1-94386642bfbb)
EXECUTE loopback/2500-b set(RFC2822_DATE=Thu, 05 Jan 2012 13:36:08 -0300)
2012-01-05 13:36:08.541517 [DEBUG] mod_dptools.c:1286 loopback/2500-b SET [RFC2822_DATE]=[Thu, 05 Jan 2012 13:36:08 -0300]
EXECUTE loopback/2500-b set(ignore_early_media=true)
2012-01-05 13:36:08.541517 [DEBUG] mod_dptools.c:1286 loopback/2500-b SET [ignore_early_media]=[true]
2012-01-05 13:36:08.541517 [DEBUG] switch_core_session.c:2133 Application callcenter Requires media! pre_answering channel loopback/2500-b
2012-01-05 13:36:08.541517 [NOTICE] mod_loopback.c:760 Pre-Answer loopback/2500-a!
2012-01-05 13:36:08.541517 [DEBUG] switch_channel.c:2930 (loopback/2500-a) Callstate Change RINGING -> EARLY
2012-01-05 13:36:08.541517 [DEBUG] switch_core_session.c:729 Send signal loopback/2500-b [BREAK]
2012-01-05 13:36:08.541517 [DEBUG] mod_loopback.c:475 loopback/2500-b CHANNEL KILL
2012-01-05 13:36:08.541517 [NOTICE] switch_core_session.c:2135 Pre-Answer loopback/2500-b!
2012-01-05 13:36:08.541517 [DEBUG] switch_channel.c:2930 (loopback/2500-b) Callstate Change RINGING -> EARLY
EXECUTE loopback/2500-b callcenter(click2call)
2012-01-05 13:36:08.541517 [DEBUG] switch_channel.c:3188 (loopback/2500-a) Callstate Change EARLY -> ACTIVE
2012-01-05 13:36:08.541517 [NOTICE] mod_loopback.c:755 Channel [loopback/2500-a] has been answered
2012-01-05 13:36:08.541517 [DEBUG] switch_core_session.c:729 Send signal loopback/2500-b [BREAK]
2012-01-05 13:36:08.541517 [DEBUG] mod_loopback.c:475 loopback/2500-b CHANNEL KILL
2012-01-05 13:36:08.541517 [DEBUG] switch_ivr_originate.c:3266 Originate Resulted in Success: [loopback/2500-a]
2012-01-05 13:36:08.541517 [DEBUG] switch_channel.c:3188 (loopback/2500-b) Callstate Change EARLY -> ACTIVE
2012-01-05 13:36:08.541517 [INFO] switch_channel.c:2708 loopback/2500-a Flipping CID from "" <0000000000> to "Outbound Call" <XML>
On Jan 5, 2012, at 4:17 AM, Oliver Schenk wrote:
Also, maybe I should be doing something like this:
sofia/gateway/mygatewayname/1091234567 '&managed(ivrAppName)'
instead of:
sofia/internal/1091234567@192.168.x.x '&managed(ivrAppName)'
but, I don't really have the CISCO configured as a gateway, nor do I
know how really...probably not on the right track there.
On Thu, Jan 5, 2012 at 3:06 PM, Oliver Schenk <olimonkey@gmail.com> wrote:
*bump*
So I think maybe the way I'm doing the originate is the problem? In my
call string I'm creating a connection directly from the CISCO
(192.168.x.x) to the managed application, which may be why it starts
playing straight away?
Maybe I should be originating a call first and then only once I know
the other side has picked up will I bridge the call to the IVR managed
application.
Problem is I dunno how to tell whether the other person has picked up
(or even if the cisco is going to tell me) and I don't know how to do
things to a call once it has been established.
I'm currently reading the Dialplan wiki page, hoping to get something
out of it there.
Cheers
Oliver
On Tue, Jan 3, 2012 at 11:46 AM, Oliver Schenk <olimonkey@gmail.com> wrote:
I've been battling while creating an IVR using FreeSWITCH mod_managed
and connecting through a CISCO 2811. Most things now work quite well,
but I am having a few issues with the way the system answers calls (or
doesn't answer calls...).
I have FreeSWITCH running as a windows service on Windows Server 2008,
which is connected via LAN to a CISCO 2811 with a 4 port FXO card,
which is then connected to a POTS phone line.
Take the following scenario:
1. Managed .NET application creates a call string and uses ESL to talk
to freeswitch and originate a call:
string callstring =
"{bridge_answer_timeout=20,ignore_early_media=true,call_timeout=20}sofia/internal/1091234567@192.168.x.x
'&managed(ivrAppName)'";
eslConnection.API("originate", callstring);
where 192.168.x.x is the CISCO IP.
2. The CISCO sees that the phone number (1091234567) starts with a 1
so it uses FXO port 1 and strips the 1 and uses the remaining phone
number (091234567) to make the call.
3. My phone rings, I pick up and I can hear my IVR playing.
These are my current problems:
- IVR starts playing before I even pick up the phone. This means that
if the system calls a mobile phone and the person doesn't pick up, the
IVR will start playing and eventually the mobile phone will divert to
voice mail. Obviously I then get a missed call and an sms saying I
have a new voice mail, which is annoying. Instead I would like it to
KNOW that no one has picked up, but I don't know how to do this.
Somehow the CISCO needs to be able to tell FreeSWITCH that the call
has not yet been answered. For some reason however as soon as the
CISCO starts calling FreeSWITCH thinks the call is already connected.
It doesn't know that the CISCO is actually still ringing. Maybe I'm
doing originate the wrong way or something ...
- The phone only rings for about 10 seconds before hanging up. I've
tried "call_timeout", "bridge_answer_timeout". I've also tried setting
CISCO "ring number". Nothing works, my phone still only rings for
about 10 seconds. I don't know if this is a FreeSWITCH issue or a
CISCO issue. I'm leaning towards CISCO, because FreeSWITCH IVR just
starts playing even if no one answers the phone.
CISCO Config for relevant FXO port:
voice service voip
allow-connections h323 to h323
allow-connections h323 to sip
allow-connections sip to h323
allow-connections sip to sip
no supplementary-service h450.2
no supplementary-service h450.3
supplementary-service h450.12
no supplementary-service sip moved-temporarily
no supplementary-service sip refer
fax protocol cisco
sip
registrar server expires max 3600 min 3600
no update-callerid
no call service stop
voice-port 0/3/2
output attenuation -3
no comfort-noise
cptone AU
impedance complex1
caller-id enable
!
dial-peer voice 100 pots
preference 1
destination-pattern 1T
port 0/3/2
!
Many Thanks,
Oliver
_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server
Official FreeSWITCH Sites
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
_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server
Official FreeSWITCH Sites
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
_________________________________________________________________________ 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
-- Brian West FreeSWITCH Solutions, LLC Phone: +1 (918) 420-9266 Fax: +1 (918) 420-9267 brian@freeswitch.org 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:4f06d49b32762089563979!
_________________________________________________________________________ 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
https://supportforums.cisco.com/message/3529491 On Mon, Jan 9, 2012 at 2:25 PM, Oliver Schenk <olimonkey@gmail.com> wrote:
Ok, this is starting to become 100% CISCO issue so I might have to move this topic to a CISCO forum instead. I played around with a few CISCO parameters.
I added this to the voice port:
voice-port 0/3/2 supervisory disconnect dualtone mid-call supervisory answer dualtone no battery-reversal
Funny thing happens now. When I answer the call I have to make a noise into the phone before the CISCO actually picks up! I just had to shake my head there...and start bashing my head against the keyboard. Wouldn't that be funny... Instruction Manual: "if you hear nothing, please snap your fingers into the phone receiver and you'll hear the IVR start playing."
So anyway, I tried to set:
supervisory answer dualtone
to
supervisory answer dualtone sensitivity high
That didn't make any difference.
So next I added:
no comfort-noise
That didn't make any difference.
Then I tried:
battery-reversal answer
As soon as I do that the CISCO once again causes FS to start playing the IVR before I even pick up the phone. So back to square one.
Starting to run out of options here...
On Mon, Jan 9, 2012 at 11:19 AM, Oliver Schenk <olimonkey@gmail.com> wrote:
I had this in my call string:
{sip_cid_type=rpid,ignore_early_media=true}
Which caused the 503 Service Unavailble error. The CISCO had some errors just prior to the 503 message:
Jan 9 01:30:36: //152/4620425F81D5/SIP/Info/ccsip_indicate_rt_packet_stats: Processing stats for callid=152, proc_id=9 Jan 9 01:30:38: //152/4620425F81D5/SIP/Media/sipSPIUpdateRtpSession: stun is disabled for stream:47110C14 Jan 9 01:30:38: //152/4620425F81D5/SIP/Info/ccsip_call_statistics: Requesting stats for callid=152 Jan 9 01:30:38: //152/4620425F81D5/SIP/Info/ccsip_call_statistics: Stats request failed for callid=152, dstCallID=153, rc=-7 Jan 9 01:30:38: //-1/xxxxxxxxxxxx/SIP/Event/sipSPIEventInfo: Queued event from SIP SPI : SIPSPI_EV_CC_CALL_DISCONNECT Jan 9 01:30:38: //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event: ccsip_spi_get_msg_type returned: 3 for event 7 Jan 9 01:30:38: //152/4620425F81D5/SIP/Info/act_recdinvite_disconnect: Performing disconnect
Something to do with "Stats request failed for callid". Which then causes a "SIPSPI_EV_CC_CALL_DISCONNECT" event.
So what I did is I removed "sip_cid_type=rpid" from my call string.
Now, when I pick up the phone I just get a bit of noise, but nothing else. The CISCO does not send any SIP messages at all. It's as if it doesn't even know I picked up the phone. Does that mean the dualtone answer supervision setting in the CISCO is not working?
After I hang up the phone I get:
CANCEL from FS (probably due to call timeout) then the CISCO sends OK then 487 Request Cancelled then ACK from FS
Output in FS just prior to my phone ringing is:
2012-01-09 11:16:03.637084 [NOTICE] switch_channel.c:816 New Channel sofia/internal/1092122856@192.168.255.1 [042f895c-4a34-4295-b250-0291a0f8b91b] 2012-01-09 11:16:07.128527 [INFO] sofia.c:740 sofia/internal/1092122856@192.168.255.1 Update Callee ID to "Outbound Call" <1092122856> 2012-01-09 11:16:07.128527 [NOTICE] sofia_glue.c:3793 Pre-Answer sofia/internal/1092122856@192.168.255.1!
When I pick up the phone there is obviously no further output because the CISCO hasn't detected the pickup.
Hmmmm!!! Still doing my head in.
Anyone? lol
On Mon, Jan 9, 2012 at 9:33 AM, Oliver Schenk <olimonkey@gmail.com> wrote:
Alright, so I tried to set ignore_early_media=true, but the phone isn't being answered at all anymore. So i went back to the CISCO and turned on debugging. I'm now getting a different sequence of events.
I still get:
INVITE from FS 100 TRYING from CISCO 183 SESSION PROGRESS from CISCO
then, when I pick up the phone I get:
503 SERVICE UNAVAILABLE from CISCO ACK from FS
I wonder what's going on now.
I'll have to play around with the "supervisiory answer dual-tone".
CISCO voice-port config:
voice-port 0/3/0 supervisory disconnect dualtone mid-call supervisory answer dualtone output attenuation -3 no comfort-noise cptone AU timeouts call-disconnect 5 timeouts wait-release 5 connection plar opx 1001 impedance complex1 caller-id enable
Cheers,
Oliver
On Sat, Jan 7, 2012 at 9:28 AM, Oliver Schenk <olimonkey@gmail.com> wrote:
No, at the time I was no longer using "ignore_early_media= true", because initially it didn't work. I was actually thinking of putting this property back in again, thanks a lot! I'll try it first thing Monday.
With regard to EXECUTE log line, either I don't have the right level of logging turned on or something else is going on, because I've never seen any such log entries before with my managed application; yet my IVR app definitely does get executed. I don't think I have the DEBUG logging output level turned on so that could explain it...
Thanks all,
Oliver
On Fri, Jan 6, 2012 at 11:21 PM, Peter Olsson <peter.olsson@visionutveckling.se> wrote:
Are you still using ignore_early_media=true - this must be set for this to work correctly.
You will see a EXECUTE log line when FS executes the application, with ignore_early_media enabled it shouldn't execute until the call has been answered. I just tried it myself, and it works as expected.
Example "originate {ignore_early_media=true}sofia/internal/number@host &park()"
Park application is only executed after the call was answered.
/Peter
________________________________________ Från: freeswitch-users-bounces@lists.freeswitch.org [freeswitch-users-bounces@lists.freeswitch.org] för Oliver Schenk [olimonkey@gmail.com] Skickat: den 6 januari 2012 12:04 Till: FreeSWITCH Users Help Ämne: Re: [Freeswitch-users] CISCO 2811 Freeswitch IVR
Because I'm using an FXO card with voice, I added something to my CISCO conf. Many others had the same thing:
voice-port 0/3/0 ... supervisory disconnect dualtone mid-call supervisory answer dualtone <---- ADDED THIS ONE ...
Once I added this, the FS output now just showed the following while the phone was ringing:
2012-01-05 16:19:31.644440 [NOTICE] switch_channel.c:816 New Channel sofia/internal/109212xxxx@192.168.x.x [69e3f13d-1e2a-409e-97a4-b5526ea6e4ec] 2012-01-05 16:19:35.124882 [INFO] sofia.c:740 sofia/internal/109212xxxx@192.168.x.x Update Callee ID to "Outbound Call" <109212xxxx> 2012-01-05 16:19:35.126883 [NOTICE] sofia_glue.c:3793 Pre-Answer sofia/internal/109212xxxx@192.168.x.x!
Where as previous it would show the above and also show the following:
2012-01-05 16:19:35.127883 [INFO] switch_channel.c:2456 sofia/internal/109212xxxx@192.168.x.x Flipping CID from "" <0000000000> to "Outbound Call" <109212xxxx> 2012-01-05 16:19:35.137384 [INFO] sofia.c:740 sofia/internal/109212xxxx@192.168.x.x Update Callee ID to "109212xxxx" <1092122856> 2012-01-05 16:19:35.138384 [NOTICE] sofia.c:5296 Channel [sofia/internal/109212xxxx@192.168.x.x] has been answered
BUT, the IVR still started playing even before I pick up the phone. Hmmmm.....so why is FS still starting the managed application when the call has not been answered yet. Are we all sure that the managed application should not be executed until the call "has been answered" shows up in the log file?
Will have to keep testing on monday as I don't have access to the CISCO from where i am now. I'll have to see whether the CISCO changes had any impact on the times at which the SIP messages are sent back and forth. Especially the 200 OK message.
Thanks again for help, maybe getting somewhere now......
Oliver
On Fri, Jan 6, 2012 at 4:20 PM, Peter Olsson <peter.olsson@visionutveckling.se> wrote:
If it sends 200 OK right after 183, this IS the problem.
200 OK means that the call was answered, it should not be sent until the call was actually picked up in the remote end. When 200 OK arrives to FS it will execute your app, and you will start playing the files.
Seems to me there is something broken in the Cisco.
/Peter
________________________________________ Från: freeswitch-users-bounces@lists.freeswitch.org [freeswitch-users-bounces@lists.freeswitch.org] för Oliver Schenk [olimonkey@gmail.com] Skickat: den 6 januari 2012 06:55 Till: FreeSWITCH Users Help Ämne: Re: [Freeswitch-users] CISCO 2811 Freeswitch IVR
I've tried looking at disable-early-media configuration command, but that didn't work and I doubt that has anything to do with the CISCO sending a 200 OK right after a 183 SESSION PROGRESS.
On Fri, Jan 6, 2012 at 9:20 AM, Brian West <brian@freeswitch.org> wrote: > Thats what the 183 is.. 180 vs 183 are kinda sketchy in some devices.. 180 > is usually RINGING (generate ringback locally) while a 183 has media... aka > early media and usually provides ringback inband. > > /b > > On Jan 5, 2012, at 7:13 PM, Oliver Schenk wrote: > > Shouldn't there be a 180 RINGING somewhere in there? > > > > > On Fri, Jan 6, 2012 at 8:25 AM, Oliver Schenk <olimonkey@gmail.com> wrote: > > I just noticed something else, if I don't pick up the phone at all. > > The IVR just keeps playing until the menu timeout kicks in. > > > So here is a CISCO SIP log: > > http://pastebin.com/Y9sYkuxi > > > The FS server is 192.168.x.50 and the CISCO is 192.168.x.1. > > I hope the CISCO log is readable, it's a bit long because I just did > > "debug ccsip all". > > > > > In this test I didn't bother picking up the phone at all, but I can > > see that FS answered anyway and the IVR kept playing until it timed > > out. > > I'm not an expert, but here is what I picked out of it: > > > At 00:08:10 we get a > > Received: "INVITE sip:109212xxxx@192.168.x.1 SIP/2.0" > > > the further down at the same timestamp we get > > Sent: "SIP/2.0 100 Trying" > > > At 00:08:13 we get a > > Sent: "SIP/2.0 183 Session Progress" > > > At 00:18:13 we get a > > Sent: "SIP/2.0 200 OK" > > > Then at the same timestamp we get: > > Received: "ACK sip:109212xxxx@192.168.x.1:5060 SIP/2.0" > > > > > Once the IVR times out at 00:09:16 we get > > Received: "BYE sip:109212xxxx@192.168.x.1:5060 SIP/2.0" > > > And then the reply right after > > Sent: "SIP/2.0 200 OK" > > > > > So I think you were right, the CISCO is sending back an "OK" 3 seconds > > after the "INVITE" is received. > > > > > The part that is beyond my field of expertise so far is WHY? > > > > > Thanks, > > > > Oliver > > > > > On Fri, Jan 6, 2012 at 8:04 AM, Oliver Schenk <olimonkey@gmail.com> wrote: > > By the way: > > > I tried {ignore_early_media=true} as well, but as I think we > > determined, my problem is probably with the CISCO telling FS that the > > call has been answered when really it hasn't yet. > > > > > On Fri, Jan 6, 2012 at 8:01 AM, Oliver Schenk <olimonkey@gmail.com> wrote: > > Thanks for the help so far. > > > > Here is a pastebin of FreeSWITCH output: > > http://pastebin.com/i6Qgc7ws > > > Notice how the "has been answered" log message comes immediately > > (within a few milliseconds) after the call was originated. I think > > this would suggest that the CISCO is immediately sending a 200 OK, as > > you suggested. I also turned on CISCO debugging, but I'm just trying > > to figure out how to get the information regarding SIP messages back > > to Freeswitch. I'll run the test again and see if I can get some > > useful CISCO debug. > > > Which "debug ccsip" commands are relevant to what I want for the CISCO > > SIP debugging? > > > > Thanks! > > > > > > 2012/1/6 Gustavo Mársico <gustavomarsico@gmail.com>: > > I think I've a similar problem related to callcenter app. When I made an > originate like this: > > > originate loopback/2500/default/XML &bridge(user/2001) > > > 2500 is an extension that leads to a callcenter application. In this case, > we dial first to the queue and when an agent answered we call to the > customer. As far as I know > > When the A-leg reaches to the queue, without selecting an agent, the call is > automatically sent to the B-leg. As far as I see, there is a pre-answer > method that fs needs to send the media to A-leg. > > In order to try to avoid this, I tried using ignore_early_media=true as part > of the originate in A-leg and/or B-leg, with no luck. > > > originate {ignore_early_media=true}loopback/2500/default/XML > &bridge({ignore_early_media=true}user/2001) > > > Dialplan: loopback/2500-b Regex (PASS) [CallCenter_Click2Call] > destination_number(2500) =~ /^(2500)$/ break=on-false > > Dialplan: loopback/2500-b Action set(ignore_early_media=true) > > Dialplan: loopback/2500-b Action callcenter(click2call) > > 2012-01-05 13:36:08.541517 [DEBUG] switch_core_state_machine.c:154 > (loopback/2500-b) State Change CS_ROUTING -> CS_EXECUTE > > 2012-01-05 13:36:08.541517 [DEBUG] switch_core_session.c:1180 Send signal > loopback/2500-b [BREAK] > > 2012-01-05 13:36:08.541517 [DEBUG] mod_loopback.c:475 loopback/2500-b > CHANNEL KILL > > 2012-01-05 13:36:08.541517 [DEBUG] switch_core_state_machine.c:410 > (loopback/2500-b) State ROUTING going to sleep > > 2012-01-05 13:36:08.541517 [DEBUG] switch_core_state_machine.c:362 > (loopback/2500-b) Running State Change CS_EXECUTE > > 2012-01-05 13:36:08.541517 [DEBUG] switch_core_state_machine.c:417 > (loopback/2500-b) State EXECUTE > > 2012-01-05 13:36:08.541517 [DEBUG] mod_loopback.c:375 loopback/2500-b > CHANNEL EXECUTE > > 2012-01-05 13:36:08.541517 [DEBUG] switch_core_state_machine.c:192 > loopback/2500-b Standard EXECUTE > > EXECUTE loopback/2500-b set(open=true) > > 2012-01-05 13:36:08.541517 [DEBUG] mod_dptools.c:1286 loopback/2500-b SET > [open]=[true] > > EXECUTE loopback/2500-b > hash(insert/10.8.0.70-spymap/0000000000/fef7d864-b3c7-407c-a6e1-94386642bfbb) > > EXECUTE loopback/2500-b hash(insert/10.8.0.70-last_dial/0000000000/2500) > > EXECUTE loopback/2500-b > hash(insert/10.8.0.70-last_dial/global/fef7d864-b3c7-407c-a6e1-94386642bfbb) > > EXECUTE loopback/2500-b set(RFC2822_DATE=Thu, 05 Jan 2012 13:36:08 -0300) > > 2012-01-05 13:36:08.541517 [DEBUG] mod_dptools.c:1286 loopback/2500-b SET > [RFC2822_DATE]=[Thu, 05 Jan 2012 13:36:08 -0300] > > EXECUTE loopback/2500-b set(ignore_early_media=true) > > 2012-01-05 13:36:08.541517 [DEBUG] mod_dptools.c:1286 loopback/2500-b SET > [ignore_early_media]=[true] > > 2012-01-05 13:36:08.541517 [DEBUG] switch_core_session.c:2133 Application > callcenter Requires media! pre_answering channel loopback/2500-b > > 2012-01-05 13:36:08.541517 [NOTICE] mod_loopback.c:760 Pre-Answer > loopback/2500-a! > > 2012-01-05 13:36:08.541517 [DEBUG] switch_channel.c:2930 (loopback/2500-a) > Callstate Change RINGING -> EARLY > > 2012-01-05 13:36:08.541517 [DEBUG] switch_core_session.c:729 Send signal > loopback/2500-b [BREAK] > > 2012-01-05 13:36:08.541517 [DEBUG] mod_loopback.c:475 loopback/2500-b > CHANNEL KILL > > 2012-01-05 13:36:08.541517 [NOTICE] switch_core_session.c:2135 Pre-Answer > loopback/2500-b! > > 2012-01-05 13:36:08.541517 [DEBUG] switch_channel.c:2930 (loopback/2500-b) > Callstate Change RINGING -> EARLY > > EXECUTE loopback/2500-b callcenter(click2call) > > 2012-01-05 13:36:08.541517 [DEBUG] switch_channel.c:3188 (loopback/2500-a) > Callstate Change EARLY -> ACTIVE > > 2012-01-05 13:36:08.541517 [NOTICE] mod_loopback.c:755 Channel > [loopback/2500-a] has been answered > > 2012-01-05 13:36:08.541517 [DEBUG] switch_core_session.c:729 Send signal > loopback/2500-b [BREAK] > > 2012-01-05 13:36:08.541517 [DEBUG] mod_loopback.c:475 loopback/2500-b > CHANNEL KILL > > 2012-01-05 13:36:08.541517 [DEBUG] switch_ivr_originate.c:3266 Originate > Resulted in Success: [loopback/2500-a] > > 2012-01-05 13:36:08.541517 [DEBUG] switch_channel.c:3188 (loopback/2500-b) > Callstate Change EARLY -> ACTIVE > > 2012-01-05 13:36:08.541517 [INFO] switch_channel.c:2708 loopback/2500-a > Flipping CID from "" <0000000000> to "Outbound Call" <XML> > > > > > > On Jan 5, 2012, at 4:17 AM, Oliver Schenk wrote: > > > Also, maybe I should be doing something like this: > > > sofia/gateway/mygatewayname/1091234567 '&managed(ivrAppName)' > > > instead of: > > > sofia/internal/1091234567@192.168.x.x '&managed(ivrAppName)' > > > > but, I don't really have the CISCO configured as a gateway, nor do I > > know how really...probably not on the right track there. > > > > > > On Thu, Jan 5, 2012 at 3:06 PM, Oliver Schenk <olimonkey@gmail.com> wrote: > > *bump* > > > > So I think maybe the way I'm doing the originate is the problem? In my > > call string I'm creating a connection directly from the CISCO > > (192.168.x.x) to the managed application, which may be why it starts > > playing straight away? > > > Maybe I should be originating a call first and then only once I know > > the other side has picked up will I bridge the call to the IVR managed > > application. > > > Problem is I dunno how to tell whether the other person has picked up > > (or even if the cisco is going to tell me) and I don't know how to do > > things to a call once it has been established. > > > > I'm currently reading the Dialplan wiki page, hoping to get something > > out of it there. > > > > Cheers > > > Oliver > > > > On Tue, Jan 3, 2012 at 11:46 AM, Oliver Schenk <olimonkey@gmail.com> wrote: > > I've been battling while creating an IVR using FreeSWITCH mod_managed > > and connecting through a CISCO 2811. Most things now work quite well, > > but I am having a few issues with the way the system answers calls (or > > doesn't answer calls...). > > > I have FreeSWITCH running as a windows service on Windows Server 2008, > > which is connected via LAN to a CISCO 2811 with a 4 port FXO card, > > which is then connected to a POTS phone line. > > > > Take the following scenario: > > > 1. Managed .NET application creates a call string and uses ESL to talk > > to freeswitch and originate a call: > > > string callstring = > > "{bridge_answer_timeout=20,ignore_early_media=true,call_timeout=20}sofia/internal/1091234567@192.168.x.x > > '&managed(ivrAppName)'"; > > eslConnection.API("originate", callstring); > > > where 192.168.x.x is the CISCO IP. > > > 2. The CISCO sees that the phone number (1091234567) starts with a 1 > > so it uses FXO port 1 and strips the 1 and uses the remaining phone > > number (091234567) to make the call. > > > 3. My phone rings, I pick up and I can hear my IVR playing. > > > > > These are my current problems: > > > - IVR starts playing before I even pick up the phone. This means that > > if the system calls a mobile phone and the person doesn't pick up, the > > IVR will start playing and eventually the mobile phone will divert to > > voice mail. Obviously I then get a missed call and an sms saying I > > have a new voice mail, which is annoying. Instead I would like it to > > KNOW that no one has picked up, but I don't know how to do this. > > Somehow the CISCO needs to be able to tell FreeSWITCH that the call > > has not yet been answered. For some reason however as soon as the > > CISCO starts calling FreeSWITCH thinks the call is already connected. > > It doesn't know that the CISCO is actually still ringing. Maybe I'm > > doing originate the wrong way or something ... > > > - The phone only rings for about 10 seconds before hanging up. I've > > tried "call_timeout", "bridge_answer_timeout". I've also tried setting > > CISCO "ring number". Nothing works, my phone still only rings for > > about 10 seconds. I don't know if this is a FreeSWITCH issue or a > > CISCO issue. I'm leaning towards CISCO, because FreeSWITCH IVR just > > starts playing even if no one answers the phone. > > > > > > > CISCO Config for relevant FXO port: > > > voice service voip > > allow-connections h323 to h323 > > allow-connections h323 to sip > > allow-connections sip to h323 > > allow-connections sip to sip > > no supplementary-service h450.2 > > no supplementary-service h450.3 > > supplementary-service h450.12 > > no supplementary-service sip moved-temporarily > > no supplementary-service sip refer > > fax protocol cisco > > sip > > registrar server expires max 3600 min 3600 > > no update-callerid > > no call service stop > > > voice-port 0/3/2 > > output attenuation -3 > > no comfort-noise > > cptone AU > > impedance complex1 > > caller-id enable > > ! > > dial-peer voice 100 pots > > preference 1 > > destination-pattern 1T > > port 0/3/2 > > ! > > > > > Many Thanks, > > > Oliver > > > _________________________________________________________________________ > > 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 > > > -- > Brian West > FreeSWITCH Solutions, LLC > Phone: +1 (918) 420-9266 > Fax: +1 (918) 420-9267 > brian@freeswitch.org > 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:4f06d49b32762089563979!
_________________________________________________________________________ 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
I think you're doing it right. It seems to me that the Cisco responds with 200 OK, and lets FS believe the call was answered, even though it was not really answered. You will need to check the settings in the Cisco. Also trace the SIP packets and log during a call, and pastebin it, and someone here can take a look on it. /Peter -----Ursprungligt meddelande----- Från: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] För Oliver Schenk Skickat: den 5 januari 2012 08:06 Till: freeswitch-users@lists.freeswitch.org Ämne: Re: [Freeswitch-users] CISCO 2811 Freeswitch IVR *bump* So I think maybe the way I'm doing the originate is the problem? In my call string I'm creating a connection directly from the CISCO (192.168.x.x) to the managed application, which may be why it starts playing straight away? Maybe I should be originating a call first and then only once I know the other side has picked up will I bridge the call to the IVR managed application. Problem is I dunno how to tell whether the other person has picked up (or even if the cisco is going to tell me) and I don't know how to do things to a call once it has been established. I'm currently reading the Dialplan wiki page, hoping to get something out of it there. Cheers Oliver On Tue, Jan 3, 2012 at 11:46 AM, Oliver Schenk <olimonkey@gmail.com> wrote:
I've been battling while creating an IVR using FreeSWITCH mod_managed and connecting through a CISCO 2811. Most things now work quite well, but I am having a few issues with the way the system answers calls (or doesn't answer calls...).
I have FreeSWITCH running as a windows service on Windows Server 2008, which is connected via LAN to a CISCO 2811 with a 4 port FXO card, which is then connected to a POTS phone line.
Take the following scenario:
1. Managed .NET application creates a call string and uses ESL to talk to freeswitch and originate a call:
string callstring = "{bridge_answer_timeout=20,ignore_early_media=true,call_timeout=20}sof ia/internal/1091234567@192.168.x.x '&managed(ivrAppName)'"; eslConnection.API("originate", callstring);
where 192.168.x.x is the CISCO IP.
2. The CISCO sees that the phone number (1091234567) starts with a 1 so it uses FXO port 1 and strips the 1 and uses the remaining phone number (091234567) to make the call.
3. My phone rings, I pick up and I can hear my IVR playing.
These are my current problems:
- IVR starts playing before I even pick up the phone. This means that if the system calls a mobile phone and the person doesn't pick up, the IVR will start playing and eventually the mobile phone will divert to voice mail. Obviously I then get a missed call and an sms saying I have a new voice mail, which is annoying. Instead I would like it to KNOW that no one has picked up, but I don't know how to do this. Somehow the CISCO needs to be able to tell FreeSWITCH that the call has not yet been answered. For some reason however as soon as the CISCO starts calling FreeSWITCH thinks the call is already connected. It doesn't know that the CISCO is actually still ringing. Maybe I'm doing originate the wrong way or something ...
- The phone only rings for about 10 seconds before hanging up. I've tried "call_timeout", "bridge_answer_timeout". I've also tried setting CISCO "ring number". Nothing works, my phone still only rings for about 10 seconds. I don't know if this is a FreeSWITCH issue or a CISCO issue. I'm leaning towards CISCO, because FreeSWITCH IVR just starts playing even if no one answers the phone.
CISCO Config for relevant FXO port:
voice service voip allow-connections h323 to h323 allow-connections h323 to sip allow-connections sip to h323 allow-connections sip to sip no supplementary-service h450.2 no supplementary-service h450.3 supplementary-service h450.12 no supplementary-service sip moved-temporarily no supplementary-service sip refer fax protocol cisco sip registrar server expires max 3600 min 3600 no update-callerid no call service stop
voice-port 0/3/2 output attenuation -3 no comfort-noise cptone AU impedance complex1 caller-id enable ! dial-peer voice 100 pots preference 1 destination-pattern 1T port 0/3/2 !
Many Thanks,
Oliver
_________________________________________________________________________ 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:4f054ba032765570613771!
I have another theory... In the managed application that gets bridged to the outgoing cisco call, l have: context.Session.Answer(); immediately. Should I be waiting for some kind of event first before I call "Answer()" to make sure it doesn't execute my code too quickly? On Thu, Jan 5, 2012 at 3:36 PM, Peter Olsson <peter.olsson@visionutveckling.se> wrote:
I think you're doing it right. It seems to me that the Cisco responds with 200 OK, and lets FS believe the call was answered, even though it was not really answered. You will need to check the settings in the Cisco. Also trace the SIP packets and log during a call, and pastebin it, and someone here can take a look on it.
/Peter
-----Ursprungligt meddelande----- Från: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] För Oliver Schenk Skickat: den 5 januari 2012 08:06 Till: freeswitch-users@lists.freeswitch.org Ämne: Re: [Freeswitch-users] CISCO 2811 Freeswitch IVR
*bump*
So I think maybe the way I'm doing the originate is the problem? In my call string I'm creating a connection directly from the CISCO (192.168.x.x) to the managed application, which may be why it starts playing straight away?
Maybe I should be originating a call first and then only once I know the other side has picked up will I bridge the call to the IVR managed application.
Problem is I dunno how to tell whether the other person has picked up (or even if the cisco is going to tell me) and I don't know how to do things to a call once it has been established.
I'm currently reading the Dialplan wiki page, hoping to get something out of it there.
Cheers
Oliver
On Tue, Jan 3, 2012 at 11:46 AM, Oliver Schenk <olimonkey@gmail.com> wrote:
I've been battling while creating an IVR using FreeSWITCH mod_managed and connecting through a CISCO 2811. Most things now work quite well, but I am having a few issues with the way the system answers calls (or doesn't answer calls...).
I have FreeSWITCH running as a windows service on Windows Server 2008, which is connected via LAN to a CISCO 2811 with a 4 port FXO card, which is then connected to a POTS phone line.
Take the following scenario:
1. Managed .NET application creates a call string and uses ESL to talk to freeswitch and originate a call:
string callstring = "{bridge_answer_timeout=20,ignore_early_media=true,call_timeout=20}sof ia/internal/1091234567@192.168.x.x '&managed(ivrAppName)'"; eslConnection.API("originate", callstring);
where 192.168.x.x is the CISCO IP.
2. The CISCO sees that the phone number (1091234567) starts with a 1 so it uses FXO port 1 and strips the 1 and uses the remaining phone number (091234567) to make the call.
3. My phone rings, I pick up and I can hear my IVR playing.
These are my current problems:
- IVR starts playing before I even pick up the phone. This means that if the system calls a mobile phone and the person doesn't pick up, the IVR will start playing and eventually the mobile phone will divert to voice mail. Obviously I then get a missed call and an sms saying I have a new voice mail, which is annoying. Instead I would like it to KNOW that no one has picked up, but I don't know how to do this. Somehow the CISCO needs to be able to tell FreeSWITCH that the call has not yet been answered. For some reason however as soon as the CISCO starts calling FreeSWITCH thinks the call is already connected. It doesn't know that the CISCO is actually still ringing. Maybe I'm doing originate the wrong way or something ...
- The phone only rings for about 10 seconds before hanging up. I've tried "call_timeout", "bridge_answer_timeout". I've also tried setting CISCO "ring number". Nothing works, my phone still only rings for about 10 seconds. I don't know if this is a FreeSWITCH issue or a CISCO issue. I'm leaning towards CISCO, because FreeSWITCH IVR just starts playing even if no one answers the phone.
CISCO Config for relevant FXO port:
voice service voip allow-connections h323 to h323 allow-connections h323 to sip allow-connections sip to h323 allow-connections sip to sip no supplementary-service h450.2 no supplementary-service h450.3 supplementary-service h450.12 no supplementary-service sip moved-temporarily no supplementary-service sip refer fax protocol cisco sip registrar server expires max 3600 min 3600 no update-callerid no call service stop
voice-port 0/3/2 output attenuation -3 no comfort-noise cptone AU impedance complex1 caller-id enable ! dial-peer voice 100 pots preference 1 destination-pattern 1T port 0/3/2 !
Many Thanks,
Oliver
_________________________________________________________________________ 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:4f054ba032765570613771!
_________________________________________________________________________ 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
No, I don't think that the call should execute the application until the call has been answered. However, there should be no need for your application to answer it, since it will be answered already. /Peter -----Ursprungligt meddelande----- Från: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] För Oliver Schenk Skickat: den 5 januari 2012 08:51 Till: FreeSWITCH Users Help Ämne: Re: [Freeswitch-users] CISCO 2811 Freeswitch IVR I have another theory... In the managed application that gets bridged to the outgoing cisco call, l have: context.Session.Answer(); immediately. Should I be waiting for some kind of event first before I call "Answer()" to make sure it doesn't execute my code too quickly? On Thu, Jan 5, 2012 at 3:36 PM, Peter Olsson <peter.olsson@visionutveckling.se> wrote:
I think you're doing it right. It seems to me that the Cisco responds with 200 OK, and lets FS believe the call was answered, even though it was not really answered. You will need to check the settings in the Cisco. Also trace the SIP packets and log during a call, and pastebin it, and someone here can take a look on it.
/Peter
-----Ursprungligt meddelande----- Från: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] För Oliver Schenk Skickat: den 5 januari 2012 08:06 Till: freeswitch-users@lists.freeswitch.org Ämne: Re: [Freeswitch-users] CISCO 2811 Freeswitch IVR
*bump*
So I think maybe the way I'm doing the originate is the problem? In my call string I'm creating a connection directly from the CISCO (192.168.x.x) to the managed application, which may be why it starts playing straight away?
Maybe I should be originating a call first and then only once I know the other side has picked up will I bridge the call to the IVR managed application.
Problem is I dunno how to tell whether the other person has picked up (or even if the cisco is going to tell me) and I don't know how to do things to a call once it has been established.
I'm currently reading the Dialplan wiki page, hoping to get something out of it there.
Cheers
Oliver
On Tue, Jan 3, 2012 at 11:46 AM, Oliver Schenk <olimonkey@gmail.com> wrote:
I've been battling while creating an IVR using FreeSWITCH mod_managed and connecting through a CISCO 2811. Most things now work quite well, but I am having a few issues with the way the system answers calls (or doesn't answer calls...).
I have FreeSWITCH running as a windows service on Windows Server 2008, which is connected via LAN to a CISCO 2811 with a 4 port FXO card, which is then connected to a POTS phone line.
Take the following scenario:
1. Managed .NET application creates a call string and uses ESL to talk to freeswitch and originate a call:
string callstring = "{bridge_answer_timeout=20,ignore_early_media=true,call_timeout=20}so f ia/internal/1091234567@192.168.x.x '&managed(ivrAppName)'"; eslConnection.API("originate", callstring);
where 192.168.x.x is the CISCO IP.
2. The CISCO sees that the phone number (1091234567) starts with a 1 so it uses FXO port 1 and strips the 1 and uses the remaining phone number (091234567) to make the call.
3. My phone rings, I pick up and I can hear my IVR playing.
These are my current problems:
- IVR starts playing before I even pick up the phone. This means that if the system calls a mobile phone and the person doesn't pick up, the IVR will start playing and eventually the mobile phone will divert to voice mail. Obviously I then get a missed call and an sms saying I have a new voice mail, which is annoying. Instead I would like it to KNOW that no one has picked up, but I don't know how to do this. Somehow the CISCO needs to be able to tell FreeSWITCH that the call has not yet been answered. For some reason however as soon as the CISCO starts calling FreeSWITCH thinks the call is already connected. It doesn't know that the CISCO is actually still ringing. Maybe I'm doing originate the wrong way or something ...
- The phone only rings for about 10 seconds before hanging up. I've tried "call_timeout", "bridge_answer_timeout". I've also tried setting CISCO "ring number". Nothing works, my phone still only rings for about 10 seconds. I don't know if this is a FreeSWITCH issue or a CISCO issue. I'm leaning towards CISCO, because FreeSWITCH IVR just starts playing even if no one answers the phone.
CISCO Config for relevant FXO port:
voice service voip allow-connections h323 to h323 allow-connections h323 to sip allow-connections sip to h323 allow-connections sip to sip no supplementary-service h450.2 no supplementary-service h450.3 supplementary-service h450.12 no supplementary-service sip moved-temporarily no supplementary-service sip refer fax protocol cisco sip registrar server expires max 3600 min 3600 no update-callerid no call service stop
voice-port 0/3/2 output attenuation -3 no comfort-noise cptone AU impedance complex1 caller-id enable ! dial-peer voice 100 pots preference 1 destination-pattern 1T port 0/3/2 !
Many Thanks,
Oliver
______________________________________________________________________ ___ 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-use rs 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-use rs 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:4f05562f32761050517028!
participants (4)
-
Brian West
-
Gustavo Mársico
-
Oliver Schenk
-
Peter Olsson