SIP route与record_route SIP路由机制

最新推荐文章于 2024-02-08 17:00:17 发布
转载 最新推荐文章于 2024-02-08 17:00:17 发布 · 2.7k 阅读 · 3

本文深入探讨SIP协议中的两种路由场景：严格路由与松散路由，详细解析其工作原理及区别，通过实例演示请求与响应消息如何在SIP网络中进行路由。

SIP中存在两种路由场景：
1，请求消息的路由
2，响应消息的路由

其中，响应消息的路由非常简单，就是完全依靠Via来完成的，具体参考RFC3261。
下面我们只谈SIP请求消息的路由。

首先我们要搞清楚什么是严格路由和松散路由。

严格路由（Strict Routing）：
可以理解为比较“死板”的理由机制，这种路由机制在SIP协议的前身RFC 2534中定义，其机制非常简单。
要求接收到的消息的request-URI必须是自己的URI，然后它会把第一个Route头域“弹”出来，并把其中的URI作为新的request-RUI，然后把该消息路由给该URI。

松散路由（Louse Routing，lr）：
该路由机制较为灵活，也是SIP路由机制的灵魂所在，在SIP根本大典RFC 3261中定义。
下面介绍一下一个松散路由的Proxy的路由决策过程：

1，Proxy首先会检查消息的request-URI是不是自己属于自己所负责的域。如果是，它就会通过定位服务将该地址“翻译”成具体的联系地址并以此替换掉原来的request-URI；否则，它不会动request-URI。

2，Proxy检查第一个Route头域中的URI是不是自己的，如果是，则移除之。

3，前面两项都是准备工作，下面该进行真正的路由了。如果还有Route头域，则Proxy会把消息路由给该头域中的URI，否则就路由给request-URI。至于如何从下一跳URI确定出IP地址，端口以及传输协议那是另外一回事了。

对于前面的3条规则，我们可以简单总结为一句话：Route的优先级高于request-URI的。

好，了解了两种路由机制，我们再来了解一下Route和Record-Route。
如果说Via是为了给一个请求消息的响应消息留后路，那么Record-Route就是为了给该请求消息之后的请求消息留后路。
【说明】一个SIP消息每经过一个Proxy（包括主叫），都会被加上一个Via头域，当消息到达被叫后，Via头域就记录了请求消息经过的完整路径。被
叫将这些Via头域原样copy到响应消息中（包括各Via的参数，以及各Via的顺序），然后下发给第一个Via中的URI，每个Proxy转发响应消
息前都会把第一个Via（也就是它自己添加的Via）删除，然后将消息转发给新的第一个Via中的URI，直到消息到达主叫。

而在一个请求消息的传输过程中，Proxy也可能（纯粹自愿，如果它希望还能接收到本次会话的后续请求消息的话）会添加一个Record-Route头
域，这样当消息到达被叫后里面就有会有0个或若干个Record-Route头域。被叫会将这些Record-Route头域并入路由集，并并入自己的路
由集，随后被叫在发送请求消息时就会使用该路由集构造一系列Route头域，以便对消息进行路由。
然后，被叫会像上面对待Via头域一样，将Record-Route头域全部原样copy到响应消息中返回给主叫。
主叫收到响应消息后也会将这些Record-Route头域并入路由集，只是它会将其反序。该会话中的后续请求消息的Route头域就会通过路由集构造。
【注意】Record-Route头域不用来路由，而只是起到传递信息的作用。
Record-Route头域不是路由集的唯一来源，路由集还可以通过手工配置等方式得到。

只是描述还是比较抽象，下面就以RFC 3261中的两个实例来解释一下。

路由示例1：

场景：
两个UE间有两个Proxy，U1 -> P1 -> P2 -> U2，并且两个Proxy都乐意添加Record-Route头域。

消息流：
【说明】由于我们在此只关心SIP路由机制，因此下面消息中跟路由机制无关的头域都省略了。

U1发出一个INVITE请求给P1（P1是U1的外拨代理服务器）：
   INVITE sip:callee@domain.com SIP/2.0
   Contact: sip:caller@u1.example.com

P1不负责域domain.com，消息中也没有Route头域，因此通过DNS查询得到负责该域的Proxy的地址并且把消息转发过去。这里P1在转发
前就添加了一个Record-Route头域，里面有一个lr参数，说明P1是一个松散路由器，遵循RFC3261中的路由机制。
   INVITE sip:callee@domain.com SIP/2.0
   Contact: sip:caller@u1.example.com
   Record-Route: <sip:p1.example.com;lr>
P2负责域domain.com，因此它通过定位服务得到[email]callee@domain.com[/email]
对应的设备地址是[email]callee@u2.domain.com[/email]
，因此用新的URI重写request-URI。消息中没有Route头域，因此它就把该消息转发给request-URI中的URI，转发前它也增加了
一个Record-Route头域，并且也有lr参数。
   INVITE sip:callee@u2.domain.com SIP/2.0
   Contact: sip:caller@u1.example.com
   Record-Route: <sip:p2.domain.com;lr>
   Record-Route: <sip:p1.example.com;lr>
位于u2.domain.com的被叫收到了该INVITE消息，并且返回一个200 OK响应。其中就包括了INVITE中的Record-Route头域。
   SIP/2.0 200 OK
   Contact: sip:callee@u2.domain.com
   Record-Route: <sip:p2.domain.com;lr>
   Record-Route: <sip:p1.example.com;lr>
被叫此时也就有了自己的路由集：
   (<sip:p2.domain.com;lr>,<sip:p1.example.com;lr>)

并且它本次会话的远端目的地址设置为INVITE中Contact中的URI：
[email]caller@u1.example.com[/email]，此后被叫在该会话中的请求消息就发到这个URI。同样，被叫在200
OK响应中也携带了自己的联系地址，主叫收到该响应消息后也会把本次会话的远端目的地址设置为：
[email]callee@u2.domain.com[/email]，此后主机在该会话中的请求消息就发到这个URI。
同样，主叫也有了自己的路由集，只是跟被叫的是反序的：
   (<sip:p1.example.com;lr>,<sip:p2.domain.com;lr>)

通话完毕后，我们架设主叫先挂机，则主叫发出BYE请求：
   BYE sip:callee@u2.domain.com SIP/2.0
   Route: <sip:p1.example.com;lr>,<sip:p2.domain.com;lr>
可以看到，BYE的Route头域正是主机的路由集构造来的。
由于p1在第一个Route中，因此BYE首先发给P1。

P1收到该消息后，发现request-URI中的URI不属于自己负责的域，而消息有Route头域，并且第一个Route头域中的URI正是自己，因此删除之，并且把消息转发给新的第一个Route头域中的URI，也就是P2：
   BYE sip:callee@u2.domain.com SIP/2.0
   Route: <sip:p2.domain.com;lr>
P2收到该消息后，发现request-URI中的URI不属于自己负责的域（P2负责的是domain.com，而不是u2.domain.com），
第一个Route头域中的URI正是自己，因此删除之，此时已经没有Route头域了，因此就转发给了request-URI中的URI。

被叫就会收到BYE消息：
   BYE sip:callee@u2.domain.com SIP/2.0

路由示例2：
如果说上面的示例主要关注的是路由流程，那么本示例关注的则是严格路由与松散路由的区别。

场景：
U1->P1->P2->P3->P4->U2
其中，P3是严格路由的，其余Proxy都是松散路由的，并且4个Proxy都很乐意增加Record-Route头域。

消息流：
我们直接给出了到达被叫的INVITE消息：
   INVITE sip:callee@u2.domain.com SIP/2.0
   Contact: sip:caller@u1.example.com
   Record-Route: <sip:p4.domain.com;lr>
   Record-Route: <sip:p3.middle.com>
   Record-Route: <sip:p2.example.com;lr>
   Record-Route: <sip:p1.example.com;lr>

这中间的其他消息我们就不过问了，直接看一下被叫最后发出的BYE消息大概是什么样子：
   BYE sip:caller@u1.example.com SIP/2.0
   Route: <sip:p4.domain.com;lr>
   Route: <sip:p3.middle.com>
   Route: <sip:p2.example.com;lr>
   Route: <sip:p1.example.com;lr>

因为P4在第一个Route里，因此被叫将BYE消息发给了P4。

P4收到该消息后，发现自己不负责域u1.example.com，但是第一个Route头域中的URI正是自己，因此删除之。P4还发现新的第一个
Route头域中的URI是一个严格路由器，因此它把request-URI中的URI添加到最后一个Route的位置，并且将第一个Route“弹出”
并且覆盖原来的request-URI。然后将消息转发给当前的request-URI，也就是P3。
   BYE sip:p3.middle.com SIP/2.0
   Route: <sip:p2.example.com;lr>
   Route: <sip:p1.example.com;lr>
   Route: <sip:caller@u1.example.com>

P3收到该消息后，直接把消息作出如下变换并且发给P2：
   BYE sip:p2.example.com;lr SIP/2.0
   Route: <sip:p1.example.com;lr>
   Route: <sip:caller@u1.example.com>
P2收到该消息后，发现消息中的request-URI是自己的，因此在进一步处理先首先对消息做如下变换：
   BYE sip:caller@u1.example.com SIP/2.0
   Route: <sip:p1.example.com;lr>
然后，P2发现自己不负责域u1.example.com，第一个Route中的URI也不是自己的，因此将消息转发给该URI，也就是P1。

P1收到该消息后，发现自己不负责域u1.example.com，但是第一个Route头域中的URI正是自己，因此删除之。消息变成下面的样子：
   BYE sip:caller@u1.example.com SIP/2.0
既然Route头域已经是空，因此P1把消息发给u1.example.com。

SIP消息路由机制
RTC hacker
12-08 2145
<br />一：请求路由<br />    松散路由(Loose Router)和严格路由(Strict Router)，这是SIP协议（RFC3261）中的一个非常重要的概念。<br />    在SIP消息的Route头域或Record-route头域中，携带的域值是SIP　URI或SIPS　URI，如果这个URI带有”lr”属性值，那么，就表示URI的地址所标识的SIP　PROXY是松散路由的，否则，是严格路由的。如Record-Route: <sip:p1.example.com;lr>、Route
国标Gb28181里Contact和Route的使用
wwyyxx26的专栏
12-07 5257
国标Gb28181是基于Sip协议的，因此对Contact和Route的使用，也可以说是Sip里Contact和Route的使用。Contact和Route则是sip协议里的头字段。 现在，在使用国标Gb28181来做项目时，经常会遇到这种情况，国标的下级是在内网里，上级在公网上。如果不做处理，下级到上级会经过nat协议的转换从而导致上级向下级发送请求时(比如获取目录请求)不能到达
SIP route与 record_route /SIP路由机制解析
热门推荐
stefmoon的专栏
04-27 1万+
转自：http://hi.baidu.com/ferrior/blog/item/74714709613285cf3bc7633b.htmlSIP路由机制解析(zz)2007-03-06 15:46  在前面已经陆续介绍了SIP重要头域、注册流程、会话流程等SIP相关知识，现在再来介绍一下SIP中的路由机制。总的来说，SIP中存在两种路由场景：1，请求消息的路由
SIP松散路由机制漫谈（以OpenSIPS为例）
5D金豆豆的博客
05-14 856
严格路由定义 松散路由定义 实例讲解
精选资源
sip协议中文版.pdf_sip协议中文_
10-01
**五、SIP路由机制** SIP请求的路由通常由"Via"头字段管理，它记录了请求经过的每个节点。"Record-Route"头用于指示请求必须经过的路径，而"Route"头用于指定请求的预期目标。 **六、SIP安全与QoS** SIP协议本身...
#ifndef _SIP_PROTOCOL_H #define _SIP_PROTOCOL_H #include "common/sip_common.h" #ifdef SIP_USE_TCP #define SIP_TRANSPORT "TCP" #else #define SIP_TRANSPORT "UDP" #endif /* 字符数组长度宏定义 */ #define SIP_URI_SCHEME_LEN 8 #define SIP_URI_USER_LEN 32 #define SIP_URI_HOST_LEN 32 #define SIP_URI_PARAM_LEN 32 #define SIP_VIA_PROTOCOL_LEN 16 #define SIP_VIA_TRANSPORT_LEN 8 #define SIP_VIA_HOST_LEN 64 #define SIP_VIA_BRANCH_LEN 32 #define SIP_VIA_RECEIVED_LEN 32 #define AUTH_REALM_LEN 64 #define AUTH_NONCE_LEN 64 #define AUTH_ALGORITHM_LEN 32 #define AUTH_QOP_LEN 32 #define AUTH_OPAQUE_LEN 64 #define AUTH_RESPONSE_LEN 33 #define SIP_HEADER_CALLID_LEN 64 #define SIP_HEADER_CONTENT_TYPE_LEN 64 #define SIP_HEADER_CONTACT_LEN 64 #define SIP_HEADER_USER_AGENT_LEN 64 #define SIP_BODY_TYPE_LEN 32 #define SIP_REASON_PHRASE_LEN 32 #define SIP_CONFIG_USER_AGENT_LEN 32 #define SIP_BRANCH_LEN 32 #define SIP_TAG_LEN 32 #define SIP_CALLID_LEN 64 #define T1_TIMEOUT 500 #define T2_TIMEOUT 64 * T1_TIMEOUT #define T4_TIMEOUT 5000 /* SIP方法定义 */ typedef enum sip_method { SIP_METHOD_INVITE = 0, SIP_METHOD_ACK, SIP_METHOD_BYE, SIP_METHOD_CANCEL, SIP_METHOD_REGISTER, SIP_METHOD_OPTIONS, SIP_METHOD_MAX } sip_method; /* SIP响应状态码 */ /* SIP响应状态码枚举 (RFC 3261及相关扩展) */ typedef enum sip_status_code { /* 1xx 临时响应 */ SIP_100_TRYING = 100, SIP_180_RINGING = 180, SIP_181_CALL_IS_BEING_FORWARDED = 181, SIP_182_QUEUED = 182, SIP_183_SESSION_PROGRESS = 183, /* 2xx 成功响应 */ SIP_200_OK = 200, SIP_202_ACCEPTED = 202, // RFC3265 /* 3xx 重定向响应 */ SIP_300_MULTIPLE_CHOICES = 300, SIP_301_MOVED_PERMANENTLY = 301, SIP_302_MOVED_TEMPORARILY = 302, SIP_305_USE_PROXY = 305, SIP_380_ALTERNATIVE_SERVICE = 380, /* 4xx 客户端错误 */ SIP_400_BAD_REQUEST = 400, SIP_401_UNAUTHORIZED = 401, SIP_402_PAYMENT_REQUIRED = 402, SIP_403_FORBIDDEN = 403, SIP_404_NOT_FOUND = 404, SIP_405_METHOD_NOT_ALLOWED = 405, SIP_406_NOT_ACCEPTABLE = 406, SIP_407_PROXY_AUTHENTICATION_REQUIRED = 407, SIP_408_REQUEST_TIMEOUT = 408, SIP_410_GONE = 410, SIP_413_REQUEST_ENTITY_TOO_LARGE = 413, SIP_414_REQUEST_URI_TOO_LONG = 414, SIP_415_UNSUPPORTED_MEDIA_TYPE = 415, SIP_416_UNSUPPORTED_URI_SCHEME = 416, SIP_420_BAD_EXTENSION = 420, SIP_421_EXTENSION_REQUIRED = 421, SIP_423_INTERVAL_TOO_BRIEF = 423, SIP_480_TEMPORARILY_UNAVAILABLE = 480, SIP_481_CALL_TRANSACTION_DOES_NOT_EXIST = 481, SIP_482_LOOP_DETECTED = 482, SIP_483_TOO_MANY_HOPS = 483, SIP_484_ADDRESS_INCOMPLETE = 484, SIP_485_AMBIGUOUS = 485, SIP_486_BUSY_HERE = 486, SIP_487_REQUEST_TERMINATED = 487, SIP_488_NOT_ACCEPTABLE_HERE = 488, SIP_489_BAD_EVENT = 489, // RFC3265 SIP_491_REQUEST_PENDING = 491, SIP_493_UNDECIPHERABLE = 493, /* 5xx 服务器错误 */ SIP_500_SERVER_INTERNAL_ERROR = 500, SIP_501_NOT_IMPLEMENTED = 501, SIP_502_BAD_GATEWAY = 502, SIP_503_SERVICE_UNAVAILABLE = 503, SIP_504_SERVER_TIME_OUT = 504, SIP_505_VERSION_NOT_SUPPORTED = 505, SIP_513_MESSAGE_TOO_LARGE = 513, /* 6xx 全局错误 */ SIP_600_BUSY_EVERYWHERE = 600, SIP_603_DECLINE = 603, SIP_604_DOES_NOT_EXIST_ANYWHERE = 604, SIP_606_NOT_ACCEPTABLE = 606 } sip_status_code; /* SIP事务状态定义 */ typedef enum sip_transaction_state { Calling = 0, Trying, Proceeding, Completed, Terminated } sip_transaction_state; /* SIP URI结构 */ typedef struct sip_uri { char scheme[SIP_URI_SCHEME_LEN]; /* "sip" or "sips" */ char user[SIP_URI_USER_LEN]; /* username */ char host[SIP_URI_HOST_LEN]; /* domain or IP */ U16 port; /* port number */ char parameters[SIP_URI_PARAM_LEN]; /* URI parameters */ } sip_uri; /* SIP Via头结构 */ typedef struct sip_via { char protocol[SIP_VIA_PROTOCOL_LEN]; /* "SIP/2.0" */ char transport[SIP_VIA_TRANSPORT_LEN]; /* "UDP", "TCP" */ char host[SIP_VIA_HOST_LEN]; /* sent-by host */ U16 port; /* sent-by port */ char branch[SIP_VIA_BRANCH_LEN]; /* branch parameter */ char received[SIP_VIA_RECEIVED_LEN]; /* received parameter */ U16 rport; /* rport parameter */ } sip_via; /* 认证信息结构体 */ typedef struct auth_info_t { char realm[AUTH_REALM_LEN]; char nonce[AUTH_NONCE_LEN]; char algorithm[AUTH_ALGORITHM_LEN]; char qop[AUTH_QOP_LEN]; char opaque[AUTH_OPAQUE_LEN]; int stale; char response[AUTH_RESPONSE_LEN]; } auth_info_t; /* SIP消息头结构 */ typedef struct sip_headers { struct sip_uri from; /* From header */ struct sip_uri to; /* To header */ struct sip_via via; /* Via header */ char call_id[SIP_HEADER_CALLID_LEN]; /* Call-ID header */ U32 cseq; /* CSeq number */ enum sip_method cseq_method; /* CSeq method */ U8 max_forwards; /* Max-Forwards header */ char content_type[SIP_HEADER_CONTENT_TYPE_LEN]; /* Content-Type */ char contact[SIP_HEADER_CONTACT_LEN]; /* Contact header */ U32 content_length; /* Content-Length header */ U32 Expires; char user_agent[SIP_HEADER_USER_AGENT_LEN]; /* User-Agent */ auth_info_t auth; } sip_headers; /* SIP消息体结构 */ typedef struct sip_body { char *content; /* Message body content */ U32 length; /* Message body length */ char type[SIP_BODY_TYPE_LEN]; /* Content type */ } sip_body; /* SIP消息结构 */ typedef struct sip_message { U8 type; /* 0:request, 1:response */ enum sip_method method; /* Method (requests) */ U16 status_code; /* Status code (responses) */ char reason_phrase[SIP_REASON_PHRASE_LEN]; /* Reason phrase */ struct sip_uri request_uri; /* Request-URI */ struct sip_headers headers; /* SIP headers */ struct sip_body body; /* Message body */ struct sockaddr_in source; /* Message source */ struct list_head list; /* List head for queue */ } sip_message; /* SIP事务信息 */ typedef struct sip_transaction { char branch[SIP_BRANCH_LEN]; /* Transaction branch */ enum sip_method method; /* Transaction method */ int timeout_idx; struct sip_message *request; /* Original request */ struct sip_message *last_response; /* Last response */ sip_transaction_state state; /*0:off, 1:on*/ } sip_transaction; /* SIP对话信息 */ typedef struct sip_dialog { char remote_tag[SIP_URI_PARAM_LEN]; /* From */ char local_tag[SIP_URI_PARAM_LEN]; /* To */ char call_id[SIP_HEADER_CALLID_LEN]; } sip_dialog; /* 协议栈配置 */ typedef struct sip_protocol_config { char user_agent[SIP_CONFIG_USER_AGENT_LEN]; U8 max_forwards; U32 t1_timeout; /* T1 timer (RTT) */ U32 t2_timeout; /* T2 timer (64*T1) */ U32 t4_timeout; /* T4 timer (5000ms) */ } sip_protocol_config; /* SIP协议栈接口 */ /** * @brief SIP消息解析 * * @param[out] msg 解析出的sip消息 * * @param[in] data sip消息原始数据 * * @param[in] length 数据长度 * * @return 错误码 * */ int sip_message_parse(sip_message *msg, const char *data, U32 length); /** * @brief SIP消息解析 * * @param[in] msg sip消息结构体 * * @param[out] buffer 构造出的sip消息 * * @param[in] size 报文大小 * * @return 错误码 * */ int sip_message_build(sip_message *msg, char *buffer, U32 size); void sip_message_free(sip_message *msg); /** * @brief SIP消息拷贝 * * @param[in] src 源消息指针 * * @return sip消息指针 * */ sip_message *sip_message_copy(sip_message *src); int sip_uri_parse(sip_uri *uri, const char *uri_str); int sip_uri_build(sip_uri *uri, char *buffer, U32 size); /** * @brief 创建SIP事务 * * @param[ori_req] 源请求 * * @return SIP事务指针 * */ sip_transaction *sip_transaction_create(sip_message *ori_req, void *timeout_hanler); void sip_transaction_terminate(sip_transaction *trans); void sip_transaction_free(sip_transaction *trans); sip_dialog *sip_dialog_create(char *to_tag, char *from_tag, char *call_id); void sip_dialog_free(sip_dialog *dialog); const char *sip_method_to_string(enum sip_method method); sip_method sip_string_to_method(const char *method_str); const char *sip_status_to_reason(U16 status_code); void sip_generate_branch(char *branch, U32 size); void sip_generate_tag(char *tag, U32 size); void sip_generate_call_id(char *buf, int len); #endif /* _SIP_PROTOCOL_H */ 帮我改进一下对话和事务的结构体，使逻辑更合理
最新发布
11-14
2. 如何根据Record-Route头构建对话的路由集（route set）？ 3. 在对话中处理BYE请求时，如何确保使用正确的路由集？ 4. 事务超时处理中，T1、T2、T4定时器分别对应哪些具体场景？ 5. 为什么REGISTER事务不会创建...
SIP协议详解：Route头字段与会话管理
在SIP（会话初始化协议）中，Route头字段扮演着关键角色，它涉及到网络通信中的路由机制。SIP是一种用于建立、修改和终止多媒体通信会话的协议，广泛应用于VoIP（Voice over IP）电话系统。根据描述，我们来详细探讨...
SIP: From ,Contact, Via 和 Record-Route/Route head字段详解
wwyyxx26的专栏
07-08 4746
http://bbs.csc-china.com.cn/forum.php?mod=viewthread&tid=17606 From:  如果一个SIP消息中没有Contact或者Record-Route头域，那么callee就会根据From头域产生后续的Request。比如：如果 Alice打一个电话给Bob，From头域的内容是 From:Alice。那么Bob打给Ali
RFC3261: SIP:20.30 Record-Route
aggs1990的专栏
02-08 142
Record-Route报头字段由代理插入请求中，以强制对话中的未来请求通过代理路由。​第16.12.1节描述了其与路由字段一起使用的示例。
SIP的路由机制
cp62的专栏
12-17 1051
在前面已经陆续介绍了SIP重要头域、注册流程、会话流程等SIP相关知识，现在再来介绍一下SIP中的路由机制。 总的来说，SIP中存在两种路由场景：1，请求消息的路由2，响应消息的路由 其中，响应消息的路由非常简单，就是完全依靠Via来完成的，具体请见我关于RFC3261中会话流程的分析。下面我们只谈SIP请求消息的路由。 首先我们要搞清楚什么是严格路由和松散路由
sip里的via,record_route和route
Blackbaby
06-13 997
      The Via header field indicates the transport used for the transaction  and identifies the location where the response is to be sent       The Route header field is used to force routing for a r...
sip中Via、Record-Route和Route set的区别和联系
06-07 8406
via中的记录是为了让请求的应答能够原路返回，而Record-Route的作用是告诉发送方按照invite建立好的这条通道来发送后续的请求。要彻底明白三者之间的区别，首先得特别明确的知道三者的定义是什么？（见rfc3261）via:The Via header field indicates the path taken by the request so far and indicates th...
SIP消息路由
学习是为了探索这个世界的本质
12-26 1473
本文通过一个完整的SIP呼叫实例解释SIP头部的一些常见字段，在对这些字段的解释的同时也阐述了SIP消息的路由过程。下图是呼叫的消息流示意图和所有的消息头部(因为SDP和消息路由无关，故在此省略)：                      atlanta.com  . . . biloxi.com                  .      proxy              prox
SIP中From ,Contact, Via 和 Record-Route/Route
weixin_30613727的博客
02-19 467
转载:http://eadgar.blogbus.com/logs/374635.html 注意:以下内容适用于SIP消息中,在具体的应用环境中,例如IMS,每个消息头都有其他独特的意义,但不会和以下的内容产生具体的冲突. From: 如果一个SIP消息中没有Contact或者Record-Route头域，那么callee就会根据From头域产生后续的Request。比如：如果Alic...
【SIP协议路由机制】
qq_25137439的博客
05-05 2139
SIP的路由机制是SIP协议的灵魂，通过此路由机制，才使得一个呼叫请求在VOIP网络的众多Proxy节点中，找到正确的目的端。在了解SIP路由机制前，我们先弄清以下几个感念。 1 与路由的相关概念 请求路由（Route）与响应路由（via） 按场景来分可以把SIP路由分为请求路由与响应路由两种路由。 请求路由（Route）：发起端到目的端的路径。比如发起端发起INVITE呼叫请求消息所走过的路径或者BYE结束一个呼叫的请求消息所走过的路径就为请求路由。 请求路由的生成是通过头域Record-Routes
SIP route fileds: Form, Contact, Record-Route, Via, Route Headers ...
有朋自远方来...
07-13 4472
SIP fields for route
sip中Via、Record-Route和Route set的区别和联系&SIP路由机制解析(zz)
zhangbaoin的专栏
11-28 2227
<link rel="stylesheet" href="https://csdnimg.cn/release/blogv2/dist/mdeditor/css/editerView/ck_htmledit_views-b5506197d8.css"> <div id="content_views" class="markdown_views prism-atom-one-dark"> <svg xmlns="ht...
评论 2
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值