0424 sip 呼叫保持 Call Hold

4.3.5 呼叫保持Call Hold
通话时,按下HOLD 按钮将使当前通话保持.具体为:在Re-INVITE 消息附
带SDP 消息中,发送的参数属性为"a=sendonly" 和IP 地址为0.0.0.0 做
传播媒介就可以实现.再一次按HOLD 按钮将释放刚才保持的状态,双向的
通话将再一次重新占用.通过Re=INVITE 附带的SDP 消息里,发送另一个
带有"a=sendrecv" 和在当前的IP 地址做传播媒介,即可恢复通话.

４．２ 呼叫控制业务

　　ＳＩＰ和Ｈ．３２３都支持呼叫保持、呼叫转移、呼叫前转、呼叫等待、电话会议和其他补充业务。以呼叫保持为例：Ｈ．３２３定义了近点呼叫保持和远点呼叫保持两种保持业务的场景，两者都可带网守或不带。网守仅仅透明地传送ＳＳ－ＨＯＬＤ。而ＳＩＰ实现同样的功能，只要向需要呼叫保持的一方发送一个更改了ＳＤＰ描述的ＩＮＶＩＴＥ命令即可。更改的ＳＤＰ描述段仅将媒体发送的目的地址变为空＜０．０．０．０＞，而其他的内容不变。收到该用户的ＵＡ，让呼叫保持，直到有新的ＩＮ ＶＩＴＥ到来为止。

看看RFC：
RFC3264 – An Offer/Answer Model with Session Description Protocol (SDP)
RFC3264 Section 6.1 says:
"If a stream is offered as sendonly, the corresponding stream MUST be marked
as recvonly or inactive in the answer."

RFC3264 Section 8.4 also says:

"If the stream to be placed on hold was previously a sendrecv media stream it is placed on hold by marking it as sendonly. If the stream to be placed on hold was previously a recvonly media stream, it is placed on hold by marking it inactive.
This means that a stream is placed "on hold" separately in each direction. Each stream is placed "on hold" independently. The recipient of an offer for a stream on-hold SHOULD NOT automatically return an answer with the corresponding stream on hold. An SDP with all streams "on hold" is referred to as held SDP."

In my mind, it seems to me that RFC3264 is very clear on how to deal with

ANY offer that is marked a=sendonly. You can 1)set the port to 0 to reject the offer 2) respond with a=recvonly
3) respond with a=inactive.
You certainly can NOT respond to a sendonly stream with sendrecv!!!

However, if my software responds to a=sendonly with a=recvonly the phone I have will only continue to offer a=sendonly from that point on.
But then I read RFC4317 Section 3.2 which lists an example in which an offer a=sendonly is responded to with no direction attribute (which implies
sendrecv!). The section of interest is below:

[Second-Offer]
v=0
o=bob 2808844564 2808844565 IN IP4 host.biloxi.example.com
s=
c=IN IP4 host.biloxi.example.com
t=0 0
m=audio 49172 RTP/AVP 97
a=rtpmap:97 iLBC/8000
a=sendonly
m=audio 49174 RTP/AVP 98
a=rtpmap:98 telephone-event/8000
a=recvonly

[Second-Answer]
v=0
o=alice 2890844526 2890844527 IN IP4 host.atlanta.example.com
s=
c=IN IP4 host.atlanta.example.com
t=0 0
m=audio 49170 RTP/AVP 0 97
a=rtpmap:0 PCMU/8000
a=rtpmap:97 iLBC/8000
m=audio 49172 RTP/AVP 98
a=rtpmap:98 telephone-event/8000
a=sendonly

8.4 Putting a Unicast Media Stream 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 unicast media   streams, a party offers the other an updated SDP.

   If the stream to be placed on hold was previously a sendrecv media   stream, it is placed on hold by marking it as sendonly.  If the   stream to be placed on hold was previously a recvonly media stream,   it is placed on hold by marking it inactive.

   This means that a stream is placed "on hold" separately in each   direction.  Each stream is placed "on hold" independently.  The   recipient of an offer for a stream on-hold SHOULD NOT automatically   return an answer with the corresponding stream on hold.  An SDP with   all streams "on hold" is referred to as held SDP.

      Certain third party call control scenarios do not work when an      answerer responds to held SDP with held SDP.

Rosenberg & Schulzrinne     Standards Track                    [Page 17]

RFC 3264  An Offer/Answer Model Session Description Protocol   June 2002

   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.

   RFC 2543 [10] specified that placing a user on hold was accomplished   by setting the connection address to 0.0.0.0.  Its usage for putting   a call on hold is no longer recommended, since it doesn\’t allow for   RTCP to be used with held streams, doesn\’t work with IPv6, and breaks   with connection oriented media.  However, it can be useful in an   initial offer when the offerer knows it wants to use a particular set   of media streams and formats, but doesn\’t know the addresses and   ports at the time of the offer.  Of course, when used, the port   number MUST NOT be zero, which would specify that the stream has been   disabled.  An agent MUST be capable of receiving SDP with a   connection address of 0.0.0.0, in which case it means that neither   RTP nor RTCP should be sent to the peer.

历史博文

标签：,
九月 27, 2006 at 2:19 下午 by yippee 1,222 次
Category: Dev
Tags: ,