IrMC 同步协议调研

文档名称：IrMC 同步协议调研

IrMC 同步协议调研

-------2011.3.21 苏有昕

百度在线网络技术（北京）有限公司（版权所有，翻版必究）

百度在线网络技术（北京）有限公司 - 1 -


1. IrMC 简介

IrMC（Ir Mobile Communications）原本是红外数据协会制定的，基于 OBEX 交互协议的无线设备数据交换同步协议。

蓝牙的 Sync profile 则是直接继承 IrMC 协议，是 IrMC 的子集，除去了 Call Control和 Audio 部分，并定义了蓝牙实现中相应的必选和可选功能。

IrMC 采用 C/S 结构，通讯端一方为 Client 一方为 Server。

Server 负责对 Client 的命令做出响应，被动的执行 Client 指令访问本端的 PIM 数据，本身不含有同步逻辑，通常 Server 由设备能力较弱的一方实现，比如手机。在蓝牙中 IrMC Server一般作为一个蓝牙服务随蓝牙开启而启动，监听来自其它蓝牙设备的访问，同步请求。

Client 端则包含同步引擎和从 Server 端读写 PIM 数据的能力，也就是说不仅可以同步 IrMC同步还可以通过 IrMC 对 PIM 数据进行管理，通常 Client 端由 PC 实现。在协议中 Client 端也被要求能接受来自 Server 端的同步开始请求，以便确保两端都可以发起同步。

能解决用户的需求：1. IrMC Client 管理 IrMC Server 端的 PIM 数据。2. IrMC Server 通知 IrMC Client 发起自动同步，也就是不管 Server 还是 Client 都可以发起同

步。3. IrMC Client 发起自动同步。



IrMC 在蓝牙协议栈中的结构：

IrMC 依赖于 OBEX 协议，IrMC 是通过 OBEX 协议封装的一种数据业务。而对于 OBEX 运行于什么协议之上并没有明确的规定，只要是可靠的支持数据流传输的通道都可以，在红外是 IrCOMM，而在蓝牙上是 RFCOMM。

2. IrMC 框架

IrMC 访问同步的对象是 PIM 数据，协议中定义的 PIM 数据为 4 种，联系人（vCard），日程（vCalendar），短消息（vMsg），记事本（vNote），前两种是被 imc（Internet Mail Consortium）所定义的，应用相当广泛，而后面两种则是由 IrMC 协议自定义的。后面章节详细介绍。

同步最终目地是为了让两方（C/S）不管哪一方的 PIM 数据有更改，在同步前不一致，而在同步后都保持一致，这有很多种方式可以实现，为了支持不同方式的访问和同步，IrMC 协议定义了访问 PIM 数据的 4 个级别，通过这四种访问级别可以实现不同的访问和同步逻辑，一个具体的 Server 实例可以选择实现哪些级别的访问。

执行不同等级的访问，在 IrMC 中是通过 OBEX 中 NAME 头的内容来加以区分的。而其中的内容是以虚拟文件系统的路径来作为操作命令的主体。



2.1 Level 1 访问级别

Level 1 的访问级别定义，Server 能够接收 Client 端发送来的 PIM 对象，并能够把对象储存于 Inbox 中以便用户决定对这个对象如何操作。

实例：OBEX Put 请求 NAME 头中可能包含一个字符串：Yoshiko.vcf

由此 Server 收到这个 Put 请求时，解析出这是一个单独的文件名，是 level1 的访问操作，则执行相应的操作把这个 Yoshiko.vcf放入 Inbox 中，这里放入 Inbox 以后不对这个对象做任何处理，等待用户选择如何处理这个对象。而这个 Yoshiko.vcf 对象可能不只包含一个 vCard对象。


Level 2 的访问级别定义，Client 可以发送和取得整个一类 PIM 数据，比如所有的联系人，所有的发送短消息。

实例：OBEX Get 请求的 NAME 头中可能包含一个字符串：telecom/pb.vcf

telecom关键字，与 level1 区分，这里是大于 level1 的同步请求pb.vcf关键字，表明所有的联系人

由此如果 Server 收到这个数据包，就可以得知 Client 发起一个 Get 请求来取得 Server 端所有的联系人数据。而收到 Server 的回复数据可能的格式如下图：



整个回复数据包中包含所有的格式化联系人数据。同样如果收到一个 Level2 的 Put 请求，则表明 Client 把本端所有的联系人推送到 Server 端。利用 Level2 可以实现最基本的同步：把 Server 的所有数据先读过来，然后同步引擎进行对比后把同步以后的数据再发送给 Server，这样最基本的同步过程就完成了。


Level 3 访问级别的定义，Client 可以发送和接收单个的以静态索引标识的数据对象。支持Level3 同步需要同时支持 Level2 和 Level1 的操作。

实例：OBEX Get 请求的 NAME 头中可能包含一个字符串：telecom/pb/1.vcf

telecom关键字，与 level1 区分，这里是大于 level1 的同步请求pb.关键字，这是一个大于 level2 的同步，而且 PIM 对象是联系人1.vcf关键字，表明是 level3 的同步，读取 index=1 的联系人，index 被定义为从 0 开始到65535 的整数



也就是说 level3 在 level2 的基础上加入了对某一个单独的使用静态索引的 PIM 数据进行添加、删除、修改的操作。

如果一个服务器实现为支持 level3 的访问，那么在执行 level2 读取所有联系人的时候与仅仅支持 level2 级别的服务器有所不同，如下图，这里可以看出 static index 的意义：

假设在 SIM卡中联系人储存在卡中的位置是固定的，在同步开始每一个独立的联系人就被分配了一个静态的索引，这个索引是从 0 开始递增的，通过 level2 的 Get 操作得到的数据如上图所示，是一个有序的联系人数据流，可能某个索引位置没有联系人信息，这时同样需要编码成一个空的 vCard 来占位。这些 index 在一次同步过程中是保持不变的。

如果 Client 要对 Server 进行 Level3 的 Put 操作，也就是增加，删除或者修改单个的 PIM 数据，index 必须由 Client 指定，Server 端必须接受并对这个 index 的数据进行修改。



支持 Level3 级别访问的同步逻辑可以实现在一次同步过程中，对 PIM 数据的管理，比如在从 Server 一次性读取了所有数据以后，再对某一个单独的 PIM 数据进行添加、删除、修改。


Level 4 访问级别也称做同步访问级别，定义是 Client 可以发送和接收单个的以唯一标识符（LUID）标识的数据对象。支持 Level4 同步需要同时支持 Level2 和 Level1 的操作，不依赖于 Level3。

实例： OBEX Get 请求的 NAME 头中可能包含一个字符串：telecom/pb/luid/813cd.vcf

telecom关键字，与 level1 区分，这里是大于 level1 的同步请求pb.关键字，这是一个大于 level2 的同步，而且 PIM 对象是联系人luid表明是使用 LUID 作为联系人表示，即 Level4 访问813cd.vcf表明需要访问的 PIM 对象是 LUID 为 813cd 的联系人。

如果一个服务器实现为支持 level4 的访问，那么在执行 level2 读取所有联系人的时候与仅仅支持 level2 级别的服务器有所不同，需要在每一个 PIM 数据中加入 X-IRMC-LUID字段来标识数据的 LUID。在 Put 操作时，如果是添加操作还需要通过 OBEX 的 APP Rsp返回 LUID 以及Change Counter.而修改和删除操作也需要通过 OBEX 的 APP Rsp返回 Change Counter。

Level4 访问还需要实现额外的两个操作：获取 sync anchor 同步锚点，用来记录当前设备的最新同步的位置，例如

telecom/pb/luid/cc.log

获取 change log，里面有记录 PIM 数据变更的相关信息。例如，取 101锚点以后的 logtelecom/pb/luid/101.log

2.5 Device Information

IrMC 协议中设备厂商的相关信息，Client 可以通过发送 Get 请求从服务器得到，比如在OBEX 的 Get 请求包中包含 NAME“telecom/devinfo.txt”

devinfo.txt 采用文本文件的形式描述，格式定义如下：Manufacturer

MANU:Big Factory, Ltd. Model

MOD:4119 OEM

OEM:Jane’s phones Firmware-Version



FW-VERSION:2.0e Firmware-Date

FW-DATE:19971031T231210 Software-Version

SW-VERSION:2.0 Software-Date Software-Date

SW-DATE:19971031T231210 IrMC-Version

IRMC-VERSION:1.1 Hardware-Version

HW-VERSION:1.22i Hardware-Date

HW-DATE:19971031T231210 Serial Number

SN:1218182THD000001-2 Phone Book Type

PB-TYPE-TX:VCARD2.1 PB-TYPE-RX:VCARD2.1

Calendar Type CAL-TYPE-TX:VCAL1.0 CAL-TYPE-RX:VCAL1.0

Message Type MSG-TYPE-TX:VMSG1.1 MSG-TYPE-RX:VMSG1.1

Note Type NOTE-TYPE-TX:VNOTE1.1 NOTE-TYPE-RX:VNOTE1.1

Inbox Capability INBOX:MULTIPLE

Sent Box Capability MSG-SENT-BOX:YES

2.6 Information Logs

IrMC 定义了 Info.log 用来记录某一个 PIM 数据的常用信息，Client 可以通过 OBEX Get 命令取得，NAME 头里面包含 telecom/pb/info.log

Server 如果实现了 Level2 以上的访问支持，支持 info.log 的读取是必须的。具体定义如下：Total-Records:

Lev3 和 lev4 都需要支持，当前种类的 PIM 数据的总数



Last-Used-Index :

Lev3 定义，最后一次使用的 index，以避免 Client 端在 ADD 操作的时候覆盖已有的数据Maximum-Records:

Lev2.3.4 定义，(*或者数字)可以支持的最大存储量IEL：访问等级支持

0x01 Level 1 (Minimum Level) Only 0x02 Level 1 and 2 (Minimum and Access Levels) Only 0x04 Level 1, 2 and 3 (Minimum, Access, Index) Only –0x08 Level 1, 2, and 4 (Minimum, Access, Sync) Only –0x10 Level 1, 2, 3 and 4 (Minimum, Access, Index, Sync)

HD：硬删除，是否支持用户可能确实删除，也可能是为了节约空间删除，client 可以选择在本端是否真的删除。

SAT：同步锚点类型CC(CHANGE COUNTER)或者 TS(TIMESTAMP)或者 CT(BOTH)

DID: 数据库 ID，CLT 会基于这个来判别同步源是否一样

X-IRMC-Fields：具体 PIM 数据所支持的格式定义X-IRMC-FIELDS: <Begin> Version: N:=20 UID:=4 ADR[1=20;2;6;7]: TEL;TYPE=HOME;WORK:

ICL (Incoming-Call-Log)

是否支持读取来电列表OCL (Outgoing-Call-Log)

是否支持读取呼叫列表MCL (Missed-Call-Log)

是否支持读取未接来电列表

实例Total-Records:4 Last-Used-Index:5 Maximum-Records:* IEL:4 HD:NO SAT:CC DID:* X-IRMC-FIELDS:



<Begin> Version: N:=20 UID:=4 ADR[1=20;2;6;7]: TEL;TYPE=HOME;WORK: <End> ICL:YES OCL:YES MCL:YES

2.7 Change Counters

Change Counters 是一个计数器，从 0 开始，用来对某一类 PIM 数据的修改操作计数。比如一开始添加了一个联系人，那么联系人的虚拟数据库中将增加一条记录，它的 Change Counter 为 0，之后用户又添加了另一条记录，那么联系人的虚拟数据库中将增加另一条记录，它的 Change Counter 为 1，以此类推。

它依赖于对 PIM 管理的虚拟数据库，如果数据库被重置则 Change Counter 也被清零。

Level4 级别的同步允许 Client 通过命令取得当前 Server 端 PIM 的最新 Change Counter例如在 OBEX 的 NAME 头中包含如下信息：

telecom/pb/luid/cc.log

2.8 Change log

Change log 是 level4 级同步必须支持的记录某一类 PIM 数据信息的文件。它提供设备号，数据库 ID，最大记录数，当前已用总数等虚拟数据库的信息，它还提供一份最新更改的记录列表，Client 可以通过修改列表获知对端数据的更改以便进行增量的同步操作。典型的 changelog修改列表格式包含 3 个信息：

Action: M=Modified, D= Deleted or H=Hard Deleted. Change Counter/ Timestamp: The Change Counter for the change LUID: The LUID form of the name of the modified Object, e.g., “13a4b.vcf”

也就是说在本端上的任何 PIM修改操作都被记录在这个表里，比如说M:201:: 19970401-080045

M表示有记录被修改或添加，201 是这个操作的 Change Counter，而 19970401-080045 则是此数据的 LUID

Change log 通常被实现为一个先进先出的队列，容量有限，需要以文件的形式存在，每一



种需要同步的 PIM 数据都需要写 change log 来记录其发生的改变。

Client 被允许可以发送命令取得任意 Change Counter 之后的 change log例如在 OBEX 的 NAME 头中包含如下信息：

telecom/pb/luid/45.log

表示取 45 change counter 之后的 change log

下面举例说明 server 改如何回复

假设 Server 端的联系人 change log 容量 10，其中以先进先出的方式记录了 change counter 为 25-34 的 10条记录如下：M:25::19970401-080045-40000F192713-0052 D:26::19790327-080045-40000F192713-0053 M:27::19740715-080045-40000F192713-0123 M:28::19981207-080045-40000F192713-2252M:29::19970401-080045-40000F192713-0052 D:30::19790327-080045-40000F192713-0054 M:31::19740715-080045-40000F192713-0129 M:32::19981207-080045-40000F192713-2352M:33::19970401-080045-40000F192713-0152 M:34::19970401-080045-40000F192713-0152

如果收到 Client 发送来的请求是telecom/pb/luid/32.log

则可能的回复是：SN:1218182THD000001-2 DID: 03df30423 Total-Records:7 Maximum-Records:50 M:33::19970401-080045-40000F192713-0152 M:34::19970401-080045-40000F192713-0152


要求的 change counter太老，记录里没有，已经删除了，返回“*”SN:1218182THD000001-2 DID: 03df30423 Total-Records:7 Maximum-Records:50

*


要求的 change counter太新，记录里没有，还没有发生，返回“*”



SN:1218182THD000001-2 DID: 03df30423 Total-Records:7 Maximum-Records:50

*


要求的 change counter 为当前最新的则返回空的 change logSN:1218182THD000001-2 DID: 03df30423 Total-Records:7 Maximum-Records:50

2.9 虚拟路径

IrMC Server 执行命令依赖于其选择的虚拟路径，通过不同的路径选择不同的访问级别以及不同的 PIM 数据

Yoshiko.vcftelecom/pb.vcftelecom/cal.vcstelecom/pb/1.vcftelecom/msg/in/1.vmgtelecom/nt/5.vnttelecom/pb/luid/127318df.vcf

如果有新的 PIM 需要实现同步，只要实现符合同步引擎需要的访问级别的接口是可以做扩展的。

3 IrMC 同步逻辑

基于 IrMC框架，如果 Server 实现了 Level4 级别的访问，可以实现增量的自动同步。流程如下图所示，这是 Client 发起的对一个支持 Level4 级别访问的设备的自动同步逻辑：



3.1 第一次同步(Slow Sync)



3.2 快同步(Fast Sync)



3.3 半慢同步(Semi Slow Sync)



3.4 复位（Reset）



3.5 恢复（Restore）

4 IrMC 与 OBEX

IrMC 作为 OBEX 协议承载的服务，需要使用 OBEX 中的操作如下图所示

作为一个完整的 Server 端需要实现 OBEX 支持出 SetPath 以外的所有操作。下面列出了所有 IrMC 需要用到的 OBEX 头



下面举例说明一个简单的 IrMC 的 OBEX 包结构Connect 请求：

80 00 13 10 00 40 06 46 00 09 49 52 4d 43 2d 53 59 4e 43

80：connect

00 13：包长度 19 字节

10：obex 版本 1.0

00：总是 0

40 06：最大包长度 16390 字节。

46：hi，target（目标）。0x40 开头，表示后面跟 2 个字节的长度描述。



00 09：header 长度 09

49 52 4d 43 2d 53 59 4e 43：IRMC-SYNC

Connect回复：a0 00 18 10 00 01 da cb 00 00 01 00 4a 00 09 49 52 4d 43 2d 53 59 4e 43

a0：ok，success

00 18：包长度 34 字节

10：obex 版本 1.0

00：总是 0

01 da：最大包长度 474 字节

cb：connection id=0x100。0xc0 开头，表示后面跟 4 个字节的值。

4a 00 09：who header。长度 0x09。

49 52 4d 43 2d 53 59 4e 43：IRMC-SYNC

Get 请求，内容是 telecom/pb/luid/111.vcf83 00 3b cb 00 00 01 00 01 00 30 00 74 00 65 00 6c 00 65 00 63 00 6f 00 6d 00 2f 00 70 00 62 00 2f 00 6c 00 75 00 69 00 64 00 2f 00 31 00 31 00 31 00 2e 00 76 00 63 00 66 00 00

83：GET

00 3b：包长度长度 54


01： NAME Header

00 30： NAME Header Len 48

00 74 00 65 00 6c 00 65 00 63 00 6f 00 6d 00 2f 00 70 00 62 00 2f 00 6c 00 75 00 69 00 64 00

2f 00 31 00 31 00 31 00 2e 00 76 00 63 00 66 00 00：telecom/pb/luid/111.vcf 的 unicode 以两个 0 结尾。



Get 回复：内容是一个 vcardBEGIN:VCARDVERSION:2.1N:JIMFN:JIMTEL;WORK;VOICE:13300988988REV:20110324T115405ZEND:VCARD

a0 00 70 cb 00 00 01 00 49 00 65 42 45 47 49 4E 3A 56 43 41 52 44 0D 0A 56 45 52 53 49 4F 4E 3A 32 2E 31 0D 0A 4E 3A 4A 49 4D 0D 0A 46 4E 3A 4A 49 4D 0D 0A 54 45 4C 3B 57 4F 52 4B 3B 56 4F 49 43 45 3A 31 33 33 30 30 39 38 38 39 38 38 0D 0A 52 45 56 3A 32 30 31 31 30 33 32 34 54 31 31 35 34 30 35 5A 0D 0A 45 4E 44 3A 56 43 41 52 44 0D 0A

a0：ok，success

00 70：包长度 112 字节


49: end of body

00 65: body 包的长度 101

42 开始就是具体的 vCard 数据

Disconnet 请求：81 00 08 cb 00 00 01 00

81：disconnect

00 08: 长度 08 字节


Disconnet 回复： a0 00 08 cb 00 00 01 00..

a0：ok，success



00 08: 长度 08 字节


5 PIM 对象

5.1 vCard

vCard 是由因特网国际标准化组织 IMC 所制定的，用来解决名片互通问题的标准。vCard2.1已经得到国际上绝大多数厂商的支持，现已成为事实上标准 .今年来随着人们需求的变化，已经发展为 vCard3.0 ， vCard4.0 ， 3.0 的规范已经被加入 RFC 规范中（RFC2425，RFC2426）。

vCard标准定义了名片的在传递时通信的双方都必须遵循的格式标准。名片交换时，发送方需要将本机名片转化为 vCard格式，接收方需要解析 vCard格式名片，并将其转为为本机名片格式保存到本机名片库。一台设备既可作为名片的发送方，也可作为接收方。

vCard标准还就名片本身做了定义，即定义了能够通过 vCard 传递的名片字段。例如，它定义了姓名、电话、EMAIL 等名片字段。

vCard 对象由多个字段组成，每一个字段用一行来表示。每个字段由字段名（ Property Name）、字段参数（Property Param）、字段值（Property Value）三部分组成。其中字段名和字段参数之间用分号（;）分隔，字段参数和字段值之间用冒号（:）分割。如下：

PropertyName [‘;’PropertyParam] ‘:’ PropertyValue

PropertyParam 以及它前面的分隔符（;）是可选的，而且 PropertyParam 可以由多个子参数组成，之间用分号（;）分割。PropertyValue 是必选的，不过也可以置空，但是它前面的分隔符（:）是必须的，即使 PropertyValue置空。有的时候，字段值也可以由很多子字段组成，子字段之间通过分号（;）来分割，例如姓名和地址，这样的字段称为复合字段。复合字段的具体的组织格式取决于字段的类型。

字段示例：

ADR;CHARSET=UTF-8;WORK:<北京海淀区>;;;;;100001

该字段为复合字段，有 2 个字段子参数，CHARSTE=UCS2、WORK。字段值为<北京海淀区>;;;;;100001，由 6 个子字段值组成，其中 4 个子字段值为空。



每个 vCard 对象由行 BEGIN:VCARD（vCard 开始分隔符）开始，中间可跟任意多个 vCard字段行，最后以行 END:VCARD（vCard 结束分隔符）结束。

BEGIN:VCARDVERSION:2.1N:JIMFN:JIMTEL;WORK;VOICE:13300988988REV:20110324T115405ZEND:VCARD

参见 http://www.imc.org/pdi/pdiproddev.html

5.2 vCalendar

vCalendar 也是由因特网国际标准化组织 IMC 所制定的，用来解决日程互通问题的标准。vCalendar1.0已经得到国际上绝大多数厂商的支持，也已成为事实上标准。

与 vCard类似的表达形式，这里不再详细阐述，具体信息请查询Specification

参见 http://www.imc.org/pdi/pdiproddev.html

BEGIN:VCALENDARVERSION:1.0BEGIN:VEVENTCLASS:PUBLICDESCRIPTION:content\nDTEND:20110325T023000ZDTSTART:20110325T020000ZAALARM:20110325T020000ZLOCATION:locationPRIORITY:5SUMMARY;LANGUAGE=zh-cn:titleEND:VEVENTEND:VCALENDAR

5.3 vMsg

vMsg格式如下图所示：包含发件人的 vCard信息，收件人的 vCard信息，和具体的消息体


http://www.imc.org/pdi/pdiproddev.html

http://www.imc.org/pdi/pdiproddev.html


5.4 vNote

IrMC 自定义的 vNote格式，相对很简单只有 BODY字段需要填入相应内容BEGIN:VNOTEVERSION:1.1BODY: Top 10 Reasonsto Love IrMCEND:VNOTE



6 IrMC 与 PC 套件

从现在国内市面上的手机支持情况来说，蓝牙的 sync profile 应用并不广泛，可能由于 PC 上只能同步 OutLook 联系人和日程，对国人来说不常用。

然而如果选用 IrMC 作为 PC 同步协议的一部分可能更为有用，它可以完成如下功能联系人管理和同步日程的管理和同步备忘录的管理和同步

短消息的管理和同步彩信的管理和同步邮件的管理和同步

对于短消息，虽然 IrMC 定义 vMsg格式来表示短消息，但由于一般 PC工具还需要发送和接收短消息的功能，IrMC 没有定义相应的功能，现行的厂商大多数还是采用 GSM07.05 中定义的相关 AT 命令来管理短消息。

7 IrMC 与 Syncml

Syncml 是近些年新定义的同步协议，旨在统一现有的数据同步协议和信息交换标准，兼顾各种网络、操作平台和电脑设备，它实现的功能和 IrMC 相似，它解决了 IrMC 在扩展性和可移植性上的一些弊端。下面简单分析下各自的优劣势：

1. IrMC 依赖于 OBEX 协议，所有的 IrMC 定义的操作都被封装为 OBEX 数据包，依赖于OBEX 的命令，以及协议头等，可以认为 IrMC 是使用 OBEX 协议的一种应用。

而 Syncml 协议本身被封装在 XML 数据流中，对于承载层协议来说，不需要提供额外的协议头命令等，只需要支持基于会话的通明传输即可。这对同步协议来说其跨平台性和可移植性都大大加强了，Syncml 可以直接运行于 Http，Wsp 等其它协议之上。

2. 另外一个比较重要的区别在于 OBEX 协议不太适合复杂网络环境下的数据交换，OBEX协议要求一个面向流的可靠的长连接型数据通道，属于简单的停等协议，如果在复杂远距离传输过程中，传输时间耗费过长、可靠性不高的情况下，会大大降低其效率和鲁棒性。它更适合于红外蓝牙串口等短距离数据传输。

而 Syncml 协议由于本身的封包比较大而且一个交互流程可以提交多个操作，在长距离网络传输的时候可以基于 Http 协议，而在短距离传输时可以基于 OBEX 协议，这样既兼



顾了长距离的传输，也兼顾了短距离传输，使得其兼容性更强。

3. 但 Syncml 也有劣势，因为其是基于 XML 的可见数据流，相对 OBEX 来说数据量大得多，虽然有 WBXML 的实现方式，但比起 IrMC 来说数据流量上还是不占优势。

4. 开发量上来说，Syncml 比 IrMC 来说更复杂，需要的工作量更多。

8 Android 蓝牙 sync 开发工作量

Sync Profile 是基于蓝牙 RFCOMM 之上，在 Android 中 framework 已经包含这部分功能，OBEX 协议也已经有实现，所以对于开发一个 IrMC server 来说工作量在于：

1. IrMC 协议本身，可只实现 1，2，4 级别的访问协议。2. PIM 相关接口的定义集成，Change log 相关模块的开发。

3. PIM 编码的实现，android已经有 vCard，vCalendar 的实现。

4. 蓝牙服务注册接口的添加。

5，是否提供界面显示。


IrMC 同步协议调研

Documents

Transcript of IrMC 同步协议调研

IrMC 同步协议 调研

Documents

Transcript of IrMC 同步协议 调研

IrMC 同步协议调研

Transcript of IrMC 同步协议调研