有关Call Hold 发出Re-Invite消息接收方无响应却有效果所引出的思考
 |
dracularking
2008-12-15
在sc中，偶然的发现当hold后接收方对相应invite消息的回调方法无反应 但却不影响hold效果 用wireshark截包后发现Re-Invite消息发送到proxy后就没有再转发给receiver
而linksys的硬电话却没有这种现象 粗略地比较了下两者消息构造的异同 发现via头域和sdp消息体有些区别，将via头域改后仍未果，待续～附上一篇相关文章 http://www.shengfang.org/blog/p/0424sipCallHold.php |
|
dracularking
2008-12-15
这是牵扯到对sip协议了解程度的一个问题 因此属于知识型范畴
相信只要认真阅读rfc文档 虽然浩如烟海 总会从蛛丝马迹中找到portal points |
|
dracularking
2008-12-15
在rfc2543中有这样一段
引用 B.5 Putting Media Streams on Hold If a party in a call wants to put the other party "on hold", i.e., request that it temporarily stops sending one or more media streams, a party re-invites the other by sending an INVITE request with a modified session description. The session description is the same as in the original invitation (or response), but the "c" destination addresses for the media streams to be put on hold are set to zero (0.0.0.0). 恰恰sc小组也是这么去实现的 |
 |
puroc
2008-12-15
sip协议都快忘光光了。。
|
|
dracularking
2008-12-15
是啊 我也不太熟 在努力挖掘中 现在正在看rfc3264
http://www.faqs.org/rfcs/rfc3264.html 看到很多资料都与我发现的事实相违背（proxy不再转发held消息） 其中阐述的offer/anwser模型都至少有reject动作的 |
|
puroc
2008-12-15
3264讲的是应该是SDP的offer/answer吧。以前也研究过，主要是用来做媒体协商的。你们现在做的这个业务是个什么场景啊，主要做的是什么东西啊？
|
|
dracularking
2008-12-15
其实从功能上来说本来都是可行的 已经可以达到put on hold和put off hold的效果
但是我想让它在hold时接收方能得到响应，就像hard phone一样，里面涉及到一些协议细节 里面看到这样一段 引用 Typically, when a user "presses" hold, the agent will generate an offer with all streams in the SDP indicating a direction of sendonly, and it will also locally mute, so that no media is sent to the far end, and no media is played out.
既然里面说了a direction of sendonly,又为什么说no media is sent to the far end，难道只有sent到proxy？关于这一点说的有些含糊 |
|
dracularking
2008-12-15
dracularking 写道 在rfc2543中有这样一段
引用 B.5 Putting Media Streams on Hold
If a party in a call wants to put the other party "on hold", i.e., request that it temporarily stops sending one or more media streams, a party re-invites the other by sending an INVITE request with a modified session description. The session description is the same as in the original invitation (or response), but the "c" destination addresses for the media streams to be put on hold are set to zero (0.0.0.0). 恰恰sc小组也是这么去实现的 我这里说错了，sc小组貌似没有这么去实现 sip中的Via头域的Sent-by Address是0.0.0.0，而sdp中的"c" destination addresses却不是0.0.0.0，但它却实现了hold的效果，所以这里大致推测可见单纯要hold只要"a" attribute updated |
|
dracularking
2008-12-16
又貌似这是已经被dreprecated的了
> In this scenario, Alice calls Bob, then Bob places the call on hold. > Bob then takes call off hold. Alice hangs up call. Note that hold > is unidirectional in nature. However, a UA that places the other > party on hold will generally also stop sending media, resulting in no > media exchange between the UAs. Older UAs may set the connection > address to 0.0.0.0 when initiating hold. However, this behavior has > been deprecated in favor of using the a=sendonly SDP attribute. |
|
dracularking
2008-12-18
初步取得的结论是proxy拒绝转发的缘由与via等header无关，而与sdp消息体内容有关
|
