[Freeswitch-users] 30 Seconds - About 6 Rings

[Michael Gende]

 Hello,

We just had an issue come up. Short version: we want to allow for about 6
rings for incoming calls.

We had been using the simple logic below (from our default.xml) allowing 15
seconds (see "call_timeout" value). That gave time for about three rings.

Need 6 rings? Just call the VoIP provider (Urbancom in our case) make sure
they will cooperate and "up" the timeout to 30. Right? Hasn't worked out
that way. Two things happen:

Turns out most calls (some land line, some cellular) ring for about 20
seconds, then the caller gets an error tone and our FS returns 847,
originator cancel.

Strangely, when I call in from Sprint (near Chicago), the logic just goes
"round and round", ringing forever. It just seems to "re-set" and rings
another 20 seconds, then resets again, ringing forever.

I'm thinking that Urbancom's PSTN provider may not wait for 30 seconds
before canceling the call. Sprint must "come in" to Urbancom another way.
But that doesn't explain not going to VM.

Those are my thoughts. Anything I'm missing?

Thanks,

Mike

<!-- Mike Added: Incoming Urbancom Calls. Pretty straightforward, ring a
call group for a time, if no one answers, go to ext 1000's VM -->

    <extension name="UrbancomIn">
      <condition field="destination_number" expression="^(8201)$">
         <action application="set" data="*call_timeout=15*"/>
         <action application="set" data="domain_name=192.168.0.198"/>
         <action application="set" data="continue_on_fail=true"/>
         <action application="set" data="hangup_after_bridge=true"/>
         <action application="bridge" data="group/support@${domain_name}"/>
         <action application="answer"/>
         <action application="sleep" data="1000"/>
         <action application="voicemail" data="default 192.168.0.198 1000"/>
      </condition>
    </extension>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20110523/2b616456/attachment.html