| Send Polyphonic sound with EMS |  Search
|
|
NowSMS Support Forums ⬆ NowSMS Support - SMS Issues ⬆ Archive through January 17, 2005 ⬆ |
◄ ► |
| Author | Message | |||
| Hichem Zait New member Username: Hichem Post Number: 2 Registered: 12-2004 |
Hello ! I am trying to split a long EMS Polyphonic message. I receive symbols but not the desired Polyphonic sound, so I guess that I do not use the UDH correctly ; First messages: 0f [UDHL] 0003010201 [Concatenation information] 140789010082030c0001 [Extended Object Header] 4d546864000000060001000200c04d54726b0000008a00ff030371717100ff010e4279206b686569 72656464696e6500ff021f436f7079726967687420a92032303034206279206b6865697265646469 6e6500ff0213416c6c2052696768747320526573657276656400ff012047656e6572617465642062 79204e6f7465576f727 Second Message : 0f [UDHL] 0003010202 [Concatenation information] 140789010082030c0001 [Extended Object Header] 4687920436f6d706f73657200ff51030927c000ff58040402180800ff2f004d54726b000004b100f f21010000ff030753746166662d3100b1077f00b10a400091406e81209140002091396e0091456e0 091486e00914c6e810e91480000914c000291486e00914c6e2e91480000914c000291486e00914c6 e5e91480000914c0002 As I mentioned, I receive a message but an empty one, so I guess there is something wrong with the headers. Has anyone tried something like this ? Thanks Hichem | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 3842 Registered: 10-2002 |
Hi Hichem, I have never used Extended Object Header. I've always used UPI (User Prompt Indicator) for sending larger objects in EMS. My impression was that UPI was more widely supported because it was defined earlier in the specifications, while the extended object header approach came in later releases. But then again, you're sending a MIDI, which was not supported in early EMS releases ... and according to the specs, MIDI has to be sent in an extended object. Since I've never used Extended Object Header encoding, your message has me curious. The first problem that I notice is that the object data needs to be part of the header. So your UDHL and IEDL for the extended object header would be incorrect, as they are not including them. So let's take a closer look at your example above, and correct the lengths. The first problem that I see trying to correct the lengths is that each of your messages has an uneven number of semi-octets. What I'm referring to is the data that follows your extended object header. There are an uneven number of characters in the hex string that follows. It takes two hex characters to represent a byte, so I think you've broken the data at an inappropriate boundary. There is also more than 140 bytes for each message so that is also going to be a problem. So I'm going to start by putting your object data back together into one piece: 4d546864000000060001000200c04d54726b0000008a00ff030371717100ff010e4279206b686569 72656464696e6500ff021f436f7079726967687420a92032303034206279206b6865697265646469 6e6500ff0213416c6c2052696768747320526573657276656400ff012047656e6572617465642062 79204e6f7465576f7274687920436f6d706f73657200ff51030927c000ff58040402180800ff2f00 4d54726b000004b100ff21010000ff030753746166662d3100b1077f00b10a400091406e81209140 002091396e0091456e0091486e00914c6e810e91480000914c000291486e00914c6e2e9148000091 4c000291486e00914c6e5e91480000914c0002 That looks like 259 bytes of data. Since a single SMS is limited to 140 bytes of binary data, it looks like this is going to require 3 SMS messages, because the headers are also going to add to the size. So let's start building the headers ... here's my best guess of how they should be encoded: Message #1: 8B [UDHL=139,max size we can get in 140 bytes] 0003010301 [Concatenation information] 1485FF0103000C0000 [Extended Object Header] [14 = Extended Object IEI] [85 = Len] [FF = extended object ref #] [01 03 = total size of object ... 103 hex = 259 dec] [00 = extended object control data] [0C = extended object type = polyphonic melody] [00 00 = extended object position] [start of extended object data follows] 4d546864000000060001000200c04d54726b0000008a00ff030371717100ff010e4279206b686569 72656464696e6500ff021f436f7079726967687420a92032303034206279206b6865697265646469 6e6500ff0213416c6c2052696768747320526573657276656400ff012047656e6572617465642062 79204e6f74 Message #2: 8B [UDHL=139,max size we can get in 140 bytes] 0003010302 [Concatenation information] 1485 [Extended Object IEI and Len] [continuation of extended object data] 65576f7274687920436f6d706f73657200ff51030927c000ff58040402180800ff2f004d54726b00 0004b100ff21010000ff030753746166662d3100b1077f00b10a400091406e81209140002091396e 0091456e0091486e00914c6e810e91480000914c000291486e00914c6e2e91480000914c00029148 6e00914c6e5e91480000914c Message #3: 09 [UDHL=9 to cover remaining data] 0003010303 [Concatenation information] 1402 [Extended Object IEI and Len] [continuation of extended object data] 0002 I've tried to send these messages out to a couple of recent EMS compatible mobile phones, but they don't seem to understand the content. Overall, while newer versions of the EMS spec cover MIDI, I'm not sure that the phone client developers have bothered to implement. EMS is one of those things where the spec keeps evolving, but vendor implementations stay with the older specs ... especially since there are better ways to deliver multimedia content with MMS and WAP. -bn | |||
