虽然中美经常闹摩擦，我们一直致力于求同存异。但我们的通信技术确是最公平的，它是无国界、无差异的。感谢在全球化以及互联网文化高度发达的今天，我们可以和全球的通信技术爱好者一起探讨我们热爱的通信技术，我们的探讨不会基于中国标准或是美国标准，它们都是3GPP（或其他规范组织）标准。

秉承此精神，我将开始尝试翻译一些国外的技术达人或牛人的技术博客，取其精华为我们所用。

本文翻译自国外的一篇技术博客，原文地址是：

https://andrewjprokop.wordpress.com/2015/02/10/understanding-sip-re-invite/

以下是主要原文和译文：

以下是主要原文和译文：

Let’s Get Started

You need to know that re-INVITE is not a new message. A re-INVITE looks just like any other INVITE. In fact, if you saw a re-INVITE out of the context of its call flow, you might not be able to tell it from an INVITE used to create a new session.  You will see most of the same headers and a similar message body.  The one exception is that you will see a tag on the To header.  This clues you in that something is different.

你需要知道re-INVITE并不是一个新的消息。一个re-INVITE看起来和其他任何一个INVITE消息并没有什么两样。实际上，如果你在呼叫流程上下文之外看到了一个新的re-INVITE消息，你可能并不能用该INVITE消息来创建一个新的会话。你会看到它们有相同的SIP头域以及相似的消息体。唯一的不同是你发现To头域中的tag值不同。这条线索，让你发现了它们实际上是有所不同的。

If you aren’t familiar with SIP tags, please see Let’s Play (SIP) Tag.

如果你对SIP tag不太了解，可以参考我的这篇文章“玩转SIP Tag”。

A Re-INVITE, it comes after a session has been established. This means that it will apply to an existing INVITE after a final response has been received and an ACK has been sent.

一个Re-INVITE，会紧跟在会话创建之后出现。这意味着Re-INVITE出现的时机是跟随一个已有的INVITE，并且是在这个INVITE的最终响应（200 OK）已经收到、ACK已经发送之后。

You send an UPDATE message prior to session establishment, but that’s an article for another day.

A re-INVITE will have the same Call-ID and From tag as the INVITE it is modifying. It can change every other header as well as the message body, but those two things tell the SIP stack that this is not a new INVITE.

你可以在会话建立之前发送一个UPDATE消息，但这是我们改天需要谈论的话题。（备注：update可以在第一个invite被应答之前发送（即收到invite的200ok之前）。也就是说，update可以被用来控制早期媒体。而re-invite只能在第一个invite被应答之后发送（即在通话已经建立之后）。）

The most common use for re-INVITE is call hold. The party putting the call on hold sends a re-INVITE with SDP indicating that media will no longer be sent. That same party will take the call off hold by sending another re-INVITE with SDP indicating that media transmission will resume.

To demonstrate this, I placed a call to my desk telephone, answered it, started up the Avaya traceSM utility, put the call on hold, stopped traceSM, and then took a few screen shots of the resultant call flow.

Re-INVITE最典型的一个应用是呼叫保持。通话一方将呼叫设置为保持状态，会发送一个带有SDP消息体的re-INVITE来声明不再发送媒体流。同样，该用户还可以发送一个带有SDP消息体的re-INVITE消息体来声明继续发送之前挂起的媒体流，从而达到取消呼叫保持的目的。为了证明这个说法，我尝试去呼叫我的桌面电话，并接听，启动Avaya traceSM实用工具进行追踪，然后将呼叫设置为保持状态，并停止traceSM的追踪，然后我就得到了以下的一些截图来论证我的观点。

Here is the complete flow from the point of me pressing hold.

以下是在我按下保持按钮时的完整过程。

At a high level, you should see the following:

从全局来看，你可以发现以下事情：

1. From my desk phone, I put the call on hold. My phone sends a re-INVITE to Session Manager.

   在我的桌面电话上，我将呼叫设置为保持。我的电话发送re-INVITE消息给会话管理器。

2. Session Manager challenges the re-INVITE with a 407 response.

   会话管理器返回了407响应。

3. My telephone resends the re-INVITE to Session Manger with the proper credentials.

   我的电话重发re-INVITE给会话管理器，并带上正确的安全相关参数。

4. Session Manager sends the re-INVITE to Communication Manager.

   会话管理器发送re-INVITE给通信管理器。

5. Communication Manager sends a PUBLISH to Session Manager indicating that the call is on hold.

   通信管理器发送PUBLISH消息给会话管理器，用于指明呼叫已经处于保持状态。

6. Communication sends the re-INVITE back to Session Manager.

   通信管理器回送re-INVTE给会话管理器。

7. Session Manager sends a NOTIFY to the telephone indicating that the call is on hold.

   会话管理器发送NOTIFY消息给电话，指明该呼叫已经处于保持状态。

8. Session Manager sends the re-INVITE to the other party in the call.

   会话管理器发送re-INVTE给本次呼叫中的其他参与者。

9. The other party answers the re-INVITE with a 200 OK.

   其他参与者发送200 OK响应，作为对re-INVITE的应答。

From the standpoint of this article, the re-INVITE at step 3 is the most important message in the flow.

从本文的角度看，第3步中的re-INVITE是本流程中最重要的消息。

I want you to notice a few things.

我希望你能注意到以下一些微小的细节：

• Although I didn’t show you the INVITE that created the call, trust me when I say that it has the same Call-ID and From tag as the re-INVITE.  We are not creating a new call.  We are simply modifying an existing one.

  尽管在图中并没有呈现出INVITE消息是如何创建这次呼叫的，但当我说它和re-INVITE消息具有相同的Call-ID和From tag的时候，请你相信我。我们不是创建一个新的呼叫。我们只是简单的对一个已经存在的呼叫进行修改。

• If this were an INVITE for a new session, there would be no To tag.  The presence of a To tag tells you this is a re-INVITE.

  如果这是一个为创建新会话而发送的INVITE消息，那么它不应该有To tag。换句话说，To tag的存在，就告诉你这是一个re-INVTE。

• An Avaya SIP telephone adds a Reason header that states this call is going on hold. This is not part of the SIP specification and is not required for hold. An Avaya system may use this for something, but it has no bearing on whether the call is going on hold or not.

  Avaya的SIP电话加入了Reason头域来声明呼叫即将处于保持状态。这并不是SIP规范的一部分，并且在保持流程中也并未要求。Avaya系统使用该头域用于一些其他的目的，但并不是用于承担呼叫是否保持的结果。

• The SDP in this INVITE looks pretty typical with one exception. Note the line that saysa=sendonly. If you were to look at the original INVITE, this single attribute line would be the only difference. It’s a big difference, though. This stops the flow of media between the telephones. This attribute is the most important part of the re-INVITE.

  该INVITE的SDP消息体部分看起来有一个非常明显的例外。请注意a=sendonly这一行。如果你和初始的INVITE消息做过比对的话，你会发现仅仅只有这一行是不同的---尽管这是一个巨大的差别。它将阻止电话之间的媒体流的传送（因为已经呼叫保持了）。这是一个在re-INVITE消息中非常重要的属性。

• I have also seen hold accomplished by setting the SDP connection line to a null IP address —c=0.0.0.0.  However, the above attribute approach is the correct way to indicate hold.  The null IP address approach should be avoided.

  同时我还发现，我可以将SDP连接行设置为一个空的IP地址----c=0.0.0.0。然后，使用a=sendonly的方法才是声明呼叫保持的正确做法。空IP方法来实现呼叫保持应该是要避免的。

For grins, let’s take a look at the PUBLISH and NOTIFY messages used to inform the telephone that the call is on hold. Like the Reason header above, this is not necessary for the hold operation itself. Instead, it can be used for lamp state or aggregated presence.

接着，我们发现PUBLISH和NOTIFY消息用于通知电话，呼叫处于保持状态。就像之前的Reason头域，这并不是呼叫保持操作本身所必须的。相反，它可以用于状态灯或者聚合呈现功能（Avaya的产品功能，不是重点。Hi，作者，还是不要跑题了哈）。

The last thing I want you to look at is the re-INVITE that is sent to the other party.  It will look a whole lot like the original re-INVITE, but I included it for the sake of completeness.

最后我希望你能看一眼发送给其他（呼叫）参与者的re-INVITE。它看起来和初始的re-INVITE非常像。放在这里的目的，是为了保持一个介绍的完整性。