SIP会话发起协议流程——自己根据rfc3261复写的一个例子

作者:sight

根据:rfc-3261

 

直接进入如下例子,此例同rfc3261,更多的是我的理解+我的注解以及我潦草的翻译。

 

发起者:[email protected]

响应者:[email protected]

 

                             Text-encode

SIP会话发起协议流程——自己根据rfc3261复写的一个例子

 

会话细节如媒体类型、编码器、样本率等没在SIP里描述,而是在SDP(RFC-2327)里描述。这个SDP就像副本一样被SIP携带。

 

 

 

 

第一步:

1. Alice的softphone发送一个邀请到SIP服务器(@atlanta.com)(proxy)获得SIP地址(@biloxi.com)安装在Alice的softphone里(或者通过DHCP)。

2. Alice的proxy通过一些手段获取biloxi.com的SIP服务器(一个方法是查看DNS表),如此获取到通往biloxi.com的中间代理、目的地址。

 

 

 

第二步:Alice开始向Bob发送邀请

SIP会话发起协议流程——自己根据rfc3261复写的一个例子

 

1.Alice收到100Trying表示第一个代理(proxy1)接收到了invite且正在向proxy2路由invite。这个响应包(100Trying)包括3位数字码(跟随一个可描述短语)。这个响应包也跟那个Invite包一样,有To,From,Call-ID,CSeq,分支参数,这样就让Alice的software关联了对应的invite包和response包。

 

2.然后atlanta.com代理接到的响应包里,代理将自己的地址加入到header field里(invite包里也有一个,便可形成呼应)。

 

3.同时,Proxy服务器查阅数据库(地址,包含bob的IP地址)。

 

 

 

第三步:当bob收到后,biloxi.com代理服务器再在接收到的invite包里加入一个自己的地址header field并且加进自己的SIP phone。

 

 

第四步:bob方要决定是否回应这个call(正如电话铃响了,bob听到声音的警醒,现在决定要不要接)。现在bob发送180Ringing通过路由返回invite发送起点。这次(回程)不不需要查看DNS,节节代理发送时将自己的地址抹去。这样每一层代理既看到了INVITE也看到了相应的response。

 

SIP会话发起协议流程——自己根据rfc3261复写的一个例子

 

当Alice的softphone接到这个180Ringing的响应时,它会给Alice本人通过消息或者声音等方式发送一个提醒。

 

 

第五步:Bob决定响应Call,会发送200(OK)响应。

 

1.)返回需要查看DNS的情况:由于回应(180和200)是不需要DNS查看的,但若直接回应收到486忙碌返回,这时biloxi.com代理服务器会发送邀请到Bob的语音信箱服务器,同时,代理服务器也会发送邀请到多个地址(有点像arp?只不过这里是取决于计算路径而不是取决于身份?),这被称作forking(分叉)。

 

 

200OK的包:

SIP会话发起协议流程——自己根据rfc3261复写的一个例子

 

 

 

 

2.)200(OK)包含了消息体携带SDP媒体描述:bob想要建立什么类型媒体的会话。如此以来Alice发送给bob有SDP,bob发送给Alice有SDP,形成对应。Bob如果不想建立会话或者正在忙于其他会话,会发送error而不是200(OK) (200(OK)的包的Via,To,From,Call-ID,CSeq是从INVITE包里拷贝来的,这个Via header field有三个,分别是Alice的SIP phone、atlanta.com代理、biloxi.com代理加进去的。而对于这个To header field,Bob SIP phone在发送200之前会加一个标签参数,这个标签会被合并进终点进入日志并且被包含在之后同一CALL中所有的请求和响应中。这个200的包中Content-Type和Content-Length也包含了SDP)。

 

 

 

 

第六步:当Alice收到200时,表明这个Call已经被回应了,于是发送ACK给Bob以达成最终确认。由于之前200响应让两个端知道了彼此的地址(通过Contact field这个header),所以这个ACK绕开了两个中间代理(此例中间代理为2个)直接发送给Bob,当然,也不需要再查看DNS。

 

 

 

 

 

 

 

 

 

 

 

INVITE,200,ACK组成三次握手:

SIP会话发起协议流程——自己根据rfc3261复写的一个例子

 

 

第七步:媒体会话开始,Alice和Bob互相传输包的格式经由之前互换SDP时达成一致。通常地,他们点对点传送的媒体包和信号包走的不同通路。若他们在会话中某一端想要改变会话的性质,他们可以发送一个re-INVITE的再邀请,其中包含了新的媒体描述。这个再邀请会根据已存在的dialog日志让对方知道修改会话。若是同意修改,择被邀请方会发送200(OK)以表示接受,当然,请求者仍然要再发送一个ACK。若是被邀方不接受则会发送error例如488以拒绝,之后请求者仍然会发送ACK。这个error并不会导致会话结束,他们将继续之前的会话。

 

 

 

SIP会话发起协议流程——自己根据rfc3261复写的一个例子

 

第八步:最终,Bob挂断电话,产生一个Bye消息,这个Bye消息仍然直接发送给Alice的softphone而不经过任何代理。Alice发送一个200(OK)以确认,之后不需要ACK了。由于SIP的可靠原理,我们可以——分类邀请:我们只要计算除了INVITE以外的所有方法长度(意思应该是除了INVITE外,其他方法长度(length)相对稳定),便可以对其进行分类。

 

 

 

 

 

 

 

 

 

概念——注册:这是让proxy知道往哪里推请求的方式之一,也是常用的一个方式。它只进不出,只要在这个proxy注册过,那么这个注册信息允许进入此proxy但没有发送出去的权限。根据初始化和一定周期间隔,Bob的SIP phone都会给biloxi.com服务器发送注册消息——SIP注册。注册经由包中的Contact header绑定Bob的SIP地址(如[email protected])到biloxi.com服务器数据库里,于是形成了绑定,当然,同一个服务器的数据库里可以绑定多个Bob地址(如果工作地址+家庭地址),这样以来服务器可以通过多重定位搜索到Bob的SIP phone。