sip RFC 4538 通过dialog授权请求

最新推荐文章于 2024-01-12 10:07:14 发布

piperzero

最新推荐文章于 2024-01-12 10:07:14 发布

阅读量222

点赞数

针对INVITE、Refer、SUBSCRIBE等方法创建dialog的场景，本文介绍了一种通过Target-Dialog SIP消息头来判断请求是否基于现有dialog的新规范。该规范有助于UA在处理Refer或Subscribe请求时，确认请求的有效性。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

背景：

一般情况下，当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接收求并处理此请求。