Page 2 of 2 FirstFirst 12
Results 16 to 28 of 28
  1. #16
    Mizter T
    Guest

    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




  2. #17
    Theo Markettos
    Guest

    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



  3. #18
    Mr.G
    Guest

    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?



  4. #19
    Robert
    Guest

    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




  5. #20
    Mizter T
    Guest

    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.



  6. #21
    disgoftunwells
    Guest

    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.



  7. #22
    Stuart Clark
    Guest

    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.



  8. #23
    Mizter T
    Guest

    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!



  9. #24
    Robert
    Guest

    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




  10. #25
    Stuart Clark
    Guest

    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.



  11. #26
    Mizter T
    Guest

    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. #27
    Stevie Plunder
    Guest

    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.



  13. #28
    Stevie Plunder
    Guest

    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




  • Page 2 of 2 FirstFirst 12