sip 初步理解
2013-01-05 20:29
330 查看
一次典型的SIP呼叫
下面对所有的消息进行了解释:
1. User Agent A发送一个SIP请求INVITE给User Agent B,表达User A想跟User B进行谈话的愿望。这个请求包含语音流协议的细节。payload中使用会话描述协议(Session Description Protocol,SDP)就是为此目的。SDP消息包含一个清单,其内容为User A支持的所有介质编码。(这些编码使用RTP进行传输。) INVITE
sip:UAB@example.com
SIP/2.0
Via: SIP/2.0/UDP 10.20.30.40:5060
From: UserA <sip:UAA@example.com>;tag=589304
To: UserB <sip:UAB@example.com>
Call-ID: 8204589102@example.com
CSeq: 1 INVITE
Contact: <sip:UserA@10.20.30.40>
Content-Type: application/sdp
Content-Length: 141
v=0
o=UserA 2890844526 2890844526 IN IP4 10.20.30.40
s=Session SDP
c=IN IP4 10.20.30.40
t=3034423619 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
2. User Agent B读取该请求,然后告诉User Agent A它已经收到请求。 SIP/2.0
100 Trying
From: UserA <sip:UAA@example.com>;tag=589304
To: UserB <sip:UAB@example.com>
Call-ID: 8204589102@example.com
CSeq: 1 INVITE
Content-Length: 0
3.当电话响铃时,User Agent B发送临时消息(响铃)给User Agent A,这样它就不会超时和放弃。 SIP/2.0
180 Ringing
From: UserA <sip:UAA@example.com>;tag=589304
To: UserB <sip:UAB@example.com>;tag=314159
Call-ID: 8204589102@example.com
CSeq: 1 INVITE
Content Length: 0
4.最终,User B决定接受呼叫。此时,User Agent B发送一个OK响应给User Agent A。在响应的payload中,还有另一条SDP消息。它包含一组两个用户代理都支持的介质编码。此时,双方正式处于呼叫中。使用200类型的响应可以接受所有类型的SIP请求。 SIP/2.0
200 OK
From: UserA <sip:UAA@example.com>;tag=589304
To: UserB <sip:UAB@example.com>;tag=314159
Call-ID: 8204589102@example.com
CSeq: 1 INVITE
Contact: <sip:UserB@10.20.30.41>
Content-Type: application/sdp
Content-Length: 140
v=0
o=UserB 2890844527 2890844527 IN IP4 10.20.30.41
s=Session SDP
c=IN IP4 10.20.30.41
t=3034423619 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
5. User Agent A最后使用一条ACK消息进行确认。对于这种请求类型来说,没有重试和响应消息,即使消息丢失。ACK只在INVITE消息中使用。 ACK
sip:UAB@example.com SIP/2.0
Via: SIP/2.0/UDP 10.20.30.41:5060
Route: <sip:UserB@10.20.30.41>
From: UserA <sip:UAA@example.com>;tag=589304
To: UserB <sip:UAB@example.com>;tag=314159
Call-ID: 8204589102@example.com
CSeq: 1 ACK
Content-Length: 0
6..两个用户代理现在使用最后一条SDP消息中选定的方法进行连接。 RTP使用PCMU/8000编码对在端口49170 & 3456上双向传输的音频数据进行打包。
7.在通信会话结束时,其中一个用户挂断。此时,这个用户的用户代理发送一个新的请求BYE。这条消息可以由任一方发送。 BYE
sip:UAB@example.com SIP/2.0
Via: SIP/2.0/UDP 10.20.30.41:5060
To: UserB <sip:UAB@example.com>;tag=314159
From: UserA <sip:UAA@example.com>;tag=589304
Call-ID: 8204589102@example.com
CSeq: 1 BYE
Content-Length: 0
8.另一用户的用户代理接受该请求,然后使用一条OK消息作为应答。呼叫连接至此断开。 SIP/2.0
200 OK
To: UserB <sip:UAB@example.com>;tag=314159
From: UserA <sip:UAA@example.com>;tag=589304
Call-ID: 8204589102@example.com
CSeq: 1 BYE
Content-Length: 0
SIP消息的第一行包含消息的类型和所使用的SIP版本(2.0)。在请求中,这一行还包含一个叫做SIP URI的地址。这代表消息的目的地。
这个例子说明了如何使用请求消息INVITE、ACK和BYE,以及200 OK响应消息。SIP中还存在许多其他消息。下面给出一些请求:
消息 用法
INVITE 呼叫一个用户代理,传送一次呼叫。
ACK 确认呼叫。
BYE 终止呼叫。
CANCEL 终止还未OK的呼叫。
REGISTER 提供一项注册服务,带有一个联系地址和可以用来代替的别名。例如,在前面的例子中,地址sip:UAA@example.com就是sip:UserA@10.20.30.40的别名。然后,注册服务器example.com就可以把呼叫转发给地址10.20.30.40。
OPTIONS 询问一个用户代理的“能力”(例如,该用户代理能够识别的消息和编码)。
现在给出一些经常使用的响应消息:
消息 用法
100 Trying 消息已收到,但是最终用户代理尚未进行处理。请等待。
180 Ringing 最终用户代理已经收到消息,正在提示用户。请等待。
200 OK 最终用户已经接受消息。
301 Moved Permanently & 302 Moved Temporarily 用户代理的地址已经改变,新的永久或临时地址位于Contact字段中。
400 Bad Request 普通错误消息。客户端不能识别消息。
401 Unauthorized & 407 Proxy Authentication Required 请使用证书重试。
404 Not Found 要联系的用户不存在或尚未注册。
408 Request Timeout 另一方没有响应。这意味着SIP消息永远不会OK。所有重试都将被丢弃。这并不意味着电话响太长时间(电话可以永远响铃)。
消息使用类似的头字段类型。下面给出其中的一些:
头字段 用法
From SIP请求的发送者。
To SIP请求的接受者。这通常与SIP URI相同(可以是一个“别名”或一个实际地址)。
Contact 用户代理的实际地址。
Call-ID 这并不是呼叫者的电话号码。它惟一地代表两个用户代理之间的完整呼叫或对话。所有相关的SIP消息都使用同一个Call-ID。例如,当一个用户代理收到一条BYE消息,根据Call-ID,它就知道要挂断哪次呼叫。
CSeq 消息的顺序编号。这在一次对话或一个Call-ID中是惟一的。这用于区别新的消息和“重试消息”。当一条初始消息没有及时OK时,重试就会进行,并会定时发送。
Content-Type 消息内payload的MIME类型。
Content-Length payload的大小,以字节为单位。信封和payload之间由一空行隔开。
还有一些与消息路由选择功能相关的头字段,如:Via、Route和Record-Route。许多头字段提供像Accept、User-Agent和Supported这样的功能。其他头字段则提供像Authorization、Privacy和WWW-Authenticate这样的安全性功能。还有很多其他的头字段存在。此外,这些字段中许多都有缩写语法(比如,From = f,To = t,等等)。
下面对所有的消息进行了解释:
1. User Agent A发送一个SIP请求INVITE给User Agent B,表达User A想跟User B进行谈话的愿望。这个请求包含语音流协议的细节。payload中使用会话描述协议(Session Description Protocol,SDP)就是为此目的。SDP消息包含一个清单,其内容为User A支持的所有介质编码。(这些编码使用RTP进行传输。) INVITE
sip:UAB@example.com
SIP/2.0
Via: SIP/2.0/UDP 10.20.30.40:5060
From: UserA <sip:UAA@example.com>;tag=589304
To: UserB <sip:UAB@example.com>
Call-ID: 8204589102@example.com
CSeq: 1 INVITE
Contact: <sip:UserA@10.20.30.40>
Content-Type: application/sdp
Content-Length: 141
v=0
o=UserA 2890844526 2890844526 IN IP4 10.20.30.40
s=Session SDP
c=IN IP4 10.20.30.40
t=3034423619 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
2. User Agent B读取该请求,然后告诉User Agent A它已经收到请求。 SIP/2.0
100 Trying
From: UserA <sip:UAA@example.com>;tag=589304
To: UserB <sip:UAB@example.com>
Call-ID: 8204589102@example.com
CSeq: 1 INVITE
Content-Length: 0
3.当电话响铃时,User Agent B发送临时消息(响铃)给User Agent A,这样它就不会超时和放弃。 SIP/2.0
180 Ringing
From: UserA <sip:UAA@example.com>;tag=589304
To: UserB <sip:UAB@example.com>;tag=314159
Call-ID: 8204589102@example.com
CSeq: 1 INVITE
Content Length: 0
4.最终,User B决定接受呼叫。此时,User Agent B发送一个OK响应给User Agent A。在响应的payload中,还有另一条SDP消息。它包含一组两个用户代理都支持的介质编码。此时,双方正式处于呼叫中。使用200类型的响应可以接受所有类型的SIP请求。 SIP/2.0
200 OK
From: UserA <sip:UAA@example.com>;tag=589304
To: UserB <sip:UAB@example.com>;tag=314159
Call-ID: 8204589102@example.com
CSeq: 1 INVITE
Contact: <sip:UserB@10.20.30.41>
Content-Type: application/sdp
Content-Length: 140
v=0
o=UserB 2890844527 2890844527 IN IP4 10.20.30.41
s=Session SDP
c=IN IP4 10.20.30.41
t=3034423619 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
5. User Agent A最后使用一条ACK消息进行确认。对于这种请求类型来说,没有重试和响应消息,即使消息丢失。ACK只在INVITE消息中使用。 ACK
sip:UAB@example.com SIP/2.0
Via: SIP/2.0/UDP 10.20.30.41:5060
Route: <sip:UserB@10.20.30.41>
From: UserA <sip:UAA@example.com>;tag=589304
To: UserB <sip:UAB@example.com>;tag=314159
Call-ID: 8204589102@example.com
CSeq: 1 ACK
Content-Length: 0
6..两个用户代理现在使用最后一条SDP消息中选定的方法进行连接。 RTP使用PCMU/8000编码对在端口49170 & 3456上双向传输的音频数据进行打包。
7.在通信会话结束时,其中一个用户挂断。此时,这个用户的用户代理发送一个新的请求BYE。这条消息可以由任一方发送。 BYE
sip:UAB@example.com SIP/2.0
Via: SIP/2.0/UDP 10.20.30.41:5060
To: UserB <sip:UAB@example.com>;tag=314159
From: UserA <sip:UAA@example.com>;tag=589304
Call-ID: 8204589102@example.com
CSeq: 1 BYE
Content-Length: 0
8.另一用户的用户代理接受该请求,然后使用一条OK消息作为应答。呼叫连接至此断开。 SIP/2.0
200 OK
To: UserB <sip:UAB@example.com>;tag=314159
From: UserA <sip:UAA@example.com>;tag=589304
Call-ID: 8204589102@example.com
CSeq: 1 BYE
Content-Length: 0
SIP消息的第一行包含消息的类型和所使用的SIP版本(2.0)。在请求中,这一行还包含一个叫做SIP URI的地址。这代表消息的目的地。
这个例子说明了如何使用请求消息INVITE、ACK和BYE,以及200 OK响应消息。SIP中还存在许多其他消息。下面给出一些请求:
消息 用法
INVITE 呼叫一个用户代理,传送一次呼叫。
ACK 确认呼叫。
BYE 终止呼叫。
CANCEL 终止还未OK的呼叫。
REGISTER 提供一项注册服务,带有一个联系地址和可以用来代替的别名。例如,在前面的例子中,地址sip:UAA@example.com就是sip:UserA@10.20.30.40的别名。然后,注册服务器example.com就可以把呼叫转发给地址10.20.30.40。
OPTIONS 询问一个用户代理的“能力”(例如,该用户代理能够识别的消息和编码)。
现在给出一些经常使用的响应消息:
消息 用法
100 Trying 消息已收到,但是最终用户代理尚未进行处理。请等待。
180 Ringing 最终用户代理已经收到消息,正在提示用户。请等待。
200 OK 最终用户已经接受消息。
301 Moved Permanently & 302 Moved Temporarily 用户代理的地址已经改变,新的永久或临时地址位于Contact字段中。
400 Bad Request 普通错误消息。客户端不能识别消息。
401 Unauthorized & 407 Proxy Authentication Required 请使用证书重试。
404 Not Found 要联系的用户不存在或尚未注册。
408 Request Timeout 另一方没有响应。这意味着SIP消息永远不会OK。所有重试都将被丢弃。这并不意味着电话响太长时间(电话可以永远响铃)。
消息使用类似的头字段类型。下面给出其中的一些:
头字段 用法
From SIP请求的发送者。
To SIP请求的接受者。这通常与SIP URI相同(可以是一个“别名”或一个实际地址)。
Contact 用户代理的实际地址。
Call-ID 这并不是呼叫者的电话号码。它惟一地代表两个用户代理之间的完整呼叫或对话。所有相关的SIP消息都使用同一个Call-ID。例如,当一个用户代理收到一条BYE消息,根据Call-ID,它就知道要挂断哪次呼叫。
CSeq 消息的顺序编号。这在一次对话或一个Call-ID中是惟一的。这用于区别新的消息和“重试消息”。当一条初始消息没有及时OK时,重试就会进行,并会定时发送。
Content-Type 消息内payload的MIME类型。
Content-Length payload的大小,以字节为单位。信封和payload之间由一空行隔开。
还有一些与消息路由选择功能相关的头字段,如:Via、Route和Record-Route。许多头字段提供像Accept、User-Agent和Supported这样的功能。其他头字段则提供像Authorization、Privacy和WWW-Authenticate这样的安全性功能。还有很多其他的头字段存在。此外,这些字段中许多都有缩写语法(比如,From = f,To = t,等等)。
相关文章推荐
- jain-sip 一些类的初步理解
- jain-sip 一些类的初步理解
- android的文件系统结构及其引导过程的初步理解
- log4j初步理解/运用
- Ajax初步理解
- Hessian初步理解
- MSR初步理解
- OC学习笔记SEL类型初步理解
- 初步理解MVC与MVP
- 对硬盘分区的初步理解
- Nginx学习-初步理解
- 流行学习初步理解
- Android adt 初步理解和分析(三)
- (Struts2,Spring,Ibatis)初步整合理解
- 三层架构初步理解
- 初步理解iOS编程的委托机制Delegate
- JavaScript 初步闭包理解
- javabean的初步理解
- js开发: JavaScript 中的面向对象的初步理解
- ASP.NET底层的初步认识与理解