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