CANCEL/BYE都在RFC 3261中定义。
CANCEL

CANCEL 用于取消客户端先前发送的请求。具体来说,它要求UAS停止处理请求并生成对该请求的error response。CANCEL对于UAS 已给出final response的请求没有影响。一般CANCEL用于取消服务器很长时间才能响应的请求。所以CANCEL 最适合 INVITE 请求,因为该请求可能需要很长时间才能生成response。在接收到 INVITE的 CANCEL 请求但尚未发送final response的 UAS 将“停止响铃”,然后使用特定的error response(487)来响应 INVITE。代理和UA都可以构造和发送 CANCEL 请求。CANCEL是在UAS尚未生成INVITE的final response时用。
BYE

BYE可以用于终止特定session或尝试的session。在这种情况下,特定session是与dialog另一方对等UA之间的session。当在dialog中收到 BYE 时,与该dialog关联的任何session都应该终止,这样也就决定了UA必须在dialog 内发送BYE,不然也没什么意义。这里还有一点需要注意,MO的UA可以为已确认 dialog或 early dialog发送 BYE,MT的UA只能在已确认dialog中发送BYE,但不能在early dialog中发送BYE。

而MT UA发送BYE也是有条件限制的,MT的UA只能在收到2xx 响应的ACK 或服务器transaction超时,才能在已确认dialog上发送BYE。
在dialog和session中,对INVITE的non-2xx final response ,CANCEL也会起到一定作用。CANCEL会尝试强制对INVITE做出non-2xx response(特别是 487)。
因此,如果 UAC 希望完全放弃其呼叫尝试,那就可以发送 CANCEL。如果UAC发送了CANCEL后,却收到了 INVITE request的 2xx final response ,就意味着UAS在CANCEL 正在进行时接受了invitation,那UAC可以继续由 2xx response建立的session,也可以用 BYE 终止sessions。
本文详细解释了在SIP协议RFC3261中,CANCEL和BYE的作用,尤其是在INVITE请求的上下文中。CANCEL用于取消长时间响应的请求,而BYE用于终止特定会话。它们在对话和会话中影响最终响应和会话管理。
5112

被折叠的 条评论
为什么被折叠?



