On Wed, 02 Jun 2010 01:08:57 -0700 Dan Williams <dcbw redhat com> wrote: > On Tue, 2010-05-25 at 10:37 +0100, Neil Williams wrote: > > On Mon, 24 May 2010 16:46:34 -0700 > > Dan Williams <dcbw redhat com> wrote: > > > - When two <dtmf> are listed, what's the difference between the two? Do > > > both do the same thing? Or are they different? > > > > The same "networkID" can have differing implementations from which the > > user needs to select according to local requirements like tariff or > > locality or handset. Our UI offers a default and then allows the user to > > choose from the alternatives. > > Is it useful to tag those different implementations with a name? We > could add a name to each of the items that need it, though it can't be a > property, it'd have to be a sub-element so that it could be localized. Each definition is more of a fallback than a discrete alternative. We don't have a reliable way of mapping one alternative to one particular description. Current theory is that service providers themselves "adopt" new details when taking over smaller networks etc. and then fold those into the main network such that whichever method works gets through to the same network space. So some items will be legacy and some will be ongoing alternatives which providers maintain for their own reasons (and could drop or switch at any time). We really cannot tell from this end. Where both alternatives work in our tests, there appears to be no way to distinguish one alternative from another, except by changes which would be inherent in the type of interface. There may have been a name tag for some alternatives but there is also no guarantee that providers will continue using the same name on the handset, leading to confusion. All we have been able to establish is that certain alternatives do appear to be a sane default and those are listed first. > > > - For the SMS balance check, when two <sms> items are listed, what's the > > > different between the two? > > > > Handset / regional / tariff based differentiation. The user configures > > which of the available methods to use, the choice is then stored in > > the application. > > Again, might make sense to have <name> and <desc> subelements to give > users some help here too. If we could know that the name or desc would be persistent then that would be useful. That just doesn't appear to be a reliable assumption and is outside user control, sadly. > That would mean changing the format a bit though to something more like: > > <voicemail dtmf="901"> > <name xml:lang="de">asdfadfadf</name> > <desc xml:lang="de">Blah Blah</desc> > </voicemail> > > and the same for the rest of the items. Or replace the "dtmf" attribute > with an element inside voicemail perhaps. Either way. Maybe we don't > actually need name/description for some of these? The issue is that if > we go with the format you're suggesting, it's really hard to add > localized name or description later without breaking the DTD. >From this end, it looks more like adding names or descriptions (and then translating them) is more likely to be misleading and error-prone, causing more work for everyone. > I'd also like to see comments in the DTD if we can stuff them in about > what each of the new fields is, like you've described them here. That > makes the DTD more of a "specification". Or if that's not the right way > to do it, at least comment about them at the top of the XML file. Comments added to the DTD. > > No problem. Further updates may follow as more devices get out to real > > users. Network methods can be impossible to test without real access to > > the network itself. > > Completely understood. Think you'd be able to respin the patch with the > suggested changes? I'm attaching a revised patch with the DTD comments to replace the first one we sent. -- Neil Williams ============= http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/
Index: serviceproviders.2.dtd
===================================================================
--- serviceproviders.2.dtd (revision 10747)
+++ serviceproviders.2.dtd (working copy)
@@ -6,7 +6,7 @@
<!ELEMENT provider (name+, gsm?, cdma?)>
-<!ELEMENT gsm (network-id*, apn+)>
+<!ELEMENT gsm (network-id*, voicemail*, balance-check*, apn+)>
<!ELEMENT apn (name*,
gateway?,
username?,
@@ -14,6 +14,34 @@
dns*)>
<!ATTLIST apn value CDATA #REQUIRED>
+<!ELEMENT voicemail (#PCDATA)>
+<! contains dial string used to access voicemail services for this provider >
+<! for historical/legacy reasons network providers may support various alternative >
+<! dial strings that can be used to access voicemail services >
+
+<!ELEMENT balance-check (ussd*,
+ dtmf*,
+ sms*,
+ ussd-response*)>
+<! for handset branding and historical/legacy reasons, network providers often >
+<! support a number of alternative methods to check balance/allowance. >
+<! the first element will typically be the default method >
+
+<!ELEMENT ussd (#PCDATA)>
+<! contains * prefixed string which when sent to the network should result in a response text string from network >
+
+<!ELEMENT dtmf (#PCDATA)>
+<! contains dial string used to access balance check service via voice call >
+
+<!ELEMENT sms (#PCDATA)>
+<!ATTLIST sms text CDATA #REQUIRED>
+<! contains dial string and text string used to access balance check service via sms >
+
+<!ELEMENT ussd-response (#PCDATA)>
+<! similar to standard ussd method but requires user to select options from initial network response >
+<! typically, option 1 followed by option 3 will display remaining credit >
+<! this method does not have widespread use >
+
<!ELEMENT network-id EMPTY>
<!ATTLIST network-id mcc CDATA #REQUIRED>
<!ATTLIST network-id mnc CDATA #REQUIRED>
Index: serviceproviders.xml
===================================================================
--- serviceproviders.xml (revision 10747)
+++ serviceproviders.xml (working copy)
@@ -287,6 +287,11 @@
<name>Telstra</name>
<gsm>
<network-id mcc="505" mnc="01"/>
+ <balance-check>
+ <dtmf>125111</dtmf>
+ <dtmf>1258888</dtmf>
+ <ussd-response>*100#</ussd-response>
+ </balance-check>
<apn value="telstra.wap">
<dns>139.130.4.4</dns>
<dns>203.50.2.71</dns>
@@ -2017,6 +2022,16 @@
<!-- Britain -->
<country code="gb">
<provider>
+ <name>Test Network</name>
+ <gsm>
+ <network-id mcc="001" mnc="01"/>
+ <apn value="dummy">
+ <username>dummy</username>
+ <password>dummy</password>
+ </apn>
+ </gsm>
+ </provider>
+ <provider>
<name>airtel vodaphone</name>
<gsm>
<apn value="airtel-ci-gprs.com"/>
@@ -2038,7 +2053,11 @@
<network-id mcc="234" mnc="02"/>
<network-id mcc="234" mnc="10"/>
<network-id mcc="234" mnc="11"/>
-
+ <voicemail>901</voicemail>
+ <balance-check>
+ <ussd>*#10#</ussd>
+ <dtmf>4444</dtmf>
+ </balance-check>
<apn value="mobile.o2.co.uk">
<name>Contract</name>
<username>o2web</username>
@@ -2079,6 +2098,12 @@
<name>T-Mobile</name>
<gsm>
<network-id mcc="234" mnc="30"/>
+ <voicemail>222</voicemail>
+ <balance-check>
+ <dtmf>150</dtmf>
+ <sms text="BA">150</sms>
+ <sms text="AL">150</sms>
+ </balance-check>
<apn value="general.t-mobile.uk">
<username>User</username>
<password>mms</password>
@@ -2102,6 +2127,11 @@
<name>Vodafone</name>
<gsm>
<network-id mcc="234" mnc="15"/>
+ <voicemail>121</voicemail>
+ <balance-check>
+ <ussd>*#1345#</ussd>
+ <dtmf>2345</dtmf>
+ </balance-check>
<apn value="internet">
<name>Contract</name>
<username>web</username>
@@ -2138,7 +2168,10 @@
<gsm>
<network-id mcc="234" mnc="33"/>
<network-id mcc="234" mnc="34"/>
-
+ <voicemail>123</voicemail>
+ <balance-check>
+ <dtmf>453</dtmf>
+ </balance-check>
<apn value="orangeinternet">
<name>Contract</name>
<username>orange</username>
@@ -2565,6 +2598,9 @@
<name>O2</name>
<gsm>
<network-id mcc="272" mnc="02"/>
+ <balance-check>
+ <ussd>*#100#</ussd>
+ </balance-check>
<apn value="open.internet">
<name>Contract</name>
<username>gprs</username>
@@ -4163,6 +4199,10 @@
<name>Telenor</name>
<gsm>
<network-id mcc="242" mnc="01"/>
+ <balance-check>
+ <dtmf>220</dtmf>
+ <sms text="saldo">222</sms>
+ </balance-check>
<apn value="telenor">
<dns>212.17.131.3</dns>
<dns>148.122.161.2</dns>
@@ -5100,6 +5140,10 @@
<gsm>
<network-id mcc="240" mnc="07"/>
<network-id mcc="240" mnc="05"/>
+ <balance-check>
+ <ussd>*111#</ussd>
+ <dtmf>211</dtmf>
+ </balance-check>
<!-- http://www.tele2.se/internet-via-gprs.html -->
<apn value="internet.tele2.se">
<name>Mobilt Internet</name>
@@ -5156,7 +5200,10 @@
<gsm>
<network-id mcc="240" mnc="01"/>
<network-id mcc="240" mnc="05"/>
-
+ <balance-check>
+ <ussd>*120#</ussd>
+ <ussd>*121#</ussd>
+ </balance-check>
<!-- http://www3.telia.se/foretag/mobilguiden/ -->
<apn value="online.telia.se"/>
</gsm>
Attachment:
pgpvtaYMSvvDo.pgp
Description: PGP signature