SamyGO

I think the most interesting thing is how the message parameter must be defined. Playing around with various formats of the MessageID should not be the problem.

The PMR requires a lot of information (service type, recipient, sender, message, time) but all this information must be included somehow into only one tag. So it would be great if someone could find out how the exeDSP parses the message (is there a divider character bethween the parameters? Are there numeric or char-based identifiers for the service type (sms, call or calendar)?) The ARM assembler is too difficult for me.

Still you did not convinced me that you get to the point that TV parses your message. Please post or send me your exact requests and responses from TV with/without MessageID so I can check exeDSP.

After checking exeDSP, I think, Message should look something like following:
So, just simple XML. Similar tags are used for other types (Calendar, Incomming call). Nothing else is checked/parsed from the request when TV parses AddMessage node.

Doodlecz, can you give me the function names thats related with this function(s)?

Your mistake is clear:

Message Type is used to define the MIME type of the message and can be left unset. It defaults to text/utf-8.

To differ bethween calls, sms and schedules, the category parameter is used. And this is an essential parameter because the exeDSP parses it in a case-of switch to decide which function will continue parsing the message. And there are three different classes:

PmrIncomingCallMessage
PmrSmsMessage
PmrScheduleMessage

I could only read out that one of these functions is called in different cases but not the necessary values of the category tag. It is possibly a word (sms, call, schedule) or an numeric ID (either 0,1,2 or a proprietary service identifier -> GSM service codes?)

In the past we believed that the words above are suitable values but these only identify functions to be called.

Furthermore unused tags are usually not set! Instead of <Tag></Tag> drop this completely out!

A thing come my mind,
Since we can up/down volume via uPNP: http://forum.samygo.tv/viewtopic.php?f=6&t=190
Could we use same format for messages? Might be sniffing this packages could give us a idea about exact formatting.

I'm sorry, I'm not home this weekend, so I cannot give you exact function names etc. But functions are those sumihe mentions. Or just find string reference to the MessageID, parsing functions are somewhere bellow.

Format for other types (for Calendar and Incomming Call) is pretty clear, also switching to parsing different type by different function is clear and is made on the Category parameter (imo text "SMS" is sms type etc.)

But I have to repeat myself, right now imo TV doesn't get to parsing AddMessage node! Or at least in my tests. exeDSP should print out some debug logs when parsing the content, but it didn't. Very simple.

I.e. returned message mentioned by sumihe:
Try to find by yourself the function which references "Invalid Request!!!!" string. This function is NOT about parsing content of the message but IMO some session management or something like this ("does TV know requester device?").
So anyone can find out the date/time format or XML format for other class types (they are very easy to find out) but it is not the problem which should bother us right now or at least, till the time when someone posts exact error response which could be related to the content parsing. But till now, no one did.

I played around with some XML texts yesterday and found one thing out: If no <MesageSizeType> is defined into the <Message> tag, I receive error 412 - precondition failed. If this tag is set, I get error 500.

This means that sub-tags are parsed and required. This means, neither experiments like
<Message category="sms" sender="12345">body-text</Message>
are necessary, nor experiments like
<Message>category:sms:sender:12345:body:body-text</Message>

<ReceiveTime> seems to be a parameter, that is used very often in different soap requests. Google shows lots of hit when searching for this tag. In most cases, the format is:
In a few cases, a time-span is entered into this tag but this makes no sense on calls and sms.

There seems not to be any Session management. DLNA servers send SOAP requests around to look up for servers and clients but not every time before sending data. A running media server on your test computer may do this task (if it's really necessary).

Possible values for MessageSizeType are:
Minimum -> normal SMS
Incoming Call -> incoming calls
Schedule Reminder -> calendar schedules
Maximum -> multipart SMS messages

It seems like if MessageBoxService::ParseMessageType parses this parameter and if MessageBoxService::ParseSMSMessage is called again. Inside ParseSMSMessage there is a loop to process slightly different code if the SMS message is long.

Found out, that the CATEGORY tag is required too, even if the category is identifiable with the MESSAGESIZETYPE too.

I hope, I found out all the necessary tags:

always required:
messageID => urn:uuid:[NUMBER]
category => identifies the service, possible values still unknown (INT or CHAR* is not clear)
messageSizeType => Minimum, Maximum, Incoming Call, Schedule Reminder
expireState => unknown

incoming calls:
callTime => yyyy-mm-ddThh:mm:ss.sssZ
callee => called number (ISDN MSN, number of the ringing mobile)
caller => phone number of the recipient

SMS:
receiveTime => see callTime
receiver => phone number or name?
sender => phone number or name?
body => text message

calendar:
startTime => see callTime
endTime => see callTime
owner => username?
subject => name of calendar entry?
location => calendar name
body => event detail text?