Discussion Board

Results 1 to 2 of 2
  1. #1
    Registered User
    Join Date
    Mar 2003

    Arrangement of Command-Part Encoding For Ringtones


    Thanks for reading this. I'm having problems interpreting the NSM specification (v3.0) for ringtones, in particular the number of <sound> command parts a ringtone can have.

    My interpretation is a ringtone will contain command parts as follows (ignoring the optinal <unicode> part for this example):

    <ringing-tone-programming> <sound> <ringing-tone-programming> <sound>

    My small parser looks for <ringing-tone-programming>,puts itself in programming mode and then expects <sound> when we continue parsing. The way the code is written we always expect <r-t-p> and then <sound>.

    I managed to obtain a ringtone which seems to differ from this, for example:
    <r-t-p> <sound> <sound>

    So in my program it returns an error as it doesn't expect the third <sound> command straight after a <sound> command. Is this correct and is such a method of representing ringtones widely used ? Why would a ringtone need to have two <sound> command parts ?

    Again thanks and any help or comments would be grately appreciated,



  2. #2
    Super Contributor
    Join Date
    Mar 2003

    RE: Arrangement of Command-Part Encoding For Ringtones

    I would interpret the specification that way that there can be only
    two command parts <ringing-tone-programming>,<sound> in one
    concatenated smart message and that is it.
    I admit that this specification leaves room for speculation:
    <r-t-p> <sound> <sound> <sound> <sound> <sound> <sound> <sound>
    <r-t-p> <sound> <r-t-p> <sound> <r-t-p> <sound> <r-t-p> <sound>
    But wouldn't these then contain several ringing tones with names
    of their own. I don't think that phones are able to receive more
    than one ringing tone at a time.
    M, Forum Nokia

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts