MSNProtocol传输文件原理调查报告.doc

MSN Protocol协议发送文件原理调查报告调查人：王丰日期版本描述备注2007-01-17Ver1.00初稿新建2003-01-19Ver2.00增加P2P传输文件名解析原理修改目 录业务需求5版本信息5微软客户端支持种类6MSNFTP官方客户端提供支持的第三方协议6MSNC1X6MSN 3.4.5传输方式6一、MSNFTP协议6使用MSNFTP发送文件过程：6发送邀请6授权登录7发送文件8结束发送8使用MSNFTP发送文件原理：8确认连接9二进制数据9协议-文本段9协议-二进制段10Example sessions11总结11二、MSN 3,4, 5传输方式12概述12发送邀请12协议12命令字段13邀请示例14总结15三、MSNC1.X16P2P消息头：16发送流程16示例和解释171.Invitation Message：SC - RC172.BaseIdentifier message183.200 OK/Error Message: RC - SC184.200 OK acknowledged message195.Directed Connection Invitation Message: SC-RC196.Direct connection invitation acknowledged message197.Direct Connection 200 OK/Error Message: RC-SC208.Direct connection: Handshake209.Direct connection handshake message2110.Direct connection handshake reply message2111.File data message(s)2112.Data acknowledged message2213.Bye message2214.Bye acknowledged message22协商会话头key值变化表23总结24文件内容传输通过客户端协商的端口传输，因此需要对协商消息作实时分析，得到连接IP和端口，得到传输内容。24参考资料25业务需求 实现基于行为的记录，包括用户信息、双方MSN标识、开始时间、结束时间、持续时间、文件标题、文件大小、文件类型、发送站点等信息的记录； 实现文件内容恢复与展现（可选）； 支持允许MSN使用，允许或禁止接受附件，禁止发送附件的方式；（可选）版本信息Microsoft MSN Messenger版本协议版本功能改进Introduced with Windows Live Messenger 8.1MSNP151. Roaming Objects2. LocationIntroduced with Windows Live Messenger 8.0.0792MSNP14Plug-In StateIntroduced with Windows Live Messenger 8.0MSNP13Introduced with Windows Live Messenger 7.5MSNP121. Dynamic Backgrounds2. Voice ClipIntroduced with MSN Messenger7.0MSNP111. Deluxe Display Pictures2. Winks3 3. Map FileIntroduced with MSN Messenger6.1MSNP10Nothing new has been added in this version.Introduced with MSN Messenger6.0MSNP91. Avatar 2. Custom 3. moticons4. User Tile5. Shared File6. Backgrounds7. Most of the changes in MSNP9 exist solely to support MSNC1Msn Messenger version 5.0MSNP8不再支持MSNP7不再支持不再支持MSNP6不再支持不再支持MSNP5不再支持不再支持MSNP4不再支持不再支持MSNP3不再支持不再支持MSNP2不再支持不再支持MSNP1不再支持微软客户端支持种类微软官方MSN Messenger提供3种发送文件机制：MSNFTP官方客户端提供支持的第三方协议尽管并不是一个MSN Messenger协议的技术上的一部分，一个被称为MSNFTP的协议还是被官方的客户端包含了。这个和平常的FTP协议，或者其他的任何文件发送协议都无关。MSNC1XMSN Messenger6最先采用并被目前最新客户端支持的协议。从MSN Messenger 6开始，一种新的给予SIP（Session Initiation Protocol）的协议出现了。MSNSLP跟SIP具有同样的功能，不过只支持更少的请求方法。MSNSLP仅用到了“INVENT”和“BYE”2个方法，“ACK”命令由服务器提供。MSNSLP消息看起来大概是这样：start-Linemessage-headerCRLF message-body MSN 3.4.5传输方式MSN Messenger3,4,5等早期版本所采用的协议。最早的文件发送协商机制出现在官方客户端3.0， 5.0时被改进使之能更好的解决计算机之间TCP的连接问题（比如：隐藏在防火墙后面的NAT）。一、 MSNFTP协议使用MSNFTP发送文件过程：发送邀请发送文件之前，你需要通过总机会话发送邀请。消息体以2个新行结束。请看参见示例:MSG 4 N 277MIME-Version: 1.0Content-Type: text/x-msmsgsinvite; charset=UTF-8Application-Name: File TransferApplication-GUID: 5D3E02AB-6190-11d3-BBBB-00C04F795683Invitation-Command: INVITEInvitation-Cookie: 33267Application-File: readme.txtApplication-FileSize: 60904Invitation-Cookie是随机数，跟transactionID在同一个域中（从0到4294967295 (232 - 1)数字）。该cookie标识每一个随后的邀请都是关联的，所以你需要记住它。以发送的文件名覆盖Application-File，以发送文件的字节数覆盖Application-FileSize。在收到此邀请后，接收者回复另一个邀请以ACCEPT或CANCEL邀请命令。下面就是如果他们接受文件，你可能收到的信息。MSG Tim 179MIME-Version: 1.0Content-Type: text/x-msmsgsinvite; charset=UTF-8Invitation-Command: ACCEPTInvitation-Cookie: 33267Launch-Application: FALSERequest-Data: IP-Address:或者他们拒绝该文件MSG Tim 146MIME-Version: 1.0Content-Type: text/x-msmsgsinvite; charset=UTF-8Invitation-Command: CANCELInvitation-Cookie: 33267Cancel-Code: REJECT如果他们接受你的邀请，你需要发送给他们另一个邀请，再一次，以2个新行作为结束。下面是示例：MSG 4 N 238MIME-Version: 1.0Content-Type: text/x-msmsgsinvite; charset=UTF-8Invitation-Command: ACCEPTInvitation-Cookie: 33267IP-Address: 5Port: 6891AuthCookie: 93301Launch-Application: FALSERequest-Data: IP-Address:IP-Address是你的IP地址，即他们将要去连接的地址。端口是你去侦听的端口号。端口通常是6891，但是假如端口号不存在，你需要发送另一个。Auth-Cookie是另一个同样大小的随即数，它用于验证正确的接收者。授权登录一旦接收者收到你的最后的邀请消息，他们将会连接到你的IP地址在指定的端口。一旦成功的连接，他们将发送VER MSNFTP加一个新行。注意的是在文件发送会话中没有事务ID。再以VER MSNFTP回复他们的消息。他们随后发送USR命令，他们的Passport作为第一个参数，Auth-Cookie作为第二个参数。如果这些是合法的，发送FIL命令，以文件大小作为唯一参数。他们将无参数的TFR命令作为答复。这就是暗示可以发送文件了。下面是整个会话内容的例子： Incoming Connection on Port: 6891 VER MSNFTP FIL 60904 TFR Being Sending File . . .发送文件每个发送包都包含3个字节的头。第1个字节总是ASCII的0。第2，3个字节由被发送的包的尺寸构成。第2个字节整除256的次数，第3个字节是包的尺寸。为了找到这些数，你可以用256去整除和取模包的尺寸。每个包都是2045字节长，除了最后一个，它会包含剩下的字节大小。在发送3个字节头之后，你需要发送一个从文件中恰好能匹配3个字节头的二进制数据。不断地发送文件头和字节包直到文件彻底发送完毕。结束发送当文件已经全部传完，接收者会知道这个文件是多少字节。接收者发送BYE 16777989加新行，作为发送这，希望你来关闭连接。如果接受者没有足够的快地向你发送BYE 命令（官方客户端是1分钟），switchboard session会以“Invitation-Command:CANCEL”和“Cancel-Code:FTTIMEOUT”发送一个邀请命令.如果中途你要取消发送，发送第1个字节等于1，第2，3字节都等于0。假如另一方选择中途取消发送，他们可以发送CCL跟一个空行。使用MSNFTP发送文件原理：这里有几个非常相似的术语用来描述MSNFTP，可能对您阅读本文会造成混淆。发送者(sender)和接收者(receiver)分别表 示发送和接受文件的计算机。服务器(server)和客户端(client) 分别表示发起和接受TCP连接的计算机。A messages is transmitted (so as not to confuse sending a message with sending the file). 在邀请阶段，（聊天的两个用户的）Messenger的客户端将会就谁是服务器，谁是客户端、谁是发送者、谁是接受者、发送的文件叫什么、以及这次Session的认证Cookie达成共识。发送者通常都是服务器，但是可能会要求接受者也充当服务器的角色。一旦客户端已经连接到服务端，MSNFTP协议将会以两台计算机交换若干行文本开始，有点像NS和SN会话。在初始阶段，双方计算机会协商一个协 议，接受者给出它的passport和认证cookie，同时，发送者应答文件的尺寸(size)。然后，发送者以二进制的固定长度块形式发送文件。接收者可以在任何时候取消文件发送。确认连接 在邀请阶段， 两台计算机需要确认一个或者两个IP地址和端口号。如果只有一个IP地址和端口号被给出，那么客户端将连接这个地址和端口，同时服务端在这个段口监听连 接。如果有两个地址和端口被给出，那么服务器需要监听这两个端口，而客户端也要同时尝试连接着两个主从地址和端口。只要连接被建立了，双方计算机需要立即 停止尝试通过另外的端口连接。二进制数据 这部分将探讨二进制数据，以及怎样发送和接受它。如果你已经很熟悉二进制数据，你可以跳过这一段。计算机发送的信息最终都是一系列的1和0组成的。一个字节(byte)包含8个1和0的组合 ，所以一个字节可以是256（2的8次方）种状态中的一种。在一个基于文本协议的通讯软件比如MSN Messenger中，字节根据一些标准被解释为字符信息，这些标准通常有 ASCII 等。在一个二进制协议中，字节被解释为一些介于0和255之间的数字 。 把字节数据解释为数字是非常普遍的，而且通常以16进制的形式。为了使得本页便于阅读，我在这里使用10进制，但是16进制在计算中会经常用到，比如将来的消息颜色代码。许多程序员乐于使用16进制，因为在16进制和2进制之间的转化非常容易。你应该查阅你的语言文档，看一看它到底是怎么处理二进制数据的。一个重要的事情你需要注意的是：许多的程序设计语言（比如C和VB）在表示一个字节 和一个字符时使用相同的数据类型。但是你不要以为字节和字符是一样的，比如，字符0并不是数字0 。在Visual Basic中，你需要通过函数asc(0)来获得一个数字0的ASCII字符，通过val(o)来获得字符0的数字值。协议-文本段 文本段类似于登录一个通知服务器的步骤，不同的是这里没有事务ID。而且如果发送的任何一方发送了一个无效的命令，另外一方会没有发送任何错误消息的情况下关闭连接。首先，接受方发送一个 VER 命令，并把它所支持的 MSNFTP 协议作为参数。官方的客户端只支持 MSNFTP 。发送方回复一个以 VER 协议，并且包含了所选的协议。然后，接受这发送了一个 USR 命令，命令的第一个参数是用户名，第二个参数是认证cookie。发送者回复一个 FIL 命令，它的参数只有一个，那就是文件的大小。官方的客户端使用这个文件大小，而不是 invitation stage 中的文件大小。接收者发送一个 TFR 命令来表明它已经准备好接受了。这时，发送者装到了二进制部分。陆续一些事情之后，接受着必须发送一个 BYE ,它的一个参数（数值）表明文件发送的结果，下面是这些值：2147942405 失败：接受方磁盘空间不足 2164261682 失败：接受方取消了发送 2164261683 失败：发送方取消了发送 2164261694 失败：连接被阻 16777987 成功 16777989 成功作为一个特例，我们一般用没有参数的 CCL 命令来代替 BYE 2164261682。 In practice, only BYE 16777989 and CCL have ever been observed, and the official clients support for other codes is shabby at best. 一旦发送方完成了发送，它将等待接受方发送一个BYE 命令。如果发送方没有尽快的（在官方客户端中大概的时间为小于1分钟）接受到一个BYE ，它将在switchboard session中发送一个邀请命令 Invitation-Command: CANCEL和Cancel-Code: FTTIMEOUT。发送方会在完成发送后随时断开连接。协议-二进制段 一个MSNFTP块包括一个包头和正文。包头用来确定文件是否已经被完全的发送了，如果没有，则包头还会表明块的正文中将要被发送的字节数。包头有3个字节长。如果文件还没有被完全的发送完，包头的第一个字节将会是0，同时，后面的两个字节用于确定正文的长度-这个长度等于第二个字节的值加上第三个字节的值乘以256。举个例子：如果正文的字节数是2045（官方客户端的默认长度），则第二个字节的值为253，第三个字节的值为 7。（253 + 7*256 = 2045）。一旦文件被完全发送完毕。一个最终块将会被发送，这个块的包头的第一个字节的值为1，其他的两个字节的值为0，正文为空。举个例子来说，如果你想发送一个13字节长的文件，文件中包含Hello,world，下面是步骤：生成第一个块 有13个字节将要发送。因此，第一个块的头的第一个字节为0。 文件小于2045字节长，所以只需一个块就可以了。256除13等于0，余13。因此包头的第二个字节为13，第三个字节的值为0。 块的正文中是13个字节的文本。 第一个块是这样的： 0, 13, 0, 72, 101, 108, 108, 111, 44, 32, 119, 111, 114, 108, 100, 33 发送第一个块 检查接受者是否发送了BYE 或者CCL 消息，如果是，则关闭Socket。 生成第二个块 还需要0字节的数据需要发送，所以这是最后一个块。 第二个块是这样的： 1, 0, 0 发送第二个块 文件发送完毕 等待最长一分钟的时间指导接受方发来BYE 或者CCL, 然后关闭Socket. Example sessions 下面是一个成功发送的例子，注意斜体部分代表二进制数据 Incoming Connection on Port: 6891 VER MSNFTP FIL 13 0, 13, 0, 72, 101, 108, 108, 111, 44, 32, 119, 111, 114, 108, 100, 33 1, 0, 0 BYE 16777989 下面是一个失败的协商 Incoming Connection on Port: 6891 VER MYPROTO Disconnect文件传输邀请阶段的消息最初是通过即时消息服务器转发的（端口1863），之后从VER命令开始进行MSNFTP直接连接状态，直到文件传送成功发送BYE消息中断连接位置。从邀请示例可以看出来，发送方在请求一开始就创建Invitation-Cookie: 33267作为会话的唯一标志，在开发过程中可以把检索到该值的数据包都看作这次会话的协商内容。总结综合以上分析结果可以得到如下数据：信息项关键字实现方式用户信息无待定发送端无待定接收端MSG读取接收端包头MSG命令字之后的邮件地址开始时间无待定结束时间无待定持续时间无=结束时间-开始时间文件标题Application-File直接读取。非ASCII名称一般需要做URL Decode解码和UTF-8转换才能得到文件大小Application-FileSize直接读取（单位字节）文件类型Application-File解析文件名的扩展名发送站点无无二、 MSN 3,4, 5传输方式文件传输出现在官方客户端的版本3种，在版本5中已经升级，解决了接收进入TCP连接有困难的问题（不如在NAT防火墙后的那些计算机们）。后续章节中对该协议有详细描述。概述Alice要发送一个文件给Bob，所以她发送一个邀请，这个邀请必须给出文件名及大小。如果Alice不能接收进入连接，邀请中应该提及。Bob或者接收或者取消文件传输，如果拒绝了，必须给出一个原因（如文件拒绝），如果接受了，由于Alice的邀请状态说明她不能接收进入连接，所以他应该在文件传输中作服务器，简单接受就可以了。如果Bob作服务器，商议完毕。否则，Alice必须发送一个应答接受Bob的信息，然后作服务器。商议最后结束，如果文件传输失败，可能提示超时错误。指定作服务器的一端必须给出IP及端口，且给出本地IP及端口。如果Bob作服务器，他必须指出Alice（发送者）将连接到Bob（接收方）。发送邀请邀请信息以MSG命令发送，通过交换板会话，MIME-Version: 1.0，Content-Type: text/x-msmsgsinvite; charset=UTF-8。主体部分为字段集合。通常，字段是任意次序的，不能被识别的字段必须被忽略掉。文件传输中，客户端可能会忽略所有可选字段 5.0以下的官方客户端总是忽略可选字段，5.0及以上版本不会这样。除了一个特殊情况：如果你发送了Connectivity字段，如果Sender-Connect字段存在于应答中的话，就必须进行处理。官方客户端仅在恰好两人的交换板会话中商议，所以如果邀请者与被邀请者没有共享这样一个会话的话，发送邀请的客户端必须首先创建一个。不必在邀请发送的会话中响应。如，如果Alice与Bob在一个交换板中，Alice发送邀请给Bob，接着Carol进入了这个交换板，Bob就必须在不同的交换板会话中发送他的应答。协议每个信息包含一个邀请命令，每个命令的次序必须为：1. 邀请者发送INVITE命令 2. 被邀请者ACCEPT邀请 3. 如果被邀请者不能提供服务，邀请者ACCEPT 4. 任一客户端可能发送CANCEL命令，并携带撤销码FTTIMEOUT，如果传输中出现错误的话。如，官方客户端将在30秒内监听接入连接，然后就取消了服务。头一个信息发送后，任一方都可以在任意时间发送CANCEL。其后不应该发送任何信息。命令字段协商中所有信息包含以下字段：Invitation-Command消息类型Invitation-Cookie1到232-1间的随机整数，唯一标识一个协商（0是不合法的）。该值决定了发送INVITE的发送方，必须在整个协商中保持一致。INVITE字段包含以下字段：Application-Name类的自然语言描述，可以不同，比如，官方客户端用英语称文件传输为File Transfer，Norwegian中为Filoverfring，日语中为送信。这仅应该是为用户描述用 如果说应用程序的GUID的话，谁会识别呢？Application-GUID类的唯一标识。一个类总会有相同的GUID，并且不会有第二个类与之相同。严格的说，应该是CLSID（通常用来标识一个类的GUID）。文件传输的GUID为5D3E02AB-6190-11d3-BBBB-00C04F795683，出于某种原因，官方客户端大小写敏感。Application-File发送的文件名Application-FileSize要发送的文件的字节长。如果发送中这个值与文件传输中指定值不同，将参照那个值。Connectivity（可选）如果客户端知道它不能接收接入连接，它应该发送该字段，并指示值为“N”。官方客户端依照初始profile决定该值，如果你愿意，也可以让用户自己指定。Cancel字段CANCEl命令中只需要一个字段就是Cancel-Code，这是撤消的简要原因。你应该看作是任意形式的字符串，官方客户端所使用的有：FAIL接收客户端不能识别任意指定的会话协议。FTTIMEOUT传输文件时出现错误OUTBANDCANCEL发送邀请的交换板窗口被关闭REJECT邀请被拒绝REJECT_NOT_INSTALLED客户端不支持应用GUIDTIMEOUT等待ACCEPT超时（或者联系人撤销请求）ACCEPT字段下面的字段出现在所有的ACCEPT命令中Launch-Application指示另外的客户端需要（不要）载入一个扩展应用。由于文件传输在官方客户端内部处理，所以这里正常情况下为“FALSE”，我们不知道有什么情况需要设置为“TRUE”。提供服务的ACCEPT命令应该包含如下字段：IP-Address客户端需要连接到的IP地址，官方客户端从初始profile中得到你的Internet网关地址。IP-Address-Internal（可选）如果头一个IP地址连接失败的话，需要尝试的第二个IP地址。最近的版本中官方客户端把你的网卡地址放在此处。Port主要的TCP监听端口。应该为6891。某些版本的官方客户端当你使用了不同地址时行为不一致。与IP-Address对应。PortX（可选）可选的第二个TCP端口。应该为11178。这个与IP-Address-Internal对应，所以如果你包含IP-Address-Internal的话，就需要包含该字段PortX-Internal（可选）如果包含该字段，其值必定与PortX相同，大概是兼容旧版本的官方客户端吧。AuthCookie1至232-1间的随机数，标识文件传输会话中发送的文件（一旦有两个文件同时发送的话）Sender-Connect（可选）通常，接收文件的计算机连接到发送者方，如果发送者需要连接到接收者（如：发送者处在防火墙后）。邀请示例下面是两个客户端间成功文件传输邀请的示例，并支持改良的邀请方法。 MSG 6 N 308rn MIME-Version: 1.0rn Content-Type: text/x-msmsgsinvite; charset=UTF-8rnrnApplication-Name: 346226207344273266344274240350276223rnApplication-GUID: 5D3E02AB-6190-11d3-BBBB-00C04F795683rnInvitation-Command: INVITErnInvitation-Cookie: 4275002rnApplication-File: Picture1.jpgrnApplication-FileSize: 14398rnConnectivity: Nrnrn SC 和 SC - RC3. 200 OK/Error Message: RC - SC4. 200 OK Acknowledged Message: SC - RC5. Directed Connection Invitation Message: SC-RC6. Directed Connection Invitation Acknowledged Message: RC - SC7. Direct Connection 200 OK/Error Message: RC-SC8. Direct Connection Handshake : SC - RC9. Direct Connection Handshake Reply Message : RC - SC10. File Data Message(s) /Data Acknowledged Message: SC - RC/RC - SC11. Bye Message: RC - SC12. Bye Acknowledged Message: SC - RCClient1 send the invitation for file transfer(tmp.txt on desktop)13. File Data Message(s)14. Data Acknowledged message15. Bye Message16. Bye Acknowledged message流程1到流程7通过即时消息服务器端口（1863）进行通信，发送端提出邀请信息，接收端进行确认，并提供待连接的IP、端口或错误信息的过程。流程8开始发送端直接连接到接收端协商好的IP和端口，执行文件传输，结束传输的通信操作。示例和解释1. Invitation Message：SC - RCMSG 3 D 1343rnMIME-Version: 1.0rnContent-Type: application/x-msnmsgrp2prnP2P-Dest: rnrn000000000000Akw000000000000000000000000000267004000000000000000000262004000000000000000000006253327001000000000000000000000000000000000000INVITEMSNMSGR: MSNSLP/1.0rnTo: rnFrom: rnVia: MSNSLP/1.0/TLP ;branch=250EDFDE-03F6-4036-BC77-4BBF86F02C86rnCSeq: 0 rnCall-ID: A2800F01-88C7-4218-A89B-1415B871F1B9rnMax-Forwards: 0rnContent-Type: application/x-msnmsgr-sessionreqbodyrnContent-Length: 863rnrnEUF-GUID: 5D3E02AB-6190-11D3-BBBB-00C04F795683rnSessionID: 30911209rnAppID: 2rnContext:PgIAAAIAAABWBwAAAAAAAAEAAAB0AG0AcAAuAHQAeAB0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAContext是文件被Base64编码后的预览信息。经过Base64解码后得到下图。可以看到文件名。2. BaseIdentifier message Binary header string RC会发送回复一个确认消息以它的字段Identifier作为BaseIdentifier值。 字段Session Identifier设置为0。 Binary footer string Application Identifier 设置为03. 200 OK/Error Message: RC - SCMSG 350203241351207221345215216(350256251346210221344273254350277207345276227350266212346235245350266212345245275) 648rnMIME-Version: 1.0rnContent-Type: application/x-msnmsgrp2prnP2P-Dest: rnrn000000000000210322=b000000000000000000000000P001000000000000000000P0010000000000000000006035241t000000000000000000000000000000000000MSNSLP/1.0 200 OKrnTo: rnFrom: rnVia: MSNSLP/1.0/TLP ;branch=250EDFDE-03F6-4036-BC77-4BBF86F02C86rnCSeq: 1 rnCall-ID: A2800F01-88C7-4218-A89B-1415B871F1B9rnMax-Forwards: 0rnContent-Type: application/x-msnmsgr-sessionreqbodyrnContent-Length: 24rnrnSessionID: 30911209rnrn0000000000000004. 200 OK acknowledged messageIf everything in the 200 OK message is as supposed to be, then the SC should send an Acknowledged Message back. 如果消息完全符合200 OK消息的要求，SC会回复确定消息。 Binary header string 字段“Identifier”保存下一个有效的SC序列“Identifier”，Session Identifier设置为0，其他字段可以根据“Sending Acknowlegements”描述分别设置。 Binary footer string Application Identifier 设置为0。5. Directed Connection Invitation Message: SC-RCMSG 21 D 580rnMIME-Version: 1.0rnContent-Type: application/x-msnmsgrp2prnP2P-Dest: rnrn000000000000Bkw000000000000000000000000000261001000000000000000000261001000000000000000000222022330001000000000000000000000000000000000000INVITE MSNMSGR: MSNSLP/1.0rnTo: rnFrom: rnVia: MSNSLP/1.0/TLP ;branch=54B595BF-3450-4D61-8E63-B4213349EAE7rnCSeq: 0 rnCall-ID: A2800F01-88C7-4218-A89B-1415B871F1B9rnMax-Forwards: 0rnContent-Type: application/x-msnmsgr-transreqbodyrnContent-Length: 92rnrnBridges: TRUDPv1 TCPv1rnNetID: 0rnConn-Type: Direct-ConnectrnUPnPNat: falsernICF: falsernrn0000000000000006. Direct connection invitation acknowledged message Binary header string 如果一切顺利，RC会发送确认消息给SC。除了字段Identifier设置为下个有效的RC序列Identifier之外，消息跟”200 OK Acknowledged Message”的内容没有太多不同。 Binary footer string Application Identifier 设置为0。 7. Direct Connection 200 OK/Error Message: RC-SCMSG 350203241351207221345215216(350256251346210221344273254350277207345276227350266212346235245350266212345245275) 648rnMIME-Version: 1.0rnContent-Type: application/x-msnmsgrp2prnP2P-Dest: rnrn000000000000211322=b000000000000000000000000$002000000000000000000$002000000000000000000371!241t00