Remote mobile voicemail access via Voip failing (GiffGaff/localphone/X-lite)

Soldato
Joined
1 Mar 2010
Posts
23,651
Accessing my GiffGaff mobile voicemail remotely from a voip/softphone setup fails, the voicemail does not respond to the '*' key when I dial my mobile number.
Has anyone else had a similar problem ? any solutions ?


more details
  • I use X-lite softphone (free version w/advertising) plus localphone as a cheap way to make national/international calls (fraction of a pence per minute), and frankly, a lot more convenient if I am in front of a computer, than having to pick up a mobile.
  • Since I have poor mobile reception on GiffGaff, accessing voicemail from home via voip is useful. (thinking of trying ee to see if their reception is better anyway)
  • Remote voicemail access to my land line with siemens handset works using X-lite/localphone, so problem seems giffgaff/o2 specific
  • I contacted Giffgaff who are unable to debug the problem.


Incidentally: was thinking of trying EE via the Asda PAYG service, until I found that their (misrepresented service IMHOP) is billed by the minute and not the second, unlike the COOP also ee, where I have now requested a sim. - so don't be conned by Asda.
 
The most likely cause is you are set to either Inband or RFC2833 for DTMF on your VoiP phone which is being accepted by your landline but not GiffGaff.
 
Thanks I had tried the different dtmf options on the softphone, but none of them get it working.

However I thought that these options were just responsible for how x-lite/softphone communicates with localphone/voip-service though, which is working for landline voicemail,
and that localphone will be using an unknown(but guaranteed industry std) to communicate with o2/giffgaff exchange ?
so I had not mentioned it in original post.


36592766501_0dd245927b_o_d.jpg
 
The default used by most SIP providers is RFC2833, but the usual PSTN is done InBand. The third option is using the SIP INFO packets (but I have never used that option).
 
I've had a run in with a problem like this before on a very large <telco> solution but I'm not a good enough VOIP engi to know if it's the same so this might be wrong.

The issue was the A-party handsets did 2833 with the platform (in your case, your SIP breakout provider), but on call-out the platform would negotiate to do 2833 with the BT IPX (or whatever device they hit first, it was a few years ago) but the IPX would always request fallback, inband. The Vodafone solution didn't support inband from the (A-Party) devices (CISCOOOOOO) due to it needing 2833 for other reasons, so the device essentially just sent it over 2833 and naturally, nothing happened because mysterously <telco> forgot to put the conversion of 2833 to inband in the platform. Can you see in your captures the return packet to check what your SIP platform is offering (2833/inband) maybe?
 
Thanks for your detailed theory, I am exploring the log files, but, as you say
because mysterously <telco> forgot to put the conversion of 2833 to inband
so it could be a lost cause.
[might be interesting to know service providers/companies for which voip remote access works seamlessly - do many put up obstacles]

not so helpful reply from GiffGaff
22 Aug 2017 17:28
Hi Paul
We don't have DTMF test numbers as we do not offer VOIP services ourselves. The protocol required depends on the VOIP service provider that you are using. There are numerous VOIP protocols and it is not possible for us to determine which protocol you need to implement.
VOIP servers usually require a hard wired stable Internet connection that can not be achieved with a wireless data connection from a SIM. You'd be best using a broadband connection for stability.
The best advice I can give is to check with your VOIP service provider regarding the protocols.
All the best, ....
 
Found the problem (awaiting giffgaff confirmation)
the caller ID on the Softphone was set to my mobile number (for potential call backs), and this makes the giffgaff voicemail unresponsive/deaf to dtmf/touch-tones.

The call verbose logs showed dtmf was being sent oob out-of-band, without any further details.
Thanks for the help you both gave
 
Back
Top Bottom