This is "typical' behavior with ITSP's. Because the call has gone unanswered, the ITSP cancels the call. There is a default timer (usually between 30-45 seconds) with your ITSP before they cancel the call. Some ITSP's can adjust this per account, and some per number.
I find that also the TELCO's are doing the same thing now, and not letting phones ring for long periods anymore. I have just oened a ticket with bandwidth.com asking them their default settings and what is configurable by them. I will post the results from the ticket here. At the same time, you are not hampered by this if this is a forwards handled by an AA (system or otherwise), since the call will be answered, so the ITSP doesn't start looking at cancelling the call for no answer. For example, the call is not forwarded but goes to voicemail (answered!), and a key press forwards the call to another destination number. This might be a workaround for some in the event a change is not easily implemented somewhere. 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
