深圳市宝安区华美居

0086-18665301040

SIP协议与应用场景技术分享笔记-卷1-rfc3261-6

SIP协议与应用场景技术分享笔记-卷1-rfc3261-6

7.1 Requests

SIP请求通过在起始行带一个Request行和其他的method加以区别。一个请求行包含method名称,一个Request-URI,和由单空格字符分开的协议版本。

请求行以换行符CRLF结束。可以允许无回车或换行,除了在以换行符结束的序列中。不允许在任何要素中有任意数量的空白格(LWS)存在。

Request-Line = Method SP Request-URI SP SIP-Version CRLF

Method: 此规范定义了六个方法: REGISTER支持注册联系消息,INVITE,ACK, 和CANCEL支持会话创建,BYE支持结束会话,OPTIONS支持对服务器的能力查询。SIP扩展中定义了其他的方法。

Request-URI: Request-URI是一个SIP或SIP URL在Section 19.1 介绍,它或者是一个标准的URL(RFC 2396 [5])。它表示这个用户或这个服务被记录。Request-URI不能包含非转义符空格或控制字符,不能以”<>”方式出现。

SIP 要素中可能支持Request-URIs,不一定是sip或者sips,也可能是其他的URL schemes形式,例如”tel”,这是RFC 2806 [9]的URL schemes。SIP要素可以在它们的处理过程中使用任何机制转译非SIP,最终生成SIP URI,或者其他的scheme。

SIP-Version: 请求和响应都包括在使用的SIP版本,并且遵守 [H3.1](HTTP替代了SIP,HTTP/1.1替代了SIP/2.0),这里涉及了版本顺序,遵守要求和版本更新数量。 为了遵从此规范,应用程序发送到SIP消息必须包括SIP版本 “SIP/2.0″。 此SIP版本字符串是大小写敏感,但是使用时必须发送大写字母。

不像HTTP/1.1,SIP把此版本号看作为一个一般字面字符串。在实际使用时,这应该没有什么不同。

7.2 Responses

SIP 响应消息和请求消息不同,响应消息包含一个Status-Line作为一个起始start-line。在每个要素中,一个Status-Line由响应版本,然后跟随一个数字类型的状态码以及其关联的文本短语,通过一个单空格字符分开。

除了在最后的CRLF顺序中,可以允许无CR(回车)或者LF(换行)转义字符。

Status-Line = SIP-Version SP Status-Code SP Reason-Phrase CRLF

状态码是一个三位整数的结果代码,它表示一个测试输出的响应理解,满足请求的要求。原因短语的目的是对状态码给予一个短语解释。使用状态码的目的是为了系统的自动处理,而原因短语的目的是方便用户阅读理解状态原因,具有可阅读性。用户不要求检查或显示原因短语。

这里,此规范建议使用明确的用词来表示原因短语,部署使用时可使用其他的文本。例如,在请求中的Accept-Language头中的语言。

状态码的第一个数字定义了响应的级别。状态码后两位没有层级的设置。因为这个原因,任何状态码介于100和199之间的响应被看作是”1xx response”,任何状态码介于200和299的响应看作是一个”2xx response”响应,以此类推。以第一个数字为划分类别,SIP/2.0支持了六个级别的状态响应码:

1xx: Provisional – 请求收到的响应码,表示是临时响应,会继续处理此请求;

2xx: Success – 成功收到处理流程,理解,接受了处理流程;

3xx: Redirection – 需要进一步的流程处理来完成此请求;

4xx: Client Error – 此请求中包含错误语法或不能满足服务器的要求;

5xx: Server Error – 服务器端不能满足一个明确有效请求;

6xx: Global Failure – 任何服务器都不能满足此请求流程。

Section 21 定义了这些级别和描述了其无效码。

7.3 Header Fields

在语法和语义方面,SIP头和HTTP头非常相似。在实际应用环境中,SIP header 遵从[H4.2] 对消息头的语法和对拓展头的规则。但是,后者通过HTTP定义,使用了隐藏的空格。此规范和RFC 2234[10]是一致的,仅使用了明确的空格,并且看作为语法的一个部分。

[H4.2] 也定义了同一域名称的多个头的语法,这些值都以逗号隔离的列表,这些列表可以合并成一个头值。这个应用方式也可以支持SIP,但是因为具体的规范有所不同。具体来说,任何SIP头都以下语法的形式表现

header = “header-name” HCOLON header-value *(COMMA header-value)

可以支持合并同一名称的头成为一个逗号隔离的列表。此 Contact header支持逗号隔离的列表,除非这个头的值是”*”。

7.3.1 Header Field Format

头域遵从标准的头格式标准,在Section 2.2 of RFC 2822 [3]定义。每个头由域名,然后冒号(“:”) 和域值构成。

field-name: field-value

消息头顶标准语法在Section 25 定义,然后紧跟一个任意数量的空格。但是,在部署使用时应该避免基于头域和冒号之间的空格,在值域和冒号之间使用一个单空格。

Subject: lunch

Subject : lunch

Subject :lunch

Subject: lunch

因此,以上格式都是有效的,建议使用最后的格式。

Header 头域可以扩展为多行,实现方式是通过在每一行前添加至少一个SP或HT tab键来实现。在下一行开始前的换行符和空格被看作是一个单SP政府。因此,以下几种格式表达的意思是相同的:

Subject: I know you’re there, pick up the phone and talk to me!

Subject: I know you’re there,

pick up the phone

and talk to me!

带不同域值的头的相对顺序不是非常重要。但是,规范推荐,为了支持代理处理,这些头(Via, Route,Record-Route,Proxy-Require,Max-Forwards,和Proxy-Authorization,例如) 应该出现在消息体的顶部来支持代理的快速解析。头的相对顺序和其对应的名称是非常重要的。如果或只有如果那个头的域值定义为以逗号分割的列表时(Section 7.3),具有同样名称的多个头值可以出现在消息中。它必须可以支持多行头值可能合并为一对”field-name: field-value”的形式,而没有改变消息的语义,首先预设每一个接下来的头值,然后以逗号分开。这个规则对WWW-Authenticate,Authorization,Proxy-Authenticate,和 Proxy-Authorization 头是一个例外。

带它们名字的多头值域可能出现在消息中,但是,因为它们的语法没有遵从Section 7.3的标准格式,它们不允许合并为单头行域值。

使用时必须可以处理同样名称的多头值,无论是每行单值合并的头或是逗号分隔的方式。

以下各组头值是有效,相等的:

Route: <sip:alice@atlanta.com>

Subject: Lunch

Route: <sip:bob@biloxi.com>

Route: <sip:carol@chicago.com>

Route: <sip:alice@atlanta.com>, <sip:bob@biloxi.com>

Route: <sip:carol@chicago.com>

Subject: Lunch

Subject: Lunch

Route: <sip:alice@atlanta.com>, <sip:bob@biloxi.com>, <sip:carol@chicago.com>

每个组的值是有效的,但是又表达各自不同含义:

Route: <sip:alice@atlanta.com>

Route: <sip:bob@biloxi.com>

Route: <sip:carol@chicago.com>

Route: <sip:bob@biloxi.com>

Route: <sip:alice@atlanta.com>

Route: <sip:carol@chicago.com>

Route: <sip:alice@atlanta.com>,<sip:carol@chicago.com>, <sip:bob@biloxi.com>

头的名称格式是通过每个头名称来定义的。它总是是UTF8文本八位字节不确定度顺序出现或空格,标志符,分隔符和带引号的字符出现。许多存在的头会附加到通过标准规范值,通过分号的方式,分隔参数名称,参数值,具体格式为:

field-name: field-value *(;parameter-name=parameter-value)

虽然任意数目的参数可以附加到头上,但是,任何已给定的参数名称不能出现第二次。

当对比头值时,头名称总是大小写不敏感的。要不然,这个头是一个指定的头,它已经声明了值域名称,参数名称和参数值是大小写不敏感的头。标记符总是大小写不敏感的字符。除非,这个标记符已经声明其属性,否则,被引号标注的字符值是大小写敏感的值。例如,

Contact: <sip:alice@atlanta.com>;expires=3600

等同于

CONTACT: <sip:alice@atlanta.com>;ExPiReS=3600

Content-Disposition: session;handling=optional

等同于

content-disposition: Session;HANDLING=OPTIONAL

以下这两组是不相同的:

Warning: 370 devnull “Choose a bigger pipe”

Warning: 370 devnull “CHOOSE A BIGGER PIPE”

7.3.2 Header Field Classification

一些头值仅使用在请求和响应的处理中,并且具有一定的意义。它们被称之为request header fields 和 response header fields。如果一个头出现在消息体中,没有匹配任何头的层级(例如,请求的头出现在响应的消息体中),它则必须被忽略掉。Section 20定义了头的各种层级。

SIP协议与应用场景技术分享笔记-卷1-rfc3261-6

SIP协议与应用场景技术分享笔记-卷1-rfc3261-6

关注微信公众号:asterisk-cn,获得有价值的Asterisk行业分享

Asterisk freepbx 中文官方论坛:http://bbs.freepbx.cn/forum.php

Asterisk freepbx技术文档: www.freepbx.org.cn

融合通信商业解决方案,协同解决方案首选产品:www.hiastar.com

Asterisk/FreePBX中国合作伙伴,官方qq技术分享群(3000千人):589995817

联系电话-18665301040
客服-3
客服-2
客服-1