SIP Via header

SIP ADVENTURES

作者原文发布在：https://andrewjprokop.wordpress.com/2014/03/06/understanding-the-sip-via-header/

Every once in a while I feel the need to get away from SIP the architecture and write about SIP the protocol (which is a little bit like the department of redundancy department – Session Initiation Protocol Protocol). Yes, I adore all those servers and services, but it’s the bits and bytes that attracted me to SIP in the first place.

Waylon Jennings said it best in his song, “Luckenbach, Texas.”

Maybe it’s time we got back to the basics of love.

以上是作者的闲聊

---

Today, I want to share the love and write about an extremely important, but sometimes misunderstood SIP header.

翻译：今天我想写一个非常重要的但常常被人误解的SIP header

When a user agent client (UAC) creates a SIP request, it must insert a Via header into that request. The Via header identifies the protocol name (SIP), protocol version (2.0), transport type (e.g. UDP or TCP), IP address of the UAC, and the protocol port (typically 5060) used for the request. This information allows the recipient of the request (a user agent server) to return SIP responses to the correct device. For example, if my SIP soft-phone were to send an INVITE request, it would contain a Via similar to the following.

翻译：当UAC创建一个SIP request，它就必然会插入Via header到request。Via header用于识别协议名（SIP），协议版本（2.0），传输层类型（e.g. UDP 或TCP），UAC的ip地址和用于request的端口号（通常是5060）。这些信息可以让request的接收者（UAS）将SIP responses发送给正确的设备。例如，如果我的软电话发送了一个INVITE request，它将包含一个类似下面的Via

乱弹：这里注意一下UAC就是发起request的一方，UAS就是回复response的一方

Via: SIP/2.0/UDP 10.11.228.67:5060

If I were operating in a point-to-point configuration, the soft-phone that received the INVITE would inspect the Via header to determine the location of my PC. It would then use that information to return a “100 Trying” response. Of course, unless I am in a lab environment, I never use SIP in a point-to-point fashion. Here at work, there are all sorts of SIP components between my soft-phone and the soft-phone I am calling. There is a Session Manager, Communication Manager, and perhaps a Session Border Controller between us. Thankfully, via headers are not reserved for endpoints. Every SIP entity uses them.

翻译：如果我在操作一个点到点的配置，那么一个收到INVITE的软电话会检查Via header来判定我PC的位置。软电话将稍后使用via中的信息来返回“100 Trying”response。当然，除非我在一个实验室环境，我绝不会以点对点的方式使用SIP。我列出了在实际工作中，两台正在通话的软电话之间有哦哪些SIP组件，有Session Manager（会话管理）、Communication Manager或者还有一个Session Border Controller（会话边际控制器也就是常说的SBC）。幸运的是，Via headers不会被endpoints所保留。每个SIP实体都使用它们

The rules for processing Via headers are very simple. Every UAC must add its own Via header before sending a SIP request. If there is already a Via header in the message, the UAC adds the new one at the top of the list before sending it to the next hop.

翻译：处理Via headers的规则十分的简单。每个UAC必然要在发送sip request前添加自己的Via header。如果在消息里面已经有一条Via header了，那么UAC在发送给下一个hop前会新增一个via header在列表的最上面

++乱弹：那就是说有部分消息里会有多个via headers++

Remember that INVITE I sent in my example? When it ends up on the called party’s device, it might contain several Via headers. When the called party is ready to send the “100 Trying,” it simply removes the top Via header and sends the response to the indicated party. In my work configuration, that top Via would most likely identify a Session Manager. However, if the soft client was a remote user, it would be my company’s SBC. It doesn’t matter, though. Whoever receives the response will remove the top Via header and send it to the next hop. This keeps happening until the Trying message lands on my PC.

翻译：还记得上文我的INVITE的例子吗？当它最终出现在被叫方的设备上时，它会包含数个Via header。当被叫方准备发送“100 Trying”时，它会去掉最上层的Via header并且发送response给主叫方。在我的工作配置中，最上层的Via最可能是一个Session Manager，然而如果软客户端是一个远端用户，那它有可能是我公司的SBC。尽管这并没有什么关系。无论是谁收到了response都会去除最上层Via header并发送到下一个hop。这个动作会持续进行直到Trying信息到达了我的PC

This Via stacking allows a SIP request to pass through any number of intermediaries and every recipient of that message will know exactly how to pass back any subsequent responses.

翻译：这个Via堆允许一个SIP request通过任何数量的中介机构并且每个request的接收者将会知道如何准确的回传response

Ah, but there’s more.To keep things simple I failed to mention something important about Via headers. Along with the protocol and IP information, every Via header contains a “branch” parameter. Here is that Via again with a branch parameter I pulled from a Wireshark trace.

翻译：啊哈 但是还有更多。为了简单起见，我没有提到关于Via header的一些重要内容，以及协议和IP信息，每个Via header包含一个“branch”参数。下面是一条我从wireshark中取出的branch参数

Via: SIP/2.0/UDP 10.11.228.67:5060; branch=z9hG4bK10_16a83292baa1de54e0b7843_I

The branch parameter must be unique across space and time for all requests sent by a user agent. The exceptions to this rule are CANCEL and ACK for non-2xx responses. A CANCEL will have the same branch parameter as the request it cancels. An ACK for a non-2xx response will have the same branch parameter as the INVITE whose response it acknowledges.

翻译：对于一个user agent（UA）所发送的所有request中的branch参数在空间和时间上必须是唯一的。对于这个规则的例外就是对于non-2XX系列response的request（CANCEL和ACK）。CANCEL会和它所取消的request拥有相同的branch参数。对于某个non-2xx的response的ACK（ACK是request）将会与它确认响应的INVITE有相同的branch参数

The uniqueness of the branch header is used to facilitate its use as a transaction ID. A SIP transaction is a message exchange between two user agents that starts with a request and ends with a final response. For a simple call, the INVITE through final response is one transaction, the ACK is another transaction, and the Bye through the 200 OK is yet another transaction. All these transactions combine to make a single dialog.

翻译:branch header的惟一性用于方便将其用作事务ID。SIP事务（SIP transaction）是两个用户代理之间的消息交换，以请求开始，以最终响应结束。对于一通简单的呼叫，INVITE与其response是一个事务（transaction），ACK是另一个事务，Bye和其200OK的确认也是一个事务，所有的这些事务组成了一次对话。

乱弹：每个request与自己的response的branch相同

If you crave more knowledge about SIP message uniqueness, please see my blog, Let’s Play (SIP) Tag.

翻译：如果您需要更多关于SIP消息惟一性的知识，请参阅我的博客，让我们来玩(SIP)标记。

The branch parameter always begins with the same string of seven characters — “z9hG4bK.” This requirement was added to identify that the branch was created in accordance with RFC 3261 and not the older RFC 2543 which did not require global uniqueness.

翻译：branch参数总是以相同的七个字符开始“z9hG4bK”。添加这个需求是为了识别分支是根据RFC 3261创建的，而不是根据不需要全局唯一性的旧RFC 2543创建的。

Okay, that’s it. I got my protocol fix for the day. I hope you are as thrilled as I am.

翻译：好的，就是这样。我今天把我的协议修复好了，我希望你们能像我一样激动高兴