sip RFC 4538 通过dialog授权请求


背景:

一般情况下,当UA收到一个会创建dialog的请求(invite/subscribe/refer)后,需要决定是否授权此请求,而有些时候UA通过判断请求是不是在一个已经建立的dialog中,以决定是否鉴权此请求,

比如INVITE建立dialog后,在此dialog内发送的其他请求(prack,act等),UA并不需要鉴权,但问题是对于refer,message,subscribe请求,会重新建立一个新的dialog,UA如果想知道这些请求是否是在一个已经建立的dialog后的新建dialog的请求,通过什么判断?此规范应运而生。

 

此规范适用范围:

INVITE,Refer,SUBSCRIBE 这些方法会创建dialog,通常是用INVITE创建dialog,然后Reffer、SUBSCRIBE创建独立的dialog,但对于Reffer或SUBSCRIBE,UA怎样确定这些请求是在一个已有的dialog上新创建的dialog?

 


此规范通过引入一个新SIP消息头Target-Dialog,以及与其对应的opiontag用于标示UA是否支持此扩展。

以refer方法为例,简述此扩展使用过程,如上图:

用户A发送INVITE,中间通过server a,b转发到用户B,用户B 响应200 ok,如果用户B支持此扩展,其会在support头用添加tdialog选项,告知对方其支持此扩展,用户A收到带tdialog选项的200ok后A,B之间建立一个dialog.

建立通话后,服务器a想发送refer给用户B,通过200 ok响应,服务器知道用户B支持此扩展,所以服务器在refer请求中添加Target-dialog头,内容为invite创建的dialog的标识,包括call-id,from-tag和to-tag.

用户B收到refer后,发现Target-dialog头,确认此请求已经存在一个dialog,认定其一定是用户A或者中间的proxy发送的请求,所以用户B接收求并处理此请求。

你可能感兴趣的:(sip RFC 4538 通过dialog授权请求)