We will need to have an API for the Voicemail number avaialble in the SIM. There is already some discussion covering this on Bug 757235. The relevant SIM details can be found in 3GPP TS 31.102, Sections 4.2.60 (EF_MBDN) and 4.2.62 (EF_MBI).

Fernando, do you have any details about the storage location of the "short" number you mentioned in b2g-voicemail? There seems to be only one number stored in EF_MBDN..

I'd like to answer here with Fernando's permission. As Ignacio pointed out in [1] some operators store the voicemail number in the SIM but other do not. In that case both short and long numbers are stored somehow on the phone by the OEM implementing what is commonly known as the operator-software variant. Another option is that the voice mail number is not stored on the phone and the operator-software variant specifies somehow that the number has to be read from SIM. I say "the numbers are stored on the phone somehow..." and "the operator-software variant specifies somehow..." because the OEM is responsible for implementing how to store them or how to specify it. I guess you are surprised with that explanation or even with that topic but that's true. So your next question here will be, Where could I read those numbers from? The answer is not clear at the moment. I am currently trying to make a proposal about how implement that operator-software variant topic. My idea is to store those numbers as Android system properties in gonk or even as a setting value in the setting DB in gecko. Something like ro.carrier.voicemail.number.short = 177, ro.carrier.voicemail.number.long = 0034666777888 or even ro.carrier.voicemail.number.fromsim = true. Maybe you could implement the API for the Voicemail number available in the SIM in the mean time and retrieve the short number from its location once we agree that location in a follow-up. Does it sond good to you? Comments? [1] https://bugzilla.mozilla.org/show_bug.cgi?id=757235#c5

(In reply to José Antonio Olivera Ortega [:jaoo] from comment #2) > > I guess you are surprised with that explanation or even with that topic but > that's true. Nothing surprises me about these telephony specifications any more :) > Something like > ro.carrier.voicemail.number.short = 177, ro.carrier.voicemail.number.long = > 0034666777888 or even ro.carrier.voicemail.number.fromsim = true. > > Maybe you could implement the API for the Voicemail number available in the > SIM in the mean time and retrieve the short number from its location once we > agree that location in a follow-up. Does it sond good to you? Comments? That sounds good to me -- Can you open a follow up? This bug will just focus on retrieving the VM number from EF_MBDN. I also see in the Android implementation that look at EF_MAILBOX_CPHS -- I guess this is an extension specification of some kind?

There are GET_SIM_STATUS and ICC IO modem bugs blocking from testing this on Otoro: Bug 766862 Bug 771440

Forgot to remove unused addition of mbdn to nsICCRecords

Comment on attachment 643044 [details] [diff] [review] Part 1: DOM API - v1 Review of attachment 643044 [details] [diff] [review]: ----------------------------------------------------------------- I assume v2 is intended to be instead of this one.

Comment on attachment 643044 [details] [diff] [review] Part 1: DOM API - v1 Nope, v2 was another patch (not the DOM APIs) :)

Comment on attachment 643053 [details] [diff] [review] Part 3: RIL impl of SIM EF_MBDN - v2 Review of attachment 643053 [details] [diff] [review]: ----------------------------------------------------------------- I've done some research about your implementation. There is still something to be done, but I think that's not what this patch should deal with. Thank you. ::: dom/system/gonk/ril_worker.js @@ +985,5 @@ > this.getIMSI(); > this.getMSISDN(); > this.getAD(); > this.getUST(); > + this.getMBDN(); According to TS 131.102 clause 4.2.60, `If service n°47 is "available", this file shall be present.` It means we have to check UST first? But I just found Android loads MBI/MBDN before UST loading. Besides, same clause also has `Each dialling number shall be associated with a message waiting indication group type using EFmbi.` So we should check MBI for Mailbox Dialing Number Identifier of Voicemail first, which is also Android's implementation now. However, specifying the record number is a missing function in current ICC utility functions and is beyond the scope of this issue. I think that would be a minor issue and probably never be an issue at all.

Comment on attachment 643049 [details] [diff] [review] Part 4: Tests - v1 Review of attachment 643049 [details] [diff] [review]: ----------------------------------------------------------------- Nice! But I'm really curious about how do you know the number in qemu. I do find some web pages showing the same number, but just can't find it in the code.

Comment on attachment 643047 [details] [diff] [review] Part 2: DOM impl (C++) - v1 >+NS_IMETHODIMP >+Voicemail::GetNumber(nsAString& aNumber) >+{ >+ aNumber.SetIsVoid(true); >+ NS_ENSURE_TRUE(mRIL, NS_ERROR_FAILURE); >+ >+ return mRIL->GetVoicemailNumber(aNumber); >+} If it is really unexpected to have null mRil, I'd do NS_ENSURE_STATE(mRil); aNumber.SetIsVoid(true); return mRIL->GetVoicemailNumber(aNumber); Similar with GetDisplayName

(In reply to Vicamo Yang [:vicamo] from comment #12) > Besides, same clause also has `Each dialling number shall be > associated with a message waiting indication group type using EFmbi.` So we > should check MBI for Mailbox Dialing Number Identifier of Voicemail first, > which is also Android's implementation now. However, specifying the record > number is a missing function in current ICC utility functions and is beyond > the scope of this issue. I think that would be a minor issue and probably > never be an issue at all. Yeah, that was the code I originally read as well. I'm fully behind supporting the EF_MBI / index, but we can open up a lower priority follow up for that, thoughts?

(In reply to Vicamo Yang [:vicamo] from comment #13) > Nice! But I'm really curious about how do you know the number in qemu. I do > find some web pages showing the same number, but just can't find it in the > code. Once I had this patch working on my Nexus S, I built and tested on the emulator, and that was the number that showed up :) I went looking through the qemu sim card code [1], there are several hard coded responses and EF files, but it's not 100% clear which has the voicemail data from a cursory glance. [1] https://github.com/mozilla-b2g/platform_external_qemu/blob/master/telephony/sim_card.c

Macro nit update

(In reply to Marshall Culpepper [:marshall_law] from comment #16) > (In reply to Vicamo Yang [:vicamo] from comment #13) > > Nice! But I'm really curious about how do you know the number in qemu. I do > > find some web pages showing the same number, but just can't find it in the > > code. > > Once I had this patch working on my Nexus S, I built and tested on the > emulator, and that was the number that showed up :) > > I went looking through the qemu sim card code [1], there are several hard > coded responses and EF files, but it's not 100% clear which has the > voicemail data from a cursory glance. > > [1] > https://github.com/mozilla-b2g/platform_external_qemu/blob/master/telephony/ > sim_card.c It's in line 371. EFmbdn = 0x6FC7 = 28615. "+CRSM=178" means "restricted SIM access: read record". Then the number you got is extracted from "5155125740f9" with hi/lo half byte inverted. That totally explains the magic number. Thank you. I learned one more thing. ;)

https://hg.mozilla.org/integration/mozilla-inbound/rev/0b1cef48b5d2 https://hg.mozilla.org/integration/mozilla-inbound/rev/1a829406e669 https://hg.mozilla.org/integration/mozilla-inbound/rev/e0f6dcb1eeca https://hg.mozilla.org/integration/mozilla-inbound/rev/a5daaa4e1657

https://hg.mozilla.org/mozilla-central/rev/0b1cef48b5d2 https://hg.mozilla.org/mozilla-central/rev/1a829406e669 https://hg.mozilla.org/mozilla-central/rev/e0f6dcb1eeca https://hg.mozilla.org/mozilla-central/rev/a5daaa4e1657

Documentation available here: https://developer.mozilla.org/en-US/docs/tag/voicemail