sip user Authentication and 401
https://www.vocal.com/sip-2/sip-user-authentication/
https://tools.ietf.org/html/rfc3261
SIP User Authentication
There are two forms of authentication in SIP – authentication of a user agent (UA) by a proxy, redirect, or registration server and authentication of one UA by another. With Transport Layer Security (TLS), mutual authentication of proxies or a proxy and UA is accomplished using certificates. Authentication is used to allow only authorized access to a service or feature and prevent malicious or unauthorized use by other applications.
Digest Authentication
Digest authentication is a simple challenge/response method based on HTTP. For RFC 2069, it employs a MD5 hash algorithm to encode the username, realm, password, digest URI, and server generated nonce as follows:
- H1 = MD5(username : realm : password)
- H2 = MD5(method : digestURI)
- Response = MD5(H1 : nonce : H2)
RFC 2617 added a client generated nonce and quality of protection (QoP) to improve security as follows:
- Response = MD5(H1 : nonce : nonceCount : nonceClient : QoP : H2)
SIP Proxy and User Authentication
As depicted in the figure, the message flow for both proxy and user agent authentication is illustrated. The initial INVITE is challenged with a 407 Proxy authorization required. The UA responds with an ACK and then reissues the INVITE containing the authentication credentials. The next proxy server or end UA responds with a 401 Unauthorized message back to the source UA to again reissue the INVITE with the proper authentication credentials and complete the authentication process.
说明:
sip的认证算法真的是采用的这个算法:
- H1 = MD5(username : realm : password)
- H2 = MD5(method : digestURI)
- Response = MD5(H1 : nonce : H2)
其中,
realm 为事先就确定好的,realm及nonce 为服务器在告诉UA需要认证时给UA的;
method 为服务器给UA一些Digest算法选项,然后由UA选一种。
digestURI 为UA需要到达的目的地;示例如下(这是设备192.168.23.113上的2004拨打2007的invite信令):
Via: SIP/2.0/UDP 192.168.23.113:;branch=z9hG4bK.rxkOqoU6K;rport
From: "sabresd" <sip:@192.168.23.100>;tag=i-ljgBYGN
To: sip:@192.168.23.100
CSeq: INVITE
Call-ID: c2kQFPZtPJ
Max-Forwards:
Supported: replaces, outbound
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO, UPDATE
Content-Type: application/sdp
Content-Length:
Contact: <sip:@192.168.23.113;transport=udp>;+sip.instance="<urn:uuid:b13bc5f4-aefc-412f-b586-7a409b46e058>"
User-Agent: LinphoneAndroid/ (belle-sip/1.5.)
Authorization: Digest realm="asterisk", nonce="1007a06b", algorithm=MD5, username="", uri="sip:2007@192.168.23.100", response="45316d80ffca2b4094333af2631d0c9f" v=
o= IN IP4 192.168.23.113
s=Talk
c=IN IP4 192.168.23.113
b=AS:
t=
a=rtcp-xr:rcvr-rtt=all: stat-summary=loss,dup,jitt,TTL voip-metrics
m=audio RTP/AVP
a=rtpmap: opus//
a=fmtp: useinbandfec=
a=rtpmap: SILK/
a=rtpmap: speex/
a=fmtp: vbr=on
a=rtpmap: speex/
a=fmtp: vbr=on
a=rtpmap: telephone-event/
a=rtpmap: telephone-event/
a=rtpmap: telephone-event/
m=video RTP/AVP
a=rtpmap: H264/
a=fmtp: profile-level-id=42801F
a=rtcp-fb: nack pli
a=rtcp-fb: ccm fir
从上可以看出,此处的invite信令是要邀请sip:2007@192.168.23.100,因此digestURI即为"sip:2007@192.168.23.100"。
其中,Via的结构是 sip协议/sip版本/UDP,Via里的 192.168.23.113:5060 表示此信息从哪里发送的,此信息的responce应该带上此信息,服务器回复此信息的时候其Via里也需要带其收到的该信息,不需要改动,由此来表明此信息的目的地,因此非目的地设备收到此信息时可以忽略该信息。
最新文章
- Java中抽象类和接口的区别
- 请问如何查看mysql 的端口号?
- dubbo.xsd
- JDK源码分析之集合02ArrayList
- 【USACO 1.3.3】回文串
- python-文件压缩和解压
- linux命令之mount
- ActiveMQ in Action(1) - JMS
- 关于jquery尺寸的总结
- CF1152E Neko and Flashback--欧拉路径
- PDF怎么旋转页面,只需几步轻松搞定!
- WPF BitmapImage 占用资源无法释放、无法删除问题
- Pandas的可视化操作(利用pandas得到图表)
- Python基础-python变量(三)
- woff字体MIME类型配置
- 亚马逊IOT-SDK,线程池数
- Syslog和Windows事件日志收集
- Python 错误和异常小结[转]
- Windows和linux通过命令互传文件
- PyCharm在win10的64位系统安装实例
热门文章
- rsync安全
- python3中try异常调试 raise 异常抛出
- 使用 ESlint、lint-staged 半自动提升项目代码质量
- 从客户端(content=";xxxxx";)中检测到有潜在危险的 Request.Form 值——较合理解决方案
- CentOS7.5环境下搭建禅道
- [转]kafka要等一段时间才能消费到数据
- Spark数据倾斜解决方案(转)
- Spark API--Spark 分区
- SQL操作Spark SQL--CatalogApiTest
- fiddler抓取手机https请求详解