SIP信息方法( 三 )


请求已取消”回应给INFO 。
然而,INFO消息决不许改变SIP呼叫的状态,或SIP初始化的会议 。
2.5SIP代理和重定向服务器的的行
2.5.1代理服务器
除非被申明,在一个服务器上的INFO的协议规定与那些在【1】中说明的BYE请求
的协议规定相一致 。
2.5.2分支代理服务器
除非被申明,在一个服务器上的INFO的协议规定与那些在【1】中说明的BYE请求
的协议规定相一致 。
2.5.3重定向服务器
除非被申明,在一个服务器上的INFO的协议规定与那些在【1】中说明的BYE请求
的协议规定相一致 。
3.INFO消息体
INFO消息的目的是在SIP用户代理间传送会议中的信息 。这一信息尽管能够在INFO信
息头中传送,它一般地将被放在消息体中传送 。
对于消息体的定义或其它任何为INFO方法产生的新头部在本文档讨论范围之外 。期望能
够产生以定义这些实体为目标的独立文档 。
另外,INFO方法并不定义确保按顺序传送的附加机制 。当CSeq头部将在传送新的
INFO消息消息时自增,这就不能被用来决定INFO信息的顺序,这是由于一个事实,即在
用户代理发送有re-INVITES或其它SIP消息时在INFO消息CSeq的计数中将会引起鸿沟 。
4.利用INFO扩展的指导方针
以下是在定义利用INFO方法的SIP扩展时必须考虑的方面 。
-被INFO消息传送的消息体的大小必须要考虑 。由于消息将可能在UDP上传送并且可能
重组一个大的消息,消息体应该保持较小 。
-有一种可能是INFO消息能被一个SIP代理服务器创建 。完成这一INFO消息中的信息
的创建过程需要被考虑 。
-当定义被INFO消息传送的消息体时,多部分消息体的应用将会很有用 。
-用INFO消息的扩展不答应依靠INFO消息做那些影响SIP 呼叫的状态或相关会
议的状态的事 。
-本文档定义的INFO扩展不依靠于请求或代理请求头部的应用 。用INFO消息的扩展名
可能需要应用这些机制 。然而,假如有可能请求或代理请求的应用最好能避免,以便在SIP
实体间可以互操作 。
5.安全性考虑
假如,消息体的内容是私有的,那么端到端的消息体的加密能够阻止未授权的进入去访
问它的内容 。
没有其它的安全方法说明给INFO方法.在SIP说明中所说明的安全需要同样用于INFO
方法 。
6.参考资料
[1]Handley,M.,Schulzrinne,H.,Schooler,E.andJ.Rosenberg,
"SIP:SessionInitiationProtocol",RFC2543,March1999.
7.致谢
作者需要感谢MatthewCannon对这一文档作出的贡献 。另外,作者想感谢
MMUSIC和SIP工作组的成员,非凡是JonathanRosenberg,他评论和建议如何提高本
文档的质量 。
8.作者联系方法
SteveDonovan
dynamicsoft
5100TennysonParkway,Suite200
Plano,Texas75024
Email:sdonovan@dynamicsoft.com
9.版权说明
Copyright(C)TheInternetSociety(2000).AllRightsReserved.
本文档和他的译本将被拷贝和附给其他人,Thisdocumentandtranslationsofitmay
becopiedandfurnishedto
others,andderivativeworksthatcommentonorotherwiseexplainit
orassistinitsimplementationmaybeprepared,copied,published
anddistributed,inwholeorinpart,withoutrestrictionofany
kind,providedthattheabovecopyrightnoticeandthisparagraphare
includedonallsUChcopiesandderivativeworks.However,this
documentitselfmaynotbemodifiedinanyway,suchasbyremoving
thecopyrightnoticeorreferencestotheInternetSocietyorother
Internetorganizations,exceptasneededforthepurposeof
developingInternetstandardsinwhichcasetheproceduresfor
copyrightsdefinedintheInternetStandardsprocessmustbe

推荐阅读