MSNC:MSNSLP

From MSNPiki

Jump to: navigation, search
MSN Client Protocol

Overview · MSNObject · Client Capabilities
P2P protocol: Transports · MSNSLP
Headers: P2Pv1 Binary headers · P2Pv2 Binary headers
Transfers: Display Pictures · Custom Emoticons · File Transfer

Contents

MSNSLP

With MSN Messenger 6 a new sort of protocol is introduced and is based on SIP (Session Initiation Protocol). SIP is explained in RFC2543. MSNSLP is pretty much the same as SIP, but supports less request methods.

MSNSLP uses only the INVITE, BYE, and ACK methods, the latter only used in messages with content type application/x-msnmsgr-transudpswitch. If you are sending an unknown method, then the other client only sends its BaseIdentifier and nothing else after it.

MSNSLP structure

MSNSLP messages follow this structure:

Start Line

If it is a request, the start line will be a request line and will look like this:

method SPACE MSNMSGR:buddy@mail.com SPACE version \r\n

The method field is either INVITE to start a session and BYE to end a session. If you receive a second INVITE message in a session, then it's used to change the session parameters, you should accept it if everything is okay.

The version is currently MSNSLP/1.0


When not a request, the start line is a status line consisting of the protocol version followed by a numeric status code and its associated textual phrase, with each element separated by space characters.

version SPACE status code SPACE reason phrase \r\n

The status code is a 3-digit integer result code that indicates the outcome of the attempt to understand and satisfy the request. Your client must read the status code to determine whether this is a 200 OK or for example a 404 not found.

Message Header

Among the message headers are always in the following order these:

When you receive an incoming message, you certainly need to check some fields whether or not they have the right values. If some data is missing or wrong, you should always send an error back. For further information read the error handling section of this document. The fields of the message header which you certainly should check are the To, the Content-Type and the Content-Length.

Message Body

The message body depends on the type of data requested and it must always have a NUL (\0 character) appended to it at the end. For information about the content of the message body see the relevant sections.

MSNSLP messages

INVITE Request

A message with INVITE as method can represent two things, namely a request to start a session or a request to change the sessions parameters. But in both cases most of the field have the same value.

Starting a session

When you want to start a session over the server, you should set the Content-Type to application/x-msnmsgr-sessionreqbody and you should add the following content fields: EUF-GUID, SessionID, AppID, Context

Starting a transfer session

When you want to transfer something to the other client, you should set the Content-Type to application/x-msnmsgr-transreqbody and you should add the following content fields: Bridges, NetID, Conn-Type, UPnPNat, ICF

BYE Request

To end an active session, you should always send a message with "BYE" as method to the other client. The Content-Type should have the value application/x-msnmsgr-sessionclosebody, the content should then be two times a CRLF. Also, if the session parameters where changed, you should just send one message with BYE as method.

Error Responding

When you receive an MSNSLP message, if some data is missing or wrong you should always send an error back. But in some cases errors are used to indicate that something processed with success or that a file transfer was declined.

If the value of the "To" header contains email addresses which isn't yours, you should reply with a 404 Not Found on the status line. The "From" should have the value <msnmsgr:wrong_mail@hotmail.com> where wrong_mail@hotmail.com isn't your email address. The Content-Type should be null and it shouldn't have content, so the Content-Length is zero.

If the Content-Type of the message received is not supported by your client, you should reply with a 500 Internal Error on the status line. The Content-Type should be null and it shouldn't have content, so the Content-Length is zero.

If some fields in the message body contain a value you don't agree with, you should also reply with a 500 Internal Error on the status line, but the Content-Type should have the same value as the received message. The message body should now only have the field SessionID with the identifier of the session as value.

Status line codes

200 OK

There are two different messages with 200 as Status-Code, namely one to accept an Invitation for a session via the server and one to accept an Invitation for a direct session between two clients.

If it's a reply to accept an Invitation for a session via the server you should generate a new BranchUID and add it to the ";branch=" text. You should also set the value of the "Content-Type" to "application/x-msnmsgr-sessionreqbody". And you also have to put the "SessionID" field into the Message Body with the Identifier of the Session as value.

If it's a reply to accept an Invitation for a direct session between two clients, you should then also generate a new BranchUID and add it to the ";branch=" text. But now the Message Body contains more fields. The field it contains are: "Bridge", "Listening", "Nonce", "IPv4External-Addrs" and "IPv4External-Port" or "IPv4Internal-Addrs" and "IPv4Internal-Port" or "IPv4ExternalAddrsAndPorts" or "IPv4InternalAddrsAndPorts" or "IPv6-Addrs" and "IPv6-Port" and "IPv6-global".

The "Bridge" field tells the other client which transport layer was chosen.

The "Listening" field tells the other client if it is already listening on the port and IP-address specified.

The "Nonce" field value is being used by the other client to "Authorize" itself via the direct connection.

If the client is behind NAT, the "IPv4Internal-Addrs" and "IPv4External-Addrs" fields contain the local and public IP-address. If the client is not behind NAT the "IPv4Internal-Addrs" field contains the public IP-address.

The "IPv4Internal-Port" and the "IPv4External-Port" fields contain the port to which you need to connect.

IMPORTANT: At the time of writing no further information is known about the IPv6 fields nor the "IPv4ExternalAddrsAndPorts" and "IPv4InternalAddrsAndPorts" fields, if you have information about that, please edit this page.

603 Decline

When you receive an Invitation for a file transfer, you can choose to decline the Invitation. This can be done by sending a "603 Decline" message to the other client. After receiving the Invitation you should send a 603 Decline message instead of a 200 OK message. Also, you should not create a new BranchUID but add the one from the Invitation message to the ";branch=" text. You should also set the value of the "Content-Type" to "application/x-msnmsgr-sessionreqbody". And you also have to put the "SessionID" field into the Message Body with the Identifier of the Session as value.

Many Thanks to ZoRoNaX

Personal tools
Namespaces
Variants
Actions
Windows Live Network Protocol
Windows Live Client Protocol
Reference
Toolbox