I spoke with Bandwidth.com at length, assuming this is BANDWIDTH.COM, they say the incoming/outgoing call timer for both their LEVEL3 and their own CLEC are 120 seconds.
The issue you might be facing is what the cancel timer is by the carrier (destination number you are forwarding to) is, which is unknowable and varies by carrier. Certainly it should not be under 10 or 15 seconds, which is what I believe based on your original comments. Tony >>> Chaitra <[email protected]> 02/20/09 5:18 AM >>> Hi All, This is regarding call forwarding an Inbound call from an ITSP to an SCS user or PSTN numbers. Consider the following scenario: Inbound call made using bandwidth.com terminates on user 200 in SCS who has set a call forwarding (if no response) forward to another PSTN number (ring for 30 seconds) Default serial fork expiration = 20 Here, if the call is not answered by user 200, then after 20 seconds it is forwarded to the PSTN phone which takes around 4 seconds to actually start ringing. In no time (about 2 rings) the call gets disconnected on the PSTN phone, with the ITSP (bandwidth.com) sending a CANCEL before the forwarding completes. In other words the ITSP cancels the call on "No Answer" exactly after 30 seconds. This behavior was previously observed in case of BT.com and callwithus.com ITSP's as well. Now, this would be an issue to a user who has set call forwarding to his cell phone as his cell phone would ring only for few seconds before the call gets disconnected. There are workarounds such as change the "default serial fork expiration =smaller value, so that the call could be made to ring for a longer time on the PSTN number. (this cannot be done by the end user, also changing this parameter would affect globally) OR setup the call forwarding configuration for "at the same time", Even with these workarounds after a total of 30 seconds if the call is not answered, the ITSP cancels the call. This issue also occurs if an Inbound call terminates in a hunt group or ACD. Since we are supporting Bandwidth.com for sipXbridge, could an issue be raised with bandwidth.com to support longer transfers? OR could this limitation be documented for ITSPs Attachment: merged.xml -->CallForwarding-to-PSTN.xml Thanks, Chaitra _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
_______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
