PBAP 1.0协议翻译(Part1)

添加vCard3.0 Spec的链接
http://tools.ietf.org/html/rfc2425
http://tools.ietf.org/html/rfc2426

寻找最新的Spec版本可以到:
https://www.bluetooth.org/Technical/Specifications/adopted.htm

本文的翻译内容是基于PBAP1.0,很多都是个人的理解,难免有疏漏,有争议或者疑问的地方,欢迎在此留言进行探讨。

5.3 Application Layer

5.3.1 Phone Book Access Profile Objects and Formats

5.3.1.1 Phone Book Repositories [ri'pɔziˌtəri]

电话薄对象的repositories包括SIM卡和Phone两种。

5.3.1.2 Phone Book Objects

包括PB,ich,och,mch,cch,其中cch是ich/och/mch的集合。

5.3.1.3 Phone Book object representations

每一个Phonebook object都有两种表现形式,分别为文件和虚拟文件夹:

Ø 文件

表现为一个单独的文件,包含了所有与之对应的电话薄实体

Ø 文件夹

表现为一个单独的虚拟文件夹包含与之对应的电话薄实体,每一条记录或者每一个实体都是虚拟文件夹中的一个独立的文件

5.3.1.4 Phone Book Entries format

电话薄中每一个独立的实体都是以vCard格式存在。PSE应当支持vCard2.1和vCard3.0版本,并可以按照PCE指定的格式将实体传送到PCE。无论是哪种格式,都采用UTF-8[p1] 进行编码。

5.3.1.4.1 Call History extension

ich/och/mch/cch的时间信息采用IrMC [13] defined X-IRMC-CALL-DATETIME属性来进行描述,该属性有如下的三个参数:

Ø MISSED

Ø RECEIVED

Ø DIALED

For instance, a call that was missed on March 20th

, 2005 at 10 am would be stamped:

X-IRMC-CALL-DATETIME;MISSED:20050320T100000

用该属性表示的时候,也可以不加入时间信息。

5.3.1.5 PBAP virtual folders structure

PBAP的Phonebook信息通过虚拟文件夹结构表示,如下图:

PBAP 1.0协议翻译(Part1)

5.3.1.5.1 Handles

vCards通过一个句柄(<handle.vcf>)来进行区分。

句柄为一个32位,通过8进制表示的数字。

5.3.1.5.2 Local Phone Books: PB and SIM1

当存在SIM卡的时候,Phonebooks有两份,一份为Phone,一份为SIM卡上,详细参照前面的图形描述。

5.3.1.5.3 Call Histories

同一个号码可能存在于多个虚拟文件夹下,如och和ich,而且对应的句柄未必一样。

5.3.1.6 vCard-Listing Object (x-bt/vcard-listing)

vCard-listing object使用xml格式进行描述,定义如下图所示:

PBAP 1.0协议翻译(Part1)

一个具体的例子如下图所示:

PBAP 1.0协议翻译(Part1)

5.3.1.6.1 Name attribute format

Name属性的命名格式如下:

“LastName;FirstName;MiddleName;Prefix;Suffix”

5.4 Phone Book Access Features

5.4.1 Phone Book Access Profile Features

共有浏览和下载两种特性,如下图所示:

PBAP 1.0协议翻译(Part1)

需要特别指出的,对于PCE来说,浏览和下载两者至少支持一个,而PSE两者必须全部支持。

5.4.2 Phone Book Download Feature

PBAP 1.0协议翻译(Part1)

5.4.3 Phone Book Browsing Feature

PBAP 1.0协议翻译(Part1)

简单说明一下,SetPhonebook可以去配置当前选择的虚拟文件夹,PullvCardListing用来获取一个特定phonebook对象的vCard listing,而PullvCardEntry用来获取一个独立的phonebook object实体(entry)。

5.5 Phone Book Access Profile Functions

5.5.1 PullPhoneBook Function

用来从OBEX Server上获取整个phonebook object,典型的如获取根目录下所有的phonebook object。

需要特别说明的是,由于PullPhoneBook和PullvCardListing的Opcode都是Get,如何来区分两者呢?

两者的Type并不一致,PullPhoneBook的Type为x-bt/phonebook,而PullvCardListing的Type为x-bt/vcard-listing,另外,两者的其他一些参数也不一样,如前者的name为具体的文件*.vcf,而后者的name为虚拟的folder

一个典型的该命令如下:

PBAP 1.0协议翻译(Part1)

Response如下:

PBAP 1.0协议翻译(Part1)

5.5.1.1 Connection ID

在OBEX建立连接的过程中获取到的,具体的例子如下:

PBAP 1.0协议翻译(Part1)

5.5.1.2 Name

为包含虚拟文件夹的绝对路径,后面将会看到,PullvCardListing函数使用的是相对路径。这也造成了PullvCardListing操作过程中需要SetPath,而PullPhoneBook则不需要。

如果为空的话,则表示存取当前的目录。

5.5.1.3 Type

固定为<x-bt/phonebook>。

5.5.1.4 Application Parameters

5.5.1.4.1 Filter {AttributeMask 64-bit value)}

用来请求vCard中需要包含的信息,用64bit来表示,如果为0则表示获取所有的信息,详细参照下图:

PBAP 1.0协议翻译(Part1)

PBAP 1.0协议翻译(Part1)

需要特别指出的是,vCard格式有不同的版本,对于PBAP来说,只涉及到2.1和3.0版本,有关vCard的详细描述,参照:

Ø http://en.wikipedia.org/wiki/VCard

Ø vCard2.1 Spec

5.5.1.4.2 Format { vCard2.1 | vCard3.0 }

按照协议中的描述,PSE应该 同时支持这两种格式。

5.5.1.4.3 MaxListCount

用来表示PCE处理x-bt/phonebook Entry的最大条目数,有效值范围为0~65536。

如果为0,则PSE应当忽略所有其他的Application Parameters,且主要用来获取感兴趣的号码信息。

如果为65536,则表示不限制最大条目数。

详细参照后续描述。

5.5.1.4.4 ListStartOffset

表示x-bt/phonebook Entry中的偏移。

5.5.1.4.5 PhonebookSize

当MaxListCount为零,该参数在Response中用到,表示实际应有的x-bt/phonebook Entry条目数。

如果MaxListCount为不为零,则忽略该参数。

[p2]

5.5.1.4.6 NewMissedCalls

只有在请求为MCH(missed incoming call)的时候才会用的到,用来表示未处理的missed calls个数。

5.5.2 SetPhoneBook

该函数用来设置虚拟目录的当前目录。

需要特别指出的是,该函数能够配置的当前路径仅限于root,parent以及child目录。所以,如果要把当前的目录配置为pb,则需要先配置为telecom,然后再配置为pb。

函数格式定义如下:

PBAP 1.0协议翻译(Part1)

5.5.3 PullvCardListing Function

该函数用来获取phonebook-listing对象,按照前面文档中对vCard-listing描述以及实际sniff log中所体现的内容,该函数只能够获取到fn(根据参数search attribute值来决定获取的结果,可供选择的值有Name,Number和Sound)以及 vCard handle信息,而PullPhoneBook则可以获取到按照标准的vCard2.1或者3.0格式表示的完整的电话薄信息。

一个具体的例子如下:

PBAP 1.0协议翻译(Part1)

Response如下:

PBAP 1.0协议翻译(Part1)

5.5.3.1 Connection ID

在OBEX建立连接的过程中获取到的Connection Handle。

5.5.3.2 Type

固定为x-bt/vcard-listing。

5.5.3.3 Name

指定待访问的虚拟文件夹相对路径,如果为空,则表示访问当前虚拟文件夹。

5.5.3.4 Application Parameters

5.5.3.4.1 Order { Alphabetical | Indexed | Phonetical }

表示x-bt/vcard-listing objects的排序方式。

Ø Alphabetical

按照N属性的字母顺序进行排序。

根据vCard2.1中对N属性的解释,N属性包含了以下的内容[p3] “The property value is a concatenation of the Family Name (first field), Given Name (second field), Additional Names (third field), Name Prefix (fourth field), and Name Suffix (fifth field) strings.”

Ø Indexed

根据Handle order排序。

Ø Phonetical

根据Sound属性进行排序,只有在PSE上的Sound为纯文本的时候才有意义。

如果没有指定的话,则默认按照indexed进行排序。

5.5.3.4.2 SearchAttribute {Name | Number | Sound }

表示以哪种属性进行查找,如果没有指定,默认按照Name属性进行查找。[p4]

5.5.3.4.3 SearchValue {<text string>}

来告知PSE哪些SearchAttribute为SearchValue的vCards将会被包含在<x-bt/vcard-listing> listing object中返回。

按照协议的规定,如果没有指定该值的话,则返回所有的vCards。

5.5.3.4.4 MaxListCount

指定<x-bt/vcard-listing> 中最大的entries,如果没有指定,则为最大值65536。

5.5.3.4.5 ListStartOffset

<x-bt/vcard-listing> Object中的Entry偏移。

5.5.3.4.6 PhonebookSize

同上。

5.5.3.4.7 NewMissedCalls

同上。

5.5.4 PullvCardEntry Function

用来获取指定的vCard的信息。

一个具体例子如下:

PBAP 1.0协议翻译(Part1)

对应的Response如下:

PBAP 1.0协议翻译(Part1)

5.5.4.1 Connection ID

在OBEX建立连接的过程中获取到的Connection Handle。

5.5.4.2 Type

固定为<x-bt/vcard>。

5.5.4.3 Name

指定待浏览的Object名字,由于使用相对路径,形如上图中的8.vcf。

5.5.3.4 Application Parameters

5.5.4.4.1 Filter {AttributeMask (64-bit value)}

同上。

5.5.4.4.2 Format { vCard2.1 | vCard3.0 }

同上。


[p1]

UTF-8(8-bit Unicode Transformation Format)是一种针对Unicode的可变长度字符编码(定长码),也是一种前缀码。它可以用来表示Unicode标准中的任何字符,且其编码中的第一个字节仍与ASCII兼容,这使得原来处理ASCII字符的软件无须或只须做少部份修改,即可继续使用。因此,它逐渐成为电子邮件、网页及其他存储或传送文字的应用中,优先采用的编码。

详细参照:http://zh.wikipedia.org/zh-cn/UTF-8

[p2]不明白啥意思?????

[p3]FN属性则包含了另外的一套内容,根据协议的定义,包括如下的内容“It can contain desired honorific prefixes, suffixes, titles, etc. For example, “Mr. John Q. Public, Jr.”, Dr. Ann Tyler, or Hon. Judge Blackwell. This property is based on the semantics of the X.520 Common Name attribute.”可以看到,可以在名字前面加上一些尊称,诸如Doctor或者Mr等

[p4]

Q:经过测试发现,即便将配置为Number,而电话薄中存在一个没有电话号码的vCard,也会获取到该vCard

A:经过分析发现,有该疑问是由于没有完全理解Spec中对于该参数的描述导致的

上一篇:MQTT-SN协议乱翻之小结篇


下一篇:OSI七层协议模型、TCP/IP四层模型