Spanning EMS ringtones over several SMS

Spanning EMS ringtones over several SMS SearchSearch

SMS & MMS Technical Forum » NowSMS Support - SMS Issues (Product Support Only) » Archive through March 09, 2004 » Spanning EMS ringtones over several SMS « Previous || Next »
Author Message
Anonymous
 
Posted on Tuesday, January 20, 2004 - 09:13 am:   

Hi !

I would like to send an EMS ringtone that spanns over 2 or 3 SMS. I can successfuly send an EMS ringtone in one SMS but I can not find any docs in how to split the ringtone in more parts.

Please help me
Liviu
Bryce Norwood - NowSMS Support
Board Administrator
Username: Bryce

Post Number: 1683
Registered: 10-2002
Posted on Tuesday, January 20, 2004 - 06:25 pm:   

You need to use the EMS UPI (User Prompt Indicator) format.

Someone posted an example of doing this for a picture at the following link:

http://support.nowsms.com/discus/messages/1/1758.html


If you have a longer iMelody that you can post, I might be able to help out with an example of how it would be encoded.

-bn
Anonymous
 
Posted on Wednesday, January 21, 2004 - 07:47 am:   

Hi !

This is the melody that is longer than 128 bytes:

BEGIN:IMELODY
VERSION:1.0
FORMAT:CLASS1.0
BEAT:120
MELODY:e3f3f3e3f3e3e3f3f3f3f1r2g3a3b3*5c3c2b3a3a4b4*5c1e3f3f3e3f3e3e3f3f3f3f1r2g 3a3b3*5c3c2b3f1r2g3a3b3*5c3c2b3a3a4c2b3a3a4b4
END:IMELODY

Liviu
Bryce Norwood - NowSMS Support
Board Administrator
Username: Bryce

Post Number: 1693
Registered: 10-2002
Posted on Thursday, January 22, 2004 - 04:45 pm:   

Liviu,

I'm going to take your example "almost as is" and explain how to encode it into a multipart EMS. The "BEAT:" parameter defaults to 120, so I'm going to omit that to simplify this example.

When you encode a melody into a multipart EMS, there are 12 bytes of UDH overhead in the first message part, and 9 bytes over UDH overhead in subsequent message parts.

This means that you can put a max of 128 bytes of melody into the first message part (140-12), and a max of 131 bytes of melody into subsequent message parts.

However, there's a catch. According to the EMS standard, you need to include the iMelody header and footer in each message part, although only the header in the first part is actually used. That is these parts:

BEGIN:IMELODY
VERSION:1.0
FORMAT:CLASS1.0

END:IMELODY

Combined, these account for 58 bytes of overhead in each message part. 45 bytes for the header (you must include a carriage return and line feed after each line of text), 13 bytes for the footer (carriage return and line feed required after END:IMELODY).

Plus, you've got overhead for text "MELODY:" and the carriage return and line feed required after the melody data. That is 9 more bytes of overhead.

So we've got 67 bytes of overhead for each message part within the iMelody data itself.

This means that we can transport 61 (128-67) bytes of actual melody data in the first message. And 64 (131-67) bytes of actual melody data in subsequent message parts.

(Note: Some phones do not require the iMelody headers. But it is up to you to test which ones if you want to use a shortened format.)

So let's get back to your melody.

If we just look at your melody data:

e3f3f3e3f3e3e3f3f3f3f1r2g3a3b3*5c3c2b3a3a4b4*5c1e3f3f3e3f3e3e3f3f3f3f1r2g3a3b3*5 c3c2b3f1r2g3a3b3*5c3c2b3a3a4c2b3a3a4b4

We have 118 bytes of actual melody data. We can easily fit that into two messages.

The first iMelody object gets the first 61 bytes of iMelody data, and becomes:

BEGIN:IMELODY
VERSION:1.0
FORMAT:CLASS1.0
MELODY:e3f3f3e3f3e3e3f3f3f3f1r2g3a3b3*5c3c2b3a3a4b4*5c1e3f3f3e3f3e3e
END:IMELODY

The second iMelody object gets the remainder of the data:

BEGIN:IMELODY
VERSION:1.0
FORMAT:CLASS1.0
MELODY:3f3f3f3f1r2g3a3b3*5c3c2b3f1r2g3a3b3*5c3c2b3a3a4c2b3a3a4b4
END:IMELODY

Now we encode the messages to be sent out.

Message #1:

8B (UDH Len = 8B hex / 139 decimal)
0003EE0201 (Concatenated message id EE, Message 1 of 2)
130102 (EMS UPI - 2 parts)
0C8100 (EMS iMelody, length = 81 hex / 129 decimal - one byte larger than actual iMelody data to include offset, offset = 0)
424547494E3A494D454C4F44590D0A56455253494F4E3A312E300D0A464F524D41543A434C415353 312E300D0A4D454C4F44593A65336633663365336633653365336633663366336631723267336133 62332A356333633262336133613462342A356331653366336633653366336533650D0A454E443A49 4D454C4F44590D0A

(The last bit is the hex representation of the first iMelody object.)

Message #2:

84 (UDH Len = 84 hex / 132 decimal)
0003EE0202 (Concatenated message id EE, Message 2 of 2)
0C7D00 (EMS iMelody, length = 7D hex / 125 decimal - one byte larger than actual iMelody data to include offset, offset = 0)
424547494E3A494D454C4F44590D0A56455253494F4E3A312E300D0A464F524D41543A434C415353 312E300D0A4D454C4F44593A33663366336633663172326733613362332A35633363326233663172 326733613362332A3563336332623361336134633262336133613462340D0A454E443A494D454C4F 44590D0A

(The last bit is the hex representation of the second iMelody object.)

-bn

Login Login / Register Logout Logout Search Last 30 Days Topics Topics