Results 16 to 28 of 28
- 12-19-2008, 12:37 PM #16Mizter TGuest
Re: Rail companies roll out barcode ticket standard
On 19 Dec, 18:11, disgoftunwells <[email protected]> wrote:
> On 19 Dec, 12:46, Mizter T <[email protected]> wrote:
>
> > On 19 Dec, 11:55, Mr Thant <[email protected]>
> > wrote:
>
> > > On 19 Dec, 11:42, Robert <[email protected]> wrote:
>
> > > > May I add to that? The link describes a Nokia proprietary
> > > > implementation, so it would only be found in Nokia handsets.
>
> > > It's widely implemented by other manufacturers though, and I'm fairly
> > > certain it's what Chiltern used to get a barcode on my phone (a Sony
> > > Ericsson). The fact it isn't a proper standard doesn't matter all that
> > > much for their purposes (although I realise the ideological and longer
> > > term impacts of ad-hoc standards like this ).
>
> > Very interesting - actually I do recall those SMS bitmap-picture
> > messages that were a selling point of the Nokia phones of old.
> > 'disgoftunwells' upthread suggests that it is in fact "a subset of SMS
> > called Enhanced Messaging Service (EMS)".
>
> Actually there are two subsets:
> EMS is used by most phones apart from Nokias
> (http://en.wikipedia.org/wiki/Enhanced_Messaging_Service)
>
> Nokia Picture Messaging Service: A standard used by Nokia (and one or
> two smaller brands). The Nokia will elongate the image to about 72
> pixels wide by 28 pixels high.
>
> Both are SMS. Many older phones don't support either standard, so all
> you get is the ticket number. Annoyingly, most smart phones don't
> support either standard so you're left with MMS and WAP Push (or other
> forms of a link in an SMS).
>
OK, thanks for the info. May I trouble you with a few more
questions...
(1) How does Chiltern (or rather their e-ticket service provider) know
which type of SMS to send - i.e. EMS or Nokia Picture Messaging
Service (aka OTA Bitmap)? Can both types be sent in the same SMS and
then the handset will just ignore the stuff it doesn't understand (or
even possibly the network's SMS kit will discard it knowing that it's
not compatible with the receiving phone)?
(2) Similarly, what happens if an an SMS with extra EMS or Nokia
Picture Messaging Service data gets sent to a basic mobile that
supports neither functionality?
Or do Chiltern somehow know what type of handset it is before sending
anything out so they can then send the appropriate type of SMS (EMS,
Nokia format or wap link for retrieval) - and if so how do they know
this? (User entered information about model numbers can't be regarded
with confidence.)
› See More: Rail companies roll out barcode ticket standard
- 12-19-2008, 03:07 PM #17Theo MarkettosGuest
Re: Rail companies roll out barcode ticket standard
In uk.telecom.mobile Mizter T <[email protected]> wrote:
> Or do Chiltern somehow know what type of handset it is before sending
> anything out so they can then send the appropriate type of SMS (EMS,
> Nokia format or wap link for retrieval) - and if so how do they know
> this? (User entered information about model numbers can't be regarded
> with confidence.)
Any conversion would have to be at the last hop, because what happens if the
receiving phone is switched off when they send? In that case the SMS will
queue in the network and the sender won't be able to alter it. Or is there
some way bulk SMS senders can know if a particular phone is on? If there
is, it raises all sorts of privacy issues.
What happens if the recipient switches their SIM to another phone before
switching it on? The sender can't rely on any IMEI information logged about
the phone the SIM was last seen in. (Though there's a fairly high chance
the SIM will reappear in the same phone)
Theo
- 12-19-2008, 05:18 PM #18Mr.GGuest
Re: Rail companies roll out barcode ticket standard
In article
<[email protected]>,
Mizter T <[email protected]> wrote:
> Yes I understand that - but I wasn't asking about MMS at all, rather
> what happens when an old or very basic phone that only supports the
> most basic SMS functionality i.e. one that does not not have the SMS
> Enhanced Messaging Service capability (nothing to do with MMS)
> receives a message with a barcode in it - does it just display a
> nonsense string of characters?
>
> My suspicion however is that the network - which knows what type of
> device a mobile is and hence its capabilities - strips anything out
> which the receiving handset cannot cope with.
Sorry, I obviously misunderstood your original question. I'm not sure
the network can determine the type of phone receiving the message
though: as others have asked, what happens if you switch the SIM card to
a different phone?
- 12-19-2008, 05:40 PM #19RobertGuest
Re: Rail companies roll out barcode ticket standard
On 2008-12-19 21:07:11 +0000, Theo Markettos
<[email protected]> said:
> In uk.telecom.mobile Mizter T <[email protected]> wrote:
>> Or do Chiltern somehow know what type of handset it is before sending
>> anything out so they can then send the appropriate type of SMS (EMS,
>> Nokia format or wap link for retrieval) - and if so how do they know
>> this? (User entered information about model numbers can't be regarded
>> with confidence.)
>
> Any conversion would have to be at the last hop, because what happens if the
> receiving phone is switched off when they send? In that case the SMS will
> queue in the network and the sender won't be able to alter it. Or is there
> some way bulk SMS senders can know if a particular phone is on? If there
> is, it raises all sorts of privacy issues.
Unless you try phoning the party you wish to send a message to, the
originator of a short message does not know if any particular phone is
switched on, and there is no signalling in the network via the Short
Message Service that will inform the originator of the phone's status.
Regarding privacy: one of the guiding credos of the GSM / 3GPP
specifications from the early days in the mid-1980s was that the caller
cannot determine the position of the called party unless the called
party agrees to his position being given. This is not the same as the
/network/ knowing where the handsets are - it obviously must do.
There are a variety of Short Messages types. Point-to-point (SMS-PP)
are targeted at a particular SIM; cell broadcast (SMS-CB) messages can
be received by any active handset in the cell. Messages can be coded so
thay are immediately displayed on the handset's screen without user
intervention, or indicate that a message has arrived and is to be read
(the normal sort) or passed to the handset for processing with no
indication to the user. This latter type is used for network management
- some phones (mainly Nokias) can display a message such as 'SIM
update'.
The payload of the SMS can either be alpha-numeric displaying up to 160
characters in a 1-byte alphabet or a binary non-text message. I don't
know the details of the railway ticket application, but it could be
(I'm guessing) that it is this feature that permits the barcode to be
displayed. It is otherwise used to pass data updates to the handset or
SIM. The mechanism is the SIM Application Toolkit whereby the SIM
instructs the handset to perform a function, e.g., sound a tone or
display some data. Practically all handsets and SIMs built since 1999
(Release 99 - I think) of the GSM specifications (so-called Phase 2+ of
the GSM rollout) support this feature. The question is whether the
handsets support /all/ the features need to display a barcode or other
symbols. If a manufacturer decides it (or any other feature) is not
needed they'll leave it off - sometimes to the annoyance of the network
operator!!
Short messages are sent to the Short Message Service Centre (SMSC) from
different sources: other handsets, the network administration and from
web sites and more recently from wired lines. If the handset is powered
on, its status is known from the Visitors Location Register (VLR) -
essentially a large database - and the SMSC passes the SMS on to the
network which routes it to the base station in the cell where the
handset is. If the handset is powered off, there is no entry in the VLR
and the SMS is stored in the SMSC and transmitted when the handset is
switched back on, camps on the network again and a VLR entry is
generated.
If the SMS is coded to request an acknowledgement of receipt at the
handset, then the handset will return an acknowledgement to the SMSC
which will be passed back to the originator. If no acknowledgement is
requested, the originator can only assume the message has been
received. No position information is transferred in the acknowledgement.
SMS messages stored on the SMSC are timed out and deleted if they are
not successfully sent. Depending on the settings the timeout can be up
to a week or two.
SMS message transmission is not deterministic. Transmission delays
depend on the load on the SMSC and all the other bits of kit in the
path to the handset. Messages can be received almost immediately or can
be delayed for some hours, even overnight. Some (a tiny, tiny
percentage) just get lost in cyberspace.....
> What happens if the recipient switches their SIM to another phone before
> switching it on? The sender can't rely on any IMEI information logged about
> the phone the SIM was last seen in. (Though there's a fairly high chance
> the SIM will reappear in the same phone)
>
> Theo
Networks mostly track IMEI / SIM combinations for fraud prevention
purposes, not for network management. If this checking is done then, on
the networks with which I am familiar, it is checked in the first few
seconds when the handset camps onto the network after power on. There
is no coding in an ETSI/3GPP standardised SMS packet which is IMEI or
handset model specific. A Short Message packet is a Short Message
packet.
I don't have the specs to hand, but I seem to remember that up to 8
short messages can be concatenated if you have a long message to send.
Of course, you'll pay 8 times! And not all handsets, mainly the older
ones, can display such a long message - it is truncated and the rest
lost.
Incidentally, all the GSM and 3GPP specifications are in the public
domain. As well as all the earlier versions. Go to the ETSI or 3GPP
websites - you'll find more than you ever wanted to know...!
--
Robert
- 12-19-2008, 06:59 PM #20Mizter TGuest
Re: Rail companies roll out barcode ticket standard
On 19 Dec, 23:40, Robert <[email protected]> wrote:
> On 2008-12-19 21:07:11 +0000, Theo Markettos
> <[email protected]> said:
>
> > In uk.telecom.mobile Mizter T <[email protected]> wrote:
> >
> >> Or do Chiltern somehow know what type of handset it is before sending
> >> anything out so they can then send the appropriate type of SMS (EMS,
> >> Nokia format or wap link for retrieval) - and if so how do they know
> >> this? (User entered information about model numbers can't be regarded
> >> with confidence.)
>
> > Any conversion would have to be at the last hop, because what happens if the
> > receiving phone is switched off when they send? In that case the SMS will
> > queue in the network and the sender won't be able to alter it. Or is there
> > some way bulk SMS senders can know if a particular phone is on? If there
> > is, it raises all sorts of privacy issues.
>
> Unless you try phoning the party you wish to send a message to, the
> originator of a short message does not know if any particular phone is
> switched on, and there is no signalling in the network via the Short
> Message Service that will inform the originator of the phone's status.
>
> Regarding privacy: one of the guiding credos of the GSM / 3GPP
> specifications from the early days in the mid-1980s was that the caller
> cannot determine the position of the called party unless the called
> party agrees to his position being given. This is not the same as the
> /network/ knowing where the handsets are - it obviously must do.
>
> There are a variety of Short Messages types. Point-to-point (SMS-PP)
> are targeted at a particular SIM; cell broadcast (SMS-CB) messages can
> be received by any active handset in the cell. Messages can be coded so
> thay are immediately displayed on the handset's screen without user
> intervention, or indicate that a message has arrived and is to be read
> (the normal sort) or passed to the handset for processing with no
> indication to the user. This latter type is used for network management
> - some phones (mainly Nokias) can display a message such as 'SIM
> update'.
>
> The payload of the SMS can either be alpha-numeric displaying up to 160
> characters in a 1-byte alphabet or a binary non-text message. I don't
> know the details of the railway ticket application, but it could be
> (I'm guessing) that it is this feature that permits the barcode to be
> displayed. It is otherwise used to pass data updates to the handset or
> SIM. The mechanism is the SIM Application Toolkit whereby the SIM
> instructs the handset to perform a function, e.g., sound a tone or
> display some data. Practically all handsets and SIMs built since 1999
> (Release 99 - I think) of the GSM specifications (so-called Phase 2+ of
> the GSM rollout) support this feature. The question is whether the
> handsets support /all/ the features need to display a barcode or other
> symbols. If a manufacturer decides it (or any other feature) is not
> needed they'll leave it off - sometimes to the annoyance of the network
> operator!!
>
> Short messages are sent to the Short Message Service Centre (SMSC) from
> different sources: other handsets, the network administration and from
> web sites and more recently from wired lines. If the handset is powered
> on, its status is known from the Visitors Location Register (VLR) -
> essentially a large database - and the SMSC passes the SMS on to the
> network which routes it to the base station in the cell where the
> handset is. If the handset is powered off, there is no entry in the VLR
> and the SMS is stored in the SMSC and transmitted when the handset is
> switched back on, camps on the network again and a VLR entry is
> generated.
> If the SMS is coded to request an acknowledgement of receipt at the
> handset, then the handset will return an acknowledgement to the SMSC
> which will be passed back to the originator. If no acknowledgement is
> requested, the originator can only assume the message has been
> received. No position information is transferred in the acknowledgement.
>
> SMS messages stored on the SMSC are timed out and deleted if they are
> not successfully sent. Depending on the settings the timeout can be up
> to a week or two.
>
> SMS message transmission is not deterministic. Transmission delays
> depend on the load on the SMSC and all the other bits of kit in the
> path to the handset. Messages can be received almost immediately or can
> be delayed for some hours, even overnight. Some (a tiny, tiny
> percentage) just get lost in cyberspace.....
>
> > What happens if the recipient switches their SIM to another phone before
> > switching it on? The sender can't rely on any IMEI information logged about
> > the phone the SIM was last seen in. (Though there's a fairly high chance
> > the SIM will reappear in the same phone)
>
>
> Networks mostly track IMEI / SIM combinations for fraud prevention
> purposes, not for network management. If this checking is done then, on
> the networks with which I am familiar, it is checked in the first few
> seconds when the handset camps onto the network after power on. There
> is no coding in an ETSI/3GPP standardised SMS packet which is IMEI or
> handset model specific. A Short Message packet is a Short Message
> packet.
>
> I don't have the specs to hand, but I seem to remember that up to 8
> short messages can be concatenated if you have a long message to send.
> Of course, you'll pay 8 times! And not all handsets, mainly the older
> ones, can display such a long message - it is truncated and the rest
> lost.
>
> Incidentally, all the GSM and 3GPP specifications are in the public
> domain. As well as all the earlier versions. Go to the ETSI or 3GPP
> websites - you'll find more than you ever wanted to know...!
>
That's a fascinating reply, thanks very much (and it truly illustrates
usenet's splendid capacity to share knowledge!). Elements of the so-
called Phase 2+ of the GSM specs appear to hold the answer as to how
these graphical SMS messages work.
Still a bit curious as to whether such a single SMS 'payload' could
possibly contain two different types of graphical message (i.e. both
EMS and Nokia), though Mr Thant's post earlier stated that the barcode
message on his Sony Ericsson was likely to be of the EMS type when he
had previously thought his handset only supported the Nokia 'standard'
- so perhaps EMS has in fact been rather more universally adopted by
manufacturers.
And I'm also curious as to how they know how to send a WAP push
message (which unless I'm mistaken is just a text with a WAP link in
it) instead of a text message to handsets that cannot support the
latter (i.e. smartphones). I have just gone through the Chiltern
Railway 'tckts by txt' purchasing process up to the point of payment
and it only asked for confirmation of the "mobile make" i.e.
manufacturer - no indication of whether the mobile is a smart or dumb
Nokia, for example.
- 12-20-2008, 06:25 AM #21disgoftunwellsGuest
Re: Rail companies roll out barcode ticket standard
On 20 Dec, 00:59, Mizter T <[email protected]> wrote:
> On 19 Dec, 23:40, Robert <[email protected]> wrote:
>
>
>
> > On 2008-12-19 21:07:11 +0000, Theo Markettos
> > <[email protected]> said:
>
> > > In uk.telecom.mobile Mizter T <[email protected]> wrote:
>
> > >> Or do Chiltern somehow know what type of handset it is before sending
> > >> anything out so they can then send the appropriate type of SMS (EMS,
> > >> Nokia format or wap link for retrieval) - and if so how do they know
> > >> this? (User entered information about model numbers can't be regarded
> > >> with confidence.)
>
> > > Any conversion would have to be at the last hop, because what happensif the
> > > receiving phone is switched off when they send? *In that case the SMS will
> > > queue in the network and the sender won't be able to alter it. *Or is there
> > > some way bulk SMS senders can know if a particular phone is on? *Ifthere
> > > is, it raises all sorts of privacy issues.
>
> > Unless you try phoning the party you wish to send a message to, the
> > originator of a short message does not know if any particular phone is
> > switched on, and there is no signalling in the network via the Short
> > Message Service that will inform the originator of the phone's status.
>
> > Regarding privacy: one of the guiding credos of the GSM / 3GPP
> > specifications from the early days in the mid-1980s was that the caller
> > cannot determine the position of the called party unless the called
> > party agrees to his position being given. This is not the same as the
> > /network/ knowing where the handsets are - it obviously must do.
>
> > There are a variety of Short Messages types. Point-to-point (SMS-PP)
> > are targeted at a particular SIM; cell broadcast (SMS-CB) messages can
> > be received by any active handset in the cell. Messages can be coded so
> > thay are immediately displayed on the handset's screen without user
> > intervention, or indicate that a message has arrived and is to be read
> > (the normal sort) or passed to the handset for processing with no
> > indication to the user. This latter type is used for network management
> > - some phones (mainly Nokias) can display a message such as 'SIM
> > update'.
>
> > The payload of the SMS can either be alpha-numeric displaying up to 160
> > characters in a 1-byte alphabet or a binary non-text message. I don't
> > know the details of the railway ticket application, but it could be
> > (I'm guessing) that it is this feature that permits the barcode to be
> > displayed. It is otherwise used to pass data updates to the handset or
> > SIM. The mechanism is the SIM Application Toolkit whereby the SIM
> > instructs the handset to perform a function, e.g., sound a tone or
> > display some data. Practically all handsets and SIMs built since 1999
> > (Release 99 - I think) of the GSM specifications (so-called Phase 2+ of
> > the GSM rollout) support this feature. The question is whether the
> > handsets support /all/ the features need to display a barcode or other
> > symbols. If a manufacturer decides it (or any other feature) is not
> > needed they'll leave it off - sometimes to the annoyance of the network
> > operator!!
>
> > Short messages are sent to the Short Message Service Centre (SMSC) from
> > different sources: other handsets, the network administration and from
> > web sites and more recently from wired lines. If the handset is powered
> > on, its status is known from the Visitors Location Register (VLR) -
> > essentially a large database - and the SMSC passes the SMS on to the
> > network which routes it to the base station in the cell where the
> > handset is. If the handset is powered off, there is no entry in the VLR
> > and the SMS is stored in the SMSC and transmitted when the handset is
> > switched back on, camps on the network again and a VLR entry is
> > generated.
> > If the SMS is coded to request an acknowledgement of receipt at the
> > handset, then the handset will return an acknowledgement to the SMSC
> > which will be passed back to the originator. If no acknowledgement is
> > requested, the originator can only assume the message has been
> > received. No position information is transferred in the acknowledgement..
>
> > SMS messages stored on the SMSC are timed out and deleted if they are
> > not successfully sent. Depending on the settings the timeout can be up
> > to a week or two.
>
> > SMS message transmission is not deterministic. Transmission delays
> > depend on the load on the SMSC and all the other bits of kit in the
> > path to the handset. Messages can be received almost immediately or can
> > be delayed for some hours, even overnight. Some (a tiny, tiny
> > percentage) just get lost in cyberspace.....
>
> > > What happens if the recipient switches their SIM to another phone before
> > > switching it on? The sender can't rely on any IMEI information loggedabout
> > > the phone the SIM was last seen in. *(Though there's a fairly high chance
> > > the SIM will reappear in the same phone)
>
> > Networks mostly track IMEI / SIM combinations for fraud prevention
> > purposes, not for network management. If this checking is done then, on
> > the networks with which I am familiar, it is checked in the first few
> > seconds when the handset camps onto the network after power on. There
> > is no coding in an ETSI/3GPP standardised SMS packet which is IMEI or
> > handset model specific. A Short Message packet is a Short Message
> > packet.
>
> > I don't have the specs to hand, but I seem to remember that up to 8
> > short messages can be concatenated if you have a long message to send.
> > Of course, you'll pay 8 times! And not all handsets, mainly the older
> > ones, can display such a long message - it is truncated and the rest
> > lost.
>
> > Incidentally, all the GSM and 3GPP specifications are in the public
> > domain. As well as all the earlier versions. Go to the ETSI or 3GPP
> > websites - you'll find more than you ever wanted to know...!
> That's a fascinating reply, thanks very much (and it truly illustrates
> usenet's splendid capacity to share knowledge!). Elements of the so-
> called Phase 2+ of the GSM specs appear to hold the answer as to how
> these graphical SMS messages work.
>
> Still a bit curious as to whether such a single SMS 'payload' could
> possibly contain two different types of graphical message (i.e. both
> EMS and Nokia), though Mr Thant's post earlier stated that the barcode
> message on his Sony Ericsson was likely to be of the EMS type when he
> had previously thought his handset only supported the Nokia 'standard'
> - so perhaps EMS has in fact been rather more universally adopted by
> manufacturers.
>
> And I'm also curious as to how they know how to send a WAP push
> message (which unless I'm mistaken is just a text with a WAP link in
> it) instead of a text message to handsets that cannot support the
> latter (i.e. smartphones). I have just gone through the Chiltern
> Railway 'tckts by txt' purchasing process up to the point of payment
> and it only asked for confirmation of the "mobile make" i.e.
> manufacturer - no indication of whether the mobile is a smart or dumb
> Nokia, for example.
>
I think Robert summed up the technology better than I can.
On the Chiltern site you enter your phone model so it knows whether to
try and send Nokia Picture Messaging, EMS, Wap Push / embedded
hyperlink, or plain text.
Of course, the problem is with a Nokia Smartphone? Is it WAP Push or
Nokia Picture Messaging. What about an ancient Nokia brick? Is it
plain text or Nokia Picture Messaging? However, if the system gets it
wrong, then the user should always get the plain text ticket number
which the inspectors can key in. (The old bricks will receive an EMS,
but only display the text, not the image. The only real problem is if
you enter "Smart Phone" but actually have an old brick).
All this works because the tickets are type "Advance". The new RSP
tickets will need to be a lot more sure that the phone can display
them.
- 12-20-2008, 07:54 AM #22Stuart ClarkGuest
Re: Rail companies roll out barcode ticket standard
Robert wrote:
> On 2008-12-19 21:07:11 +0000, Theo Markettos
> <[email protected]> said:
>
>> In uk.telecom.mobile Mizter T <[email protected]> wrote:
>> queue in the network and the sender won't be able to alter it. Or is
>> there
>> some way bulk SMS senders can know if a particular phone is on? If there
>> is, it raises all sorts of privacy issues.
>
> Unless you try phoning the party you wish to send a message to, the
> originator of a short message does not know if any particular phone is
> switched on, and there is no signalling in the network via the Short
> Message Service that will inform the originator of the phone's status.
>
By using two of the features mentioned in your messages you can find
this out (though it isn't foolproof). Send an "invisible" text to the
number with delivery reporting activated. When the text is received
nothing is displayed to the user, but the originator is informed of the
delivery.
However, I doubt this technique is much used, as firstly it costs an
extra text fee to deliver this initial invisible text, secondly is
asynchronous in its nature, and thirdly it isn't always going to work
(I've seen different handsets interpret "delivery report" differently,
and because it is SMS both the message and the report could get lost on
the way or delayed).
>
> I don't have the specs to hand, but I seem to remember that up to 8
> short messages can be concatenated if you have a long message to send.
> Of course, you'll pay 8 times! And not all handsets, mainly the older
> ones, can display such a long message - it is truncated and the rest lost.
>
The old phone I used to use just displayed them as several texts (which
they are) rather than discarding them, and I'd expect that to be the
normal situation.
- 12-20-2008, 08:05 AM #23Mizter TGuest
Re: Rail companies roll out barcode ticket standard
On 20 Dec, 12:25, disgoftunwells <[email protected]> wrote:
> On 20 Dec, 00:59, Mizter T <[email protected]> wrote:
>
> (big snip including comprehensive reply from Robert)
>
> > That's a fascinating reply, thanks very much (and it truly illustrates
> > usenet's splendid capacity to share knowledge!). Elements of the so-
> > called Phase 2+ of the GSM specs appear to hold the answer as to how
> > these graphical SMS messages work.
>
> > Still a bit curious as to whether such a single SMS 'payload' could
> > possibly contain two different types of graphical message (i.e. both
> > EMS and Nokia), though Mr Thant's post earlier stated that the barcode
> > message on his Sony Ericsson was likely to be of the EMS type when he
> > had previously thought his handset only supported the Nokia 'standard'
> > - so perhaps EMS has in fact been rather more universally adopted by
> > manufacturers.
>
> > And I'm also curious as to how they know how to send a WAP push
> > message (which unless I'm mistaken is just a text with a WAP link in
> > it) instead of a text message to handsets that cannot support the
> > latter (i.e. smartphones). I have just gone through the Chiltern
> > Railway 'tckts by txt' purchasing process up to the point of payment
> > and it only asked for confirmation of the "mobile make" i.e.
> > manufacturer - no indication of whether the mobile is a smart or dumb
> > Nokia, for example.
>
> I think Robert summed up the technology better than I can.
>
> On the Chiltern site you enter your phone model so it knows whether to
> try and send Nokia Picture Messaging, EMS, Wap Push / embedded
> hyperlink, or plain text.
>
> Of course, the problem is with a Nokia Smartphone? Is it WAP Push or
> Nokia Picture Messaging. What about an ancient Nokia brick? Is it
> plain text or Nokia Picture Messaging? However, if the system gets it
> wrong, then the user should always get the plain text ticket number
> which the inspectors can key in. (The old bricks will receive an EMS,
> but only display the text, not the image. The only real problem is if
> you enter "Smart Phone" but actually have an old brick).
>
> All this works because the tickets are type "Advance". The new RSP
> tickets will need to be a lot more sure that the phone can display
> them.
>
Thanks for some more details, much appreciated. So it appears that the
SMS containing the barcode ticket that Chiltern send out is in fact
different according to the make of phone that the customer has. And
thanks for making clear what the old bricks do when they get an EMS -
i.e. simply display the text - I was curious as to whether they might
display gibberish, but thankfully they do not.
Regarding the new RSP tickets - the associated online sales process
will obviously have to deal with this issue very carefully. I suppose
the easiest thing would be to have a test MMS message sent to the
punter to see if they can get it. The point you make about people
being able to find their MMS inbox is a really good one - and that's
not necessarily dealt with by a test message, as the punter will be
sat waiting for that test to arrive and once it does the phone will
almost certainly present an option to jump straight to the message, so
they still might not be any the wiser as to how to get to the MMS
inbox. I can imagine guards and gateline staff becoming expert in
operating many different models of handsets!
- 12-20-2008, 04:06 PM #24RobertGuest
Re: Rail companies roll out barcode ticket standard
On 2008-12-20 13:54:22 +0000, Stuart Clark <[email protected]> said:
> Robert wrote:
>> On 2008-12-19 21:07:11 +0000, Theo Markettos
>> <[email protected]> said:
>>
>>> In uk.telecom.mobile Mizter T <[email protected]> wrote:
>>> queue in the network and the sender won't be able to alter it. Or is there
>>> some way bulk SMS senders can know if a particular phone is on? If there
>>> is, it raises all sorts of privacy issues.
>>
>> Unless you try phoning the party you wish to send a message to, the
>> originator of a short message does not know if any particular phone is
>> switched on, and there is no signalling in the network via the Short
>> Message Service that will inform the originator of the phone's status.
>>
>
> By using two of the features mentioned in your messages you can find
> this out (though it isn't foolproof). Send an "invisible" text to the
> number with delivery reporting activated. When the text is received
> nothing is displayed to the user, but the originator is informed of the
> delivery.
>
> However, I doubt this technique is much used, as firstly it costs an
> extra text fee to deliver this initial invisible text, secondly is
> asynchronous in its nature, and thirdly it isn't always going to work
> (I've seen different handsets interpret "delivery report" differently,
> and because it is SMS both the message and the report could get lost on
> the way or delayed).
It might work depending on the handset, but as you say, the handsets
vary between manufacturer and also over time. What might work with one,
definately won't with another.
Just to clarify one point. The short messages a caller can send,
whether from a handset by keying in the message or from a web portal
will only ever be the type that indicates on the target handset that a
message has been received. The other types, those for immediate display
and those intended for data updates, can only be originated by the
network, or an entity which has approved access to the network.
>
>>
>> I don't have the specs to hand, but I seem to remember that up to 8
>> short messages can be concatenated if you have a long message to send.
>> Of course, you'll pay 8 times! And not all handsets, mainly the older
>> ones, can display such a long message - it is truncated and the rest
>> lost.
>>
>
> The old phone I used to use just displayed them as several texts (which
> they are) rather than discarding them, and I'd expect that to be the
> normal situation.
Some phones show concatenated messages as several individual ones,
others can recombine the messages and present them as one message. It
depends on manufacturer and model, the newer ones tending to be better.
Some just truncate them, some old Siemens models come to mind (M75 and
similar?) which chopped them at something like 750 characters.
--
Robert
- 12-21-2008, 03:37 AM #25Stuart ClarkGuest
Re: Rail companies roll out barcode ticket standard
Robert wrote:
>
> Just to clarify one point. The short messages a caller can send, whether
> from a handset by keying in the message or from a web portal will only
> ever be the type that indicates on the target handset that a message has
> been received. The other types, those for immediate display and those
> intended for data updates, can only be originated by the network, or an
> entity which has approved access to the network.
>
Sorry, I wasn't referring to something a "normal" user could do, but
something which could be done by a company with access to a "bulk SMS"
web service. I know Clickatel at least used to give that sort of access.
>>
>>>
>>> I don't have the specs to hand, but I seem to remember that up to 8
>>> short messages can be concatenated if you have a long message to
>>> send. Of course, you'll pay 8 times! And not all handsets, mainly the
>>> older ones, can display such a long message - it is truncated and the
>>> rest lost.
>>>
>>
>> The old phone I used to use just displayed them as several texts
>> (which they are) rather than discarding them, and I'd expect that to
>> be the normal situation.
>
> Some phones show concatenated messages as several individual ones,
> others can recombine the messages and present them as one message. It
> depends on manufacturer and model, the newer ones tending to be better.
> Some just truncate them, some old Siemens models come to mind (M75 and
> similar?) which chopped them at something like 750 characters.
>
This was with a phone which was too old to support EMS/Nokia long messages.
- 12-21-2008, 04:11 AM #26Mizter TGuest
Re: Rail companies roll out barcode ticket standard
On 21 Dec, 09:37, Stuart Clark <[email protected]> wrote:
> Robert wrote:
>
> > Just to clarify one point. The short messages a caller can send, whether
> > from a handset by keying in the message or from a web portal will only
> > ever be the type that indicates on the target handset that a message has
> > been received. The other types, those for immediate display and those
> > intended for data updates, can only be originated by the network, or an
> > entity which has approved access to the network.
>
> Sorry, I wasn't referring to something a "normal" user could do, but
> something which could be done by a company with access to a "bulk SMS"
> web service. I know Clickatel at least used to give that sort of access.
>
And no resulting message got displayed on the handset? If so it does
rather sound like an abuse of the access to the network they had.
- 12-22-2008, 08:51 AM #27Stevie PlunderGuest
Re: Rail companies roll out barcode ticket standard
* disgoftunwells wrote:
> There has been some use of MMS tickets (on Hull Trains?) but there the
> user needs to receive a test ticket and confirm its receipt.
Virgin Trains via Mobitix use DCF files (as a container) to encapsulate
19kB 256 colour 200x 240 JPEG file types.
- 12-22-2008, 08:55 AM #28Stevie PlunderGuest
Re: Rail companies roll out barcode ticket standard
* Stevie Plunder wrote:
> * disgoftunwells wrote:
>> There has been some use of MMS tickets (on Hull Trains?) but there the
>> user needs to receive a test ticket and confirm its receipt.
>
> Virgin Trains via Mobitix use DCF files (as a container) to encapsulate
> 19kB 256 colour 200x 240 JPEG file types.
... and you actually download the file via a link in a text they send you
(WAP).
To see if your phone works you have to register it by way of confirming
receipt of a dummy ticket.
Similar Threads
- alt.cellular.verizon
- alt.cellular.verizon
Lifeline cell phone service
in Chit Chat