Protocols/MSNP/MSNC/Display pictures
| MSNP Protocol |
| MSNC |
| Overview • MSNObject |
| Client Capabilities |
| P2P protocol |
| Transports • MSNSLP |
| Headers |
| P2Pv1 Binary headers |
| P2Pv2 Binary headers |
| Transfers |
| Display Pictures |
| Custom Emoticons |
| File Transfer |
| Overview |
| Introduction • Terms • Clients |
| Reference |
| Error List • Commands • Relying Party Suite • Spotlife |
| Services |
| XMPP • HTTP Gateway • Tabs • Activities |
| Documentation |
| Development Tools • MSNP Grid |
| Polygamy • URLs used by MSN |
| Documents |
| Protocol Versions |
| Version 21 |
| Version 18 |
| Version 16 |
| Version 15 |
| Version 14 |
| Version 13 |
| Version 12 |
| Version 11 |
| Version 9 |
| Version 8 |
| Version 2 |
| MSNC |
| Introduction • P2P • Object Descriptor • Display Pictures • File Transfer |
| Scenarios |
| Microsoft Messenger for Mac |
| MSNP on WebTV (MSNTV) |
Overview
Sending and receiving display pictures doesn't only depend on the MSNSLP protocol, but also on schemes being used by the binary header and footer. The scheme for sending or receiving display pictures isn't the same as for receiving files. The scheme for sending and receiving display pictures is not very difficult: Just go with the flow. If some fields of the binary string aren't discussed in a message, you should set it's value to zero.
A display picture transfer will go like this:
- << Invitation
- >> Acknowledgement
- >> 200 OK
- << Acknowledgement
- >> Data preparation message
- << Acknowledgement
- >> Data piece 1
- >> Data piece 2
- ...
- >> Data piece n (Actually the data is only ONE message, split in parts)
- << Acknowledgement (Therefore only one acknowledgement is send after the last packet)
- (The picture should now be visible)
- << BYE
- >> Acknowledgement
Note that all messages in this flow are mandatory: the official MSN client will refuse your display picture if you don't send acknowledgements or set the binary header fields incorrectly.
First, the receiving client (RC) sends the sending client (SC) an invitation to start a session. The Identifier field of that invitation should contain a generated BaseIdentifier, the Identifier field of the following messages should be calculated from that BaseIdentifier. The identifier of the next messages send by the SC should be BaseIdentifier - 3, BaseIdentifier - 2 and so on. If the field reaches the BaseIdentifier again, you should proceed with BaseIdentifier + 1, BaseIdentifier + 2 and so on.
The receiving client should on its turn send messages with BaseIdentifier + 1, BaseIdentifier + 2 and so on as values for the Identifier field.
Invitation message
- See Invite Request
Binary header
- The receiving client should generate a BaseIdentifier and set is as value of the Identifier field.
Content
- CSeq is 0
- EUF-GUID is {A4268EEC-FEC5-49E5-95C3-F126696BDBF6} to indicate that it's an invite to send a display picture.
- SessionID must have the Session Identifier as value.
- AppID is 1
- Context is the base64 encoded string of the MSNObject
- As always when sending MSNSLP, append NUL (0x00 character) to the end of the message.
Binary footer
- Application Identifier is 0
Example:
MSG 1 D 800 MIME-Version: 1.0 Content-Type: application/x-msnmsgrp2p P2P-Dest: buddy1@hotmail.com
00 00 00 00 58 A9 18 01 00 00 00 00 00 00 00 00
91 02 00 00 00 00 00 00 91 02 00 00 00 00 00 00
AB 38 1E 00 00 00 00 00 00 00 00 00 00 00 00 00
INVITE MSNMSGR:buddy1@hotmail.com MSNSLP/1.0
To: <msnmsgr:buddy1@hotmail.com>
From: <msnmsgr:me@hotmail.com>
Via: MSNSLP/1.0/TLP ;branch={33517CE4-02FC-4428-B6F4-39927229B722}
CSeq: 0
Call-ID: {9D79AE57-1BD5-444B-B14E-3FC9BB2B5D58}
Max-Forwards: 0
Content-Type: application/x-msnmsgr-sessionreqbody
Content-Length: 326
EUF-GUID: {A4268EEC-FEC5-49E5-95C3-F126696BDBF6}
SessionID: 1980589
AppID: 1
Context: PG1zbm9iaiBDcmVhdG9yPSJidWRkeTFAaG90bWFpbC5jb20iIFNpemU9IjI0NTM5IiBUeXBlPSIzIiBMb2NhdGlvbj0iVEZSMkMudG1wIiBGcmllbmRseT0iQUFBPSIgU0hBMUQ9InRyQzhTbEZ4MnNXUXhaTUlCQVdTRW5YYzhvUT0iIFNIQTFDPSJVMzJvNmJvc1p6bHVKcTgyZUF0TXB4NWRJRUk9Ii8+DQoA
00
00 00 00 00
Invitation acknowledged message
- Identifier is the generated BaseIdentifier
Example:
MSG buddy1@hotmail.com D 139 MIME-Version: 1.0 Content-Type: application/x-msnmsgrp2p P2P-Dest: me@hotmail.com
00 00 00 00 3B 99 4F 02 00 00 00 00 00 00 00 00 91 02 00 00 00 00 00 00 00 00 00 00 02 00 00 00 58 A9 18 01 AB 38 1E 00 91 02 00 00 00 00 00 00 00 00 00 00
200 OK message
If everything is okay, the SC can respond with a 200 OK message. But if there are some things it doesn't accept, it should send another error back instead of 200 OK. For the Identifier it doesn't matter if it's a 200 OK, a 404 Not Found or something else.
Binary header
- SessionID is 0
- Identifier is the next available sending client sequence identifier. The other fields have the same value as those described by the invitation message.
Content
- CSeq is the value of the CSeq field from the invitation message + 1
- SessionID is the same as in the invitation message
Binary footer
- Application Identifier is 0
Example:
MSG buddy1@hotmail.com D 417 MIME-Version: 1.0 Content-Type: application/x-msnmsgrp2p P2P-Dest: me@hotmail.com
00 00 00 00 38 99 4F 02 00 00 00 00 00 00 00 00
46 01 00 00 00 00 00 00 46 01 00 00 00 00 00 00
4B 99 4F 02 00 00 00 00 00 00 00 00 00 00 00 00
MSNSLP/1.0 200 OK
To: <msnmsgr:me@hotmail.com>
From: <msnmsgr:buddy1@hotmail.com>
Via: MSNSLP/1.0/TLP ;branch={33517CE4-02FC-4428-B6F4-39927229B722}
CSeq: 1
Call-ID: {9D79AE57-1BD5-444B-B14E-3FC9BB2B5D58}
Max-Forwards: 0
Content-Type: application/x-msnmsgr-sessionreqbody
Content-Length: 23
SessionID: 1980589
00 00 00 00 00
200 OK acknowledged message
- Identifier is the next available receiving client sequence identifier
Example:
MSG 2 D 143 MIME-Version: 1.0 Content-Type: application/x-msnmsgrp2p P2P-Dest: buddy1@hotmail.com
00 00 00 00 59 A9 18 01 00 00 00 00 00 00 00 00 46 01 00 00 00 00 00 00 00 00 00 00 02 00 00 00 38 99 4F 02 4B 99 4F 02 46 01 00 00 00 00 00 00 00 00 00 00
Data preparation message
If the sending client received the 200 OK acknowledged message from the receiving client it should send a "data preparation message".
Binary header
- SessionID is the SessionID as from the invitation message
- Identifier is the next available sending client sequence identifier
- Total data size is 4, because the data in this message is four bytes long.
- Unique Identifier (seventh field) should have a random number
Content
- This message should have 4 NUL (0x00 characters) as data.
Binary footer
- Application identifier is differently from previous messages, 1. Because this is big endian (big end first), the binary string looks like this: 0x00 0x00 0x00 0x01
Example:
MSG buddy1@hotmail.com D 143 MIME-Version: 1.0 Content-Type: application/x-msnmsgrp2p P2P-Dest: me@hotmail.com
AD 38 1E 00 39 99 4F 02 00 00 00 00 00 00 00 00 04 00 00 00 00 00 00 00 04 00 00 00 00 00 00 00 57 99 4F 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01
Data preparation acknowledged message
- Identifier field is the next available receiving client sequence identifier
Example:
MSG 3 D 143 MIME-Version: 1.0 Content-Type: application/x-msnmsgrp2p P2P-Dest: buddy1@hotmail.com
AD 38 1E 00 5A A9 18 01 00 00 00 00 00 00 00 00 04 00 00 00 00 00 00 00 00 00 00 00 02 00 00 00 39 99 4F 02 57 99 4F 02 04 00 00 00 00 00 00 00 00 00 00 00
Data message(s)
If everything till now was alright, the sending client can send the content of the display picture file. Although it is only one message, it is generally big enough to have to be split into several MSG commands, each with a binary header and footer:
Binary header
- Identifier is the next available sending client sequence identifier
- SessionID is the SessionID
- Data offset is the bytes already sent
- Data length is the length of the file
- Message length is the size of the content of this P2P message
- Flag is 0x20 to indicate that this the message content is display picture or custom emoticon data
- Unique Identifier (seventh field) is a random number
Content
- This message should contain the content of the display picture file. (Which is often split)
Binary footer
- Application identifier is 1 big endian: 0x00 0x00 0x00 0x01
Example (start):
MSG buddy1@hotmail.com D 1341 MIME-Version: 1.0 Content-Type: application/x-msnmsgrp2p P2P-Dest: me@hotmail.com
AD 38 1E 00 3A 99 4F 02 00 00 00 00 00 00 00 00 78 05 00 00 00 00 00 00 B2 04 00 00 20 00 00 00 64 9A 4F 02 00 00 00 00 00 00 00 00 00 00 00 00 PNG File Data Start 00 00 00 01
Example (end):
MSG buddy1@hotmail.com D 337 MIME-Version: 1.0 Content-Type: application/x-msnmsgrp2p P2P-Dest: me@hotmail.com
AD 38 1E 00 3A 99 4F 02 B2 04 00 00 00 00 00 00 78 05 00 00 00 00 00 00 C6 00 00 00 20 00 00 00 78 9A 4F 02 00 00 00 00 00 00 00 00 00 00 00 00 PNG File Data End 00 00 00 01
When the complete data has arrived, the display picture should be visible if everything went fine. If you can't see it, check your MSN object and that every field in the messages have correct values.
Data acknowledged message
- Identifier is the next available receiving client sequence identifier
Example:
MSG 4 D 143 MIME-Version: 1.0 Content-Type: application/x-msnmsgrp2p P2P-Dest: buddy1@hotmail.com
AD 38 1E 00 5B A9 18 01 00 00 00 00 00 00 00 00 78 05 00 00 00 00 00 00 00 00 00 00 02 00 00 00 3A 99 4F 02 78 9A 4F 02 78 05 00 00 00 00 00 00 00 00 00 00
Note that only one acknowledgement is sent once all parts of the split data message have been received.
Bye message
- See Bye Request
Binary header
- Identifier is the next available receiving client sequence identifier
- SessionID is 0
- The other fields have the same value as those described by the Invitation Message
Content
- CSeq is 0
- The message body is a CRLF followed by a NUL (0x00 character)
Binary footer
- Application identifier is 0
Example:
MSG 5 D 472 MIME-Version: 1.0 Content-Type: application/x-msnmsgrp2p P2P-Dest: buddy1@hotmail.com
00 00 00 00 5C A9 18 01 00 00 00 00 00 00 00 00
49 01 00 00 00 00 00 00 49 01 00 00 00 00 00 00
04 9B 4F 02 00 00 00 00 00 00 00 00 00 00 00 00
BYE MSNMSGR:buddy1@hotmail.com MSNSLP/1.0
To: <msnmsgr:buddy1@hotmail.com>
From: <msnmsgr:me@hotmail.com>
Via: MSNSLP/1.0/TLP ;branch={A0D624A6-6C0C-4283-A9E0-BC97B4B46D32}
CSeq: 0
Call-ID: {9D79AE57-1BD5-444B-B14E-3FC9BB2B5D58}
Max-Forwards: 0
Content-Type: application/x-msnmsgr-sessionclosebody
Content-Length: 3
00 00 00 00 00
Bye acknowledged message
- Identifier is the next available sending client sequence identifier
Example:
MSG buddy1@hotmail.com D 139 MIME-Version: 1.0 Content-Type: application/x-msnmsgrp2p P2P-Dest: me@hotmail.com
00 00 00 00 3C 99 4F 02 00 00 00 00 00 00 00 00 49 01 00 00 00 00 00 00 00 00 00 00 02 00 00 00 5C A9 18 01 04 9B 4F 02 49 01 00 00 00 00 00 00 00 00 00 00