在RFC5359中描述了SIP服务的常见的几个例子。对这些服务的概念，流程，消息进行了比较详细的介绍。近期时间比较空闲，重新温习一下，不少概念澄清了。将这个RFC简单介绍一下。
第一个服务的例子就是callhold（呼叫保持）。流程如下图所示：
Alice Proxy Bob
| INVITE F1 | |
|--------------->| |
| | INVITE F2 |
|(100 Trying) F3 |------------->|
|<---------------| |
| |180 Ringing F4|
| 180 Ringing F5 |<-------------|
|<---------------| |
| | 200 OK F6 |
| 200 OK F7 |<-------------|
|<---------------| |
| ACK F8 | |
|--------------->| ACK F9 |
| |------------->|
| Both way RTP Established |
|<=============================>|
| |INVITE(hold) F10
|INVITE(hold) F11|<-------------|
|<---------------| |
| 200 OK F12 | |
|--------------->| 200 OK F13 |
| |------------->|
| | ACK F14 |
| ACK F15 |<-------------|
|<---------------| |
| No RTP Sent! |
| | INVITE F16 |
| INVITE F17 |<-------------|
|<---------------| |
| 200 OK F18 | |
|--------------->| 200 OK F19 |
| |------------->|
| | ACK F20 |
| ACK F21 |<-------------|
|<---------------| |
| Both way RTP Established |
|<=============================>|
| BYE F22 | |
|--------------->| BYE F23 |
| |------------->|
| | 200 OK F24 |
| 200 OK F25 |<-------------|
|<---------------| |
图1 Call Hold示例
在上面的这个场景中，Alice呼叫Bob，呼叫建立后，Bob将这个呼叫保持，过段时间后，又取消了呼叫保持，恢复了正常通话。然后Alice结束了通话。
在上面的这个过程中，可以看到hold的动作是由Bob向proxy发送了一个比较特殊的Invite。这个invite之所以特殊，就是特殊在invite消息中的sdp部分。不同的UA发送的这个sdp参数不一样。比较早期的UA实现是将sdp的c地址改为0.0.0.0。现在比较流行的做法是如果会话中有媒体流的话，将sdp的a改为a=inactive；如果是没有媒体流的话，将a属性改为a=sendonly。
下面是对F10的介绍：
F10 INVITE Bob -> Proxy 1
INVITE sips:alice@client.atlanta.example.com SIP/2.0
Via: SIP/2.0/TLS client.biloxi.example.com:5061
;branch=z9hG4bKnashds7
Route:
Max-Forwards: 70
From: Bob ;tag=314159
To: Alice ;tag=1234567
Call-ID: 12345601@atlanta.example.com
CSeq: 1 INVITE
Contact: ;+sip.rendering="no"
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Content-Type: application/sdp
Content-Length: ...
v=0
o=bob 2890844527 2890844528 IN IP4 client.biloxi.example.com
s=
c=IN IP4 client.biloxi.example.com
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=sendonly
这里是将a改为sendonly。
在后续的200OK中，Alice的UA发送的200OK中，sdp部分会将a改为a=recvonly.此后Alice和Bob之间就没有了媒体流的交互了。
恢复正常通话：
Bob需要再发送一个特殊的invite来取消callhold。在这个invite中sdp部分，会将a属性重新修改为sendrecv，下面例子中是将a改为了rtpmap:0 PCMU/8000。
F16 INVITE Bob -> Proxy 1
INVITE sips:alice@client.atlanta.example.com SIP/2.0
Via: SIP/2.0/TLS client.biloxi.example.com:5061
;branch=z9hG4bKnashds73
Route:
Max-Forwards: 70
From: Bob ;tag=314159
To: Alice ;tag=1234567
Call-ID: 12345601@atlanta.example.com
CSeq: 2 INVITE
Contact:
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Content-Type: application/sdp
Content-Length: ...
v=0
o=bob 2890844527 2890844529 IN IP4 client.biloxi.example.com
s=
c=IN IP4 client.biloxi.example.com
t=0 0 m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000
在Alice随后的200OK中，a属性也是rtpmap:0 PCMU/8000了。这样Alice和Bob就进行了双向的RTP交互了。恢复了正常的通话。
