Hi Folks,
I was doing some call forwarding testing yesterday on my Obi110. I wanted to test ringing from a cellphone using the cellphone network (not wifi, CSipSimple etc) into my home phone, to make an incoming PSTN call, with a call forward that I had intended to ring a) the phone on the Phone socket b) a cellphone via SP1. c) a SIP URI which diverts to voicemail after a few seconds (e.g. 15 seconds)
What I wanted to achieve was to ring my home phone and cellphone at the same time, but if the call was not answered within 15 seconds, for the voicemail at Sipgate to answer the call and record the message.
I tried to do this by using the following InboundCallRoute on the Line Port:
{ph,SP1(07761xxxxxx),SP1(211xxxx@sipgate.co.uk)}
Where 07761xxxxxx is a second cellphone that the call is to be forwarded to (the B-end).
SP1 = Localphone.
So, I made a call from the A-end cellphone and after a short delay heard the B-end cellphone ring out. I answered the B-end and all was connected correctly. Success! After a few test words to check media path I closed the call down after about 1 minute by hitting disconnect button on cellphone at A-end, and then same button on phone at B-end. When I looked at the Obi local config on the web browser a few minutes later, I could see something strange – the Obi reported the circuit was still connected. I was puzzled by this because both cellphones were in the normal state – no calls in progress, counters running etc.
I could not see how to shut the apparent call down except by rebooting the Obi, which I did. I was very surprised to find that the Obi still reported the call as connected after reboot. So, I unplugged the power from the Obi for about 5 minutes, and also physically disconnected the line and phone ports. When I powered up Obi, status was as normal – no calls in progress.
I logged onto the Localphone website about an hour later to see what I had been charged. Strange – no record of the call. When I checked a couple of hours later I had a unpleasant surprise – I had been billed for a call of 120 minutes and 1 second!
I submitted a ticket and today they have, to their credit, refunded the cost of the call with an explanation: "I have checked the call data on this call and we did not receive the BYE(hang-up) and we dropped the call at 2 hours. Please make sure your call closes down correctly in future."
Now, can anyone explain why this happened...I don't want to test this again if there's any chance of another 2 hour call billed to a cellphone!
Another interesting observation that may be related. When I tried the following InboundCallRoute on the Line Port:
{SP2(1777xxxxxxx@in.callcentric.com)}
Where SP2 = Callcentric
The Callcentric voicemail answers after a few seconds, as per my config on their portal, but when I left a message of 23 seconds, I get an email from Callcentric with an attached voice message of 4 minutes 2 seconds. After the first 23 seconds there is a constant tone for the remaining time. Could the same thing be happening here, that the Obi110 was not sending the call clearing message in a timely way after 23 seconds? Thinking about it, if it waited until 4 minutes, that probably explains why localphone didn't receive the call clearing / BYE (hang-up) packet – by that time I had panicked and shut the power off to the Obi! However even if that were the case, it is unacceptable from a users point of view to have a bill for a 2 hour call when both A and B ends were disconnected. It would certainly not happen on the PSTN. Surely Localphone would have received a disconnect from the cellphone network at the B-end and used that to clear the connection down, even if the A-end was in an unresponsive state.
Any thoughts on how to prevent this happening again? Would it have been better to instead of using
{ph,SP1(07761xxxxxx),SP1(211xxxx@sipgate.co.uk)}
To use
{ph,SP1(07761xxxxxx),SP2(211xxxx@sipgate.co.uk)}
Instead...possibly using SP1 twice on the inbound call route confused SP1?
The XML file I am using is called UK-Profile-09OCT14 , v2.4 09 Oct 2014 from here:
https://www.ukvoipforums.com//viewtopic.php?f=25&t=342
with Line port->DetectFarEndLongSilence Unchecked (if checked, incoming calls from PSTN randomly disconnect in mid-call).
