sip消息的路由
2012-03-23 22:04
232 查看
不知为何,出现在CSDN的“2011年风云专栏”评选中,两个专栏,入围一个,另一个访问人数多一倍的没有,不知道是什么标准。希望不要最后一名现眼。这种活动,还是自愿参加为好。
今天下午去了大学城,看IMAX《异星战场》。画面***很精良,而剧情实在受不了,不是说剧情简单问题,只是情节要圆满一些。一开始,出现了三个所谓的使者,而主人公在离开地球之前干掉一个,在第二次离开又干掉一个,还有一个啊。这些神通广大的人,在主人公从Mars回到地球,再回去Mars,中间好像有11年,具体不记得了,只要11个月,那2个使者完全可天翻地覆,知道射线的火星公主本要被干掉,估计也已被处理。这真是吐血的结局。
Mars的某种土著有4只手,但是作为2只手的人类,不能充分想像四只手如何用。感觉有2只很是多余,没能充分利用。
看IMAX,效果很好,但是字幕在影片的下面(不再画面上,完全在下面),上次阿凡达是浮在画面中下处。结果看得很辛苦,只好尽量不看,幸好对白不多。我有点近视,100度,平实不带眼镜,但是IMAX看不清楚。只好带上眼镜矫正。
SIP研究是很久之前,真的很久很久,以至于被人问的时候,一下不知道如何回答。N年之前写过基于java的sip stack,那时没有什么sip的开源,特别是没有基于java。之后在互联互通时,对一些特殊业务流程,碰到问题通常是不能完全遵循协议,也就是只实现了协议的某个子集,由此也对SIP有更多的研究,无他,就是协议精读。后来帮别人做相关互联互通问题的评判,通常都号称遵循协议,互相指责对方不遵循。实际上确实完全遵循协议,只是没有完全覆盖协议。这次碰到的case也是互联互通导致。
具体的业务流程不谈,实际是:
1、SIP请求消息(INVITE)中的Request-URI是否可以和To中的不一样?
2、如果不一样,路由是根据哪个来设定?
先回答第二个问题:SIP消息的路由如何决定?
路由并不是由To来确定,每个SIP消息中都包含路由关系,单从消息本身可以判断发往哪个地址,有以下几个优先顺序:
1、Route字段强制要求
2、对于请求消息:Request-URI,对于应答消息,Via,并优先maddr参数中的地址。
从Record-Route中获得信息,填入Route中,顺序相反(按stack理解,实现原路返回)。根据Contact信息,设置Request-URI。
回头看第一个问题:在SIP消息传递过程中,中间的AS,IMS,SS,Proxy,如何对SIP消息进行处理?
它们可根据可根据对业务的理解,对真实的目的地重新处理。在RFC3261的16.5 Determining Request Targets明确给出:
2. Update the Request-URI。
The Request-URI in the copy's start line MUST be replaced with the URI for this target. If the URI contains any parameters not allowed in a Request-URI, they MUST be removed. This is the essence of a proxy's role. This is the mechanism through which a proxy
routes a request toward its destination.
通常UAC发出的第一个INVITE的Request-URI和To是一样的,在RFC3261中用了SHOULD。中间经过的服务器,将Request URI修改为真正的目的地,例如呼转的情况下。Request-URI可以修改,可以和To不一致。对于session的第一个INVITE消息,没有Route字段,也就是由Request-URI指出下一跳。
相关链接:我的网络通信相关文章
今天下午去了大学城,看IMAX《异星战场》。画面***很精良,而剧情实在受不了,不是说剧情简单问题,只是情节要圆满一些。一开始,出现了三个所谓的使者,而主人公在离开地球之前干掉一个,在第二次离开又干掉一个,还有一个啊。这些神通广大的人,在主人公从Mars回到地球,再回去Mars,中间好像有11年,具体不记得了,只要11个月,那2个使者完全可天翻地覆,知道射线的火星公主本要被干掉,估计也已被处理。这真是吐血的结局。
Mars的某种土著有4只手,但是作为2只手的人类,不能充分想像四只手如何用。感觉有2只很是多余,没能充分利用。
看IMAX,效果很好,但是字幕在影片的下面(不再画面上,完全在下面),上次阿凡达是浮在画面中下处。结果看得很辛苦,只好尽量不看,幸好对白不多。我有点近视,100度,平实不带眼镜,但是IMAX看不清楚。只好带上眼镜矫正。
SIP研究是很久之前,真的很久很久,以至于被人问的时候,一下不知道如何回答。N年之前写过基于java的sip stack,那时没有什么sip的开源,特别是没有基于java。之后在互联互通时,对一些特殊业务流程,碰到问题通常是不能完全遵循协议,也就是只实现了协议的某个子集,由此也对SIP有更多的研究,无他,就是协议精读。后来帮别人做相关互联互通问题的评判,通常都号称遵循协议,互相指责对方不遵循。实际上确实完全遵循协议,只是没有完全覆盖协议。这次碰到的case也是互联互通导致。
具体的业务流程不谈,实际是:
1、SIP请求消息(INVITE)中的Request-URI是否可以和To中的不一样?
2、如果不一样,路由是根据哪个来设定?
先回答第二个问题:SIP消息的路由如何决定?
路由并不是由To来确定,每个SIP消息中都包含路由关系,单从消息本身可以判断发往哪个地址,有以下几个优先顺序:
1、Route字段强制要求
2、对于请求消息:Request-URI,对于应答消息,Via,并优先maddr参数中的地址。
从Record-Route中获得信息,填入Route中,顺序相反(按stack理解,实现原路返回)。根据Contact信息,设置Request-URI。
回头看第一个问题:在SIP消息传递过程中,中间的AS,IMS,SS,Proxy,如何对SIP消息进行处理?
它们可根据可根据对业务的理解,对真实的目的地重新处理。在RFC3261的16.5 Determining Request Targets明确给出:
2. Update the Request-URI。
The Request-URI in the copy's start line MUST be replaced with the URI for this target. If the URI contains any parameters not allowed in a Request-URI, they MUST be removed. This is the essence of a proxy's role. This is the mechanism through which a proxy
routes a request toward its destination.
通常UAC发出的第一个INVITE的Request-URI和To是一样的,在RFC3261中用了SHOULD。中间经过的服务器,将Request URI修改为真正的目的地,例如呼转的情况下。Request-URI可以修改,可以和To不一致。对于session的第一个INVITE消息,没有Route字段,也就是由Request-URI指出下一跳。
相关链接:我的网络通信相关文章
相关文章推荐
- SIP消息路由
- SIP消息路由机制
- SIP消息路由机制
- SIP消息路由
- SIP消息路由机制
- SIP消息路由
- SIP消息头域的说明(转)
- sip消息的常见流程
- 深入biztalk消息以及消息订阅发布路由机制(三)-消息发布和路由
- SIP消息源路由
- sip消息概念(一)
- 07-rabbitmq-消息路由
- DUILIB库笔记:消息的路由
- 分布式消息队列RocketMQ源码分析之1 -- Topic路由数据结构解析 -- topicRoute与topicPublishInfo与queueId
- RabbitMQ (消息队列)专题学习05 routing(路由)
- freeDiameter源码阅读之消息路由
- Mule的消息路由
- RabbitMQ 基础教程 Routing(消息路由)
- SIP消息头域的说明
- SIP消息