SIP消息路由

最新推荐文章于 2024-07-16 14:19:04 发布
原创 最新推荐文章于 2024-07-16 14:19:04 发布 · 4.2k 阅读 · 2 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#session #c #branch #server

本文通过一个完整的SIP呼叫实例解释SIP头部的一些常见字段，在对这些字段的解释的同时也阐述了SIP消息的路由过程。下图是呼叫的消息流示意图和所有的消息头部(因为SDP和消息路由无关，故在此省略)：

                     atlanta.com  . . . biloxi.com

                 .      proxy              proxy     .

               .                                       .

       Alice's  . . . . . . . . . . . . . . . . . . . .  Bob's

      softphone                                        SIP Phone

         |                |                |                |

         |    INVITE F1   |                |                |

         |--------------->|    INVITE F2   |                |

         |  100 Trying F3 |--------------->|    INVITE F4   |

         |<---------------|  100 Trying F5 |--------------->|

         |                |<-------------- | 180 Ringing F6 |

         |                | 180 Ringing F7 |<---------------|

         | 180 Ringing F8 |<---------------|     200 OK F9  |

         |<---------------|    200 OK F10  |<---------------|

         |    200 OK F11  |<---------------|                |

         |<---------------|                |                |

         |                       ACK F12                    |

         |------------------------------------------------->|

         |                   Media Session                  |

         |<================================================>|

         |                       BYE F13                    |

         |<-------------------------------------------------|

         |                     200 OK F14                   |

         |------------------------------------------------->|

         |                                                  |

 

F1 INVITE Alice -> atlanta.com proxy

 

INVITE sip:bob@biloxi.com SIP/2.0

Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8

Max-Forwards: 70

To: Bob <sip:bob@biloxi.com>

From: Alice <sip:alice@atlanta.com>;tag=1928301774

Call-ID: a84b4c76e66710

CSeq: 314159 INVITE

Contact: <sip:alice@pc33.atlanta.com>

Content-Type: application/sdp

Content-Length: 142

F2 100 Trying atlanta.com proxy -> Alice

 

SIP/2.0 100 Trying

Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8

 ;received=192.0.2.1

To: Bob <sip:bob@biloxi.com>

From: Alice <sip:alice@atlanta.com>;tag=1928301774

Call-ID: a84b4c76e66710

CSeq: 314159 INVITE

Content-Length: 0

F3 INVITE atlanta.com proxy -> biloxi.com proxy

 

INVITE sip:bob@biloxi.com SIP/2.0

Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1

Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8

 ;received=192.0.2.1

Max-Forwards: 69

To: Bob <sip:bob@biloxi.com>

From: Alice <sip:alice@atlanta.com>;tag=1928301774

Call-ID: a84b4c76e66710

CSeq: 314159 INVITE

Contact: <sip:alice@pc33.atlanta.com>

Content-Type: application/sdp

Content-Length: 142

F4 100 Trying biloxi.com proxy -> atlanta.com proxy

 

SIP/2.0 100 Trying

Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1

 ;received=192.0.2.2

Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8

 ;received=192.0.2.1

To: Bob <sip:bob@biloxi.com>

From: Alice <sip:alice@atlanta.com>;tag=1928301774

Call-ID: a84b4c76e66710

CSeq: 314159 INVITE

Content-Length: 0

F5 INVITE biloxi.com proxy -> Bob

 

INVITE sip:bob@192.0.2.4 SIP/2.0

Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1

Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1

 ;received=192.0.2.2

Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8

 ;received=192.0.2.1

Max-Forwards: 68

To: Bob <sip:bob@biloxi.com>

From: Alice <sip:alice@atlanta.com>;tag=1928301774

Call-ID: a84b4c76e66710

CSeq: 314159 INVITE

Contact: <sip:alice@pc33.atlanta.com>

Content-Type: application/sdp

Content-Length: 142

F6 180 Ringing Bob -> biloxi.com proxy

 

SIP/2.0 180 Ringing

Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1

 ;received=192.0.2.3

Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1

 ;received=192.0.2.2

Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8

 ;received=192.0.2.1

To: Bob <sip:bob@biloxi.com>;tag=a6c85cf

From: Alice <sip:alice@atlanta.com>;tag=1928301774

Call-ID: a84b4c76e66710

Contact: <sip:bob@192.0.2.4>

CSeq: 314159 INVITE

Content-Length: 0

F7 180 Ringing biloxi.com proxy -> atlanta.com proxy

 

SIP/2.0 180 Ringing

Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1

 ;received=192.0.2.2

Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8

 ;received=192.0.2.1

To: Bob <sip:bob@biloxi.com>;tag=a6c85cf

From: Alice <sip:alice@atlanta.com>;tag=1928301774

Call-ID: a84b4c76e66710

Contact: <sip:bob@192.0.2.4>

CSeq: 314159 INVITE

Content-Length: 0

F8 180 Ringing atlanta.com proxy -> Alice

 

SIP/2.0 180 Ringing

Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8

 ;received=192.0.2.1

To: Bob <sip:bob@biloxi.com>;tag=a6c85cf

From: Alice <sip:alice@atlanta.com>;tag=1928301774

Call-ID: a84b4c76e66710

Contact: <sip:bob@192.0.2.4>

CSeq: 314159 INVITE

Content-Length: 0

F9 200 OK Bob -> biloxi.com proxy

 

SIP/2.0 200 OK

Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1

 ;received=192.0.2.3

Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1

 ;received=192.0.2.2

Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8

 ;received=192.0.2.1

To: Bob <sip:bob@biloxi.com>;tag=a6c85cf

From: Alice <sip:alice@atlanta.com>;tag=1928301774

Call-ID: a84b4c76e66710

CSeq: 314159 INVITE

Contact: <sip:bob@192.0.2.4>

Content-Type: application/sdp

Content-Length: 131

F10 200 OK biloxi.com proxy -> atlanta.com proxy

 

SIP/2.0 200 OK

Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1

 ;received=192.0.2.2

Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8

 ;received=192.0.2.1

To: Bob <sip:bob@biloxi.com>;tag=a6c85cf

From: Alice <sip:alice@atlanta.com>;tag=1928301774

Call-ID: a84b4c76e66710

CSeq: 314159 INVITE

Contact: <sip:bob@192.0.2.4>

Content-Type: application/sdp

Content-Length: 131

F11 200 OK atlanta.com proxy -> Alice

 

SIP/2.0 200 OK

Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8

 ;received=192.0.2.1

To: Bob <sip:bob@biloxi.com>;tag=a6c85cf

From: Alice <sip:alice@atlanta.com>;tag=1928301774

Call-ID: a84b4c76e66710

CSeq: 314159 INVITE

Contact: <sip:bob@192.0.2.4>

Content-Type: application/sdp

Content-Length: 131

F12 ACK Alice -> Bob

 

ACK sip:bob@192.0.2.4 SIP/2.0

Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds9

Max-Forwards: 70

To: Bob <sip:bob@biloxi.com>;tag=a6c85cf

From: Alice <sip:alice@atlanta.com>;tag=1928301774

Call-ID: a84b4c76e66710

CSeq: 314159 ACK

Content-Length: 0

F13 BYE Bob -> Alice

 

BYE sip:alice@pc33.atlanta.com SIP/2.0

Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnashds10

Max-Forwards: 70

From: Bob <sip:bob@biloxi.com>;tag=a6c85cf

To: Alice <sip:alice@atlanta.com>;tag=1928301774

Call-ID: a84b4c76e66710

CSeq: 231 BYE

Content-Length: 0

F14 200 OK Alice -> Bob

 

SIP/2.0 200 OK

Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnashds10

From: Bob <sip:bob@biloxi.com>;tag=a6c85cf

To: Alice <sip:alice@atlanta.com>;tag=1928301774

Call-ID: a84b4c76e66710

CSeq: 231 BYE

Content-Length: 0

1. SIP消息头部主要字段：

·         Request-URI：Request消息的第一行中method后面紧跟的部分就是Request-URI(本例中的sip:bob@biloxi.com)。该值在消息经过Proxy之后就有可能发生变化，变成消息路径中Next Hop的URI。

·         To：包含的是最终用户的Public address，消息无论被Proxy多少次该值都不会改变。当最终用户开始回应第一个Response消息时(比如本例中的180 Ring)会在To中加上本地唯一的一个tag值。

·         From：包含Request消息发起者的URI，也不会被Proxy改变；在生成Reqeust消息时就会在后面加上一个本地唯一的tag值。

·         Call-Id：用来标识一个唯一的Session，整个Session期间的所有消息的Session-Id都是相同的。

·         Max-Forwards：消息可被转发的最大次数，每经过一个Proxy，该值就会被减一。

·         CSeq：该属性由一个整数和一个method名字两部分组成；整数部分的作用是用来对同一个Session中的Request消息进行排序的；从第一个Invite消息发出后，随后的所有Request消息(ACK和Cancel除外)中的CSeq值都依次加一。比如Alice与Bob的通话过程中Alice想修改会话的一些属性，于是她便发起第二个Invite消息，这个Invite消息中的CSeq就需要加一；在比如Alice给Bob发送了一个Invite消息，而Bob发回的200 OK发生延时，于是Alice又发送第二个Invite消息，此时对第一个Invite消息的200 OK到达，Alice根据200 OK中的CSeq便可以知道这是对第一个Invite消息的应答。Request消息Cancel和Ack中的CSeq和与之对应的Invite消息中的CSeq值是一致的。

·         Via：该属性记录了消息的路由。Request消息被生成的时候只有一个Via，那就是本地的URI，此后消息每经过一个Proxy，Proxy都会在消息中插入一个Via记录下自己的URI。当最终用户发挥Response消息时，会从Request消息中拷贝所有的Via，然后按照反序进行路由，每经过一个Proxy，该Proxy就会将包含自己URI的Via删除，这样当Response消息最终到达Request发起端的时候就只剩下一个Via了。

·         Contact：该属性包含了用户可以被直接找到的一个URI，Request发起方会在Request消息中加入该值，接收方会在第一个Response(该例中的180 Ring)中加入该值。利用这个URI，此后再发起Request消息时就直接发送到对方了，而无需经过Proxy，比如本例中的F12 ACK消息，由于之前通过交换Contact值，Alice知道如何能直接找到Bob，于是在第一行的SIP-URI中填上Bob所提供的Contact值，将ACK消息直接发送给Bob而无需经过Proxy，注意To中仍然是原先的值。

·         Route and Record-Route：这两个属性都是有Proxy加入的；上面提到Contact属性可以让随后的Reqeust消息绕过Proxy而直接发给最终用户。有时候处于安全或者其他方面的原因，Proxy希望所有的消息都必须经过Proxy，那么这时候Proxy就需要在经过它的第一个Request消息中插入该属性记录自己的URI，这样此后的Request消息就必须按照该属性中指定的路径路由。

 

2. 对以上几个头部属性简单概括一下：

·         SIP-URI是一个Hop-to-Hop的属性，所以有可能被Proxy改变；

·         From和To属性在消息的路由过程中一直保持不变；它们在Request消息中确定，此后对端发来的所有Response消息的From和To都是原样拷贝Request消息中的From和To；

·         Via是用来帮助Response消息进行路由的，Contact是用来供随后的Request消息进行路由的。

参考资料：

1.  “RFC 3261”- Section 4，Section 12，Section 17，Section 24；

2.  “SIP Demystified”- Chapter 4， Chapter 5；

SIP 消息的路由和 7 个相关的 Header && IMS-HSS 中的透明数据及非透明数据(VoNR、VoLTE均用)
原来45的博客
08-06 669
SIP 消息的路由和 7 个相关的 Header && IMS-HSS 中的透明数据及非透明数据(VoNR、VoLTE均用)
SIP协议消息
king_weng的博客
03-09 2640
1、SIP消息 SIP 协议是一个基于文本的协议，使用 UTF-8 字符集（RFC2279[7]）。一个 SIP 消息既可以是一个从客户端到服务器端的请求，也可以是一个从服务器端到客户端的一个应答。 消息类型都由一个起始行，一个或者多个包头域，一个可选的消息中文组成。 起始行、每一个包头行，空行、都必须由回车换行组成（CRLF）。即使消息正文没有，也必须有一个空行跟随。 2、请求 SIP 请求是根据起始行中的 Request-Lin...
SIP消息路由机制
RTC hacker
12-08 2141
<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
SIP协议详解(中文)-5
demon_evil的专栏
02-15 7988
事务分为客户端和服务端两方。客户端的事务是客户端事务，服务器端的事务就是服务端事务。客户端事务发出请求，并且服务端事务送回应答。客户端和服务端事务都是逻辑上的概念，他们可以被无数部件所包含。特别是，他们在UA中和有状态的proxy服务器中存在。以第四节的例子来说明。在这个例子中，UAC执行客户端事务，它的外发proxy执行服务端事务。外发proxy同时也执行客户端事务，把请求发送到一个那发prox
【SIP基础】SIP协议中请求与响应消息都有的头域
VVSIP官网博客
09-14 4675
AcceptAccept 头域用于指示在响应中能够接收的媒体的类型。 该字段使用互联网常用”type/sub-type “格式来描述。 缺省值为application/sdp。 媒体类型的列表可以使用q值参数进行设置。 Accept-Encoding该头头域用于指定消息体的编码方案。 编码可以被用来在单个UDP数据报内确保带有大消息体的SIP消息的组合。 使用q值参数可以设置首选项。如果没有可以接受
路由有关的SIP消息头的简单小结
dingpeng1978的专栏-凤舞九天
07-23 6397
一、SIP协议中定义的路由相关字段1. Via：当UAC发起一个SIP Request消息时，消息经过的每一跳（包含发起方）都会在SIP消息中增加一个Via字段，内容为自己的地址信息，表示此消息通过此地址发往下一跳。为什么要增加Via字段来记录Request消息经过的地址呢？实际上这个地址信息将被作为Request消息的Response消息的路由，Response将根据Via字段中记录的地址逐级返
SIP消息头域的说明
firstime_tzjz的专栏
06-13 1342
http://www.cnblogs.com/stanleyhe/archive/2011/12/04/2275186.html
JAIN-SIP消息路由优化：路由机制与性能提升技巧
![JAIN-SIP消息路由优化：路由机制与...文章首先介绍了SIP协议的工作原理及其在路由中的作用，然后详细讨论了代理、重定向和注册服务器路由策略，以及SIP消息的转发过程。接着，文章分析了影响路由性能的因素，包括网络
精选资源
SIP消息总体描述.doc
05-24
SIP消息分为两类：请求消息（Request）和响应消息（Response）。请求消息从UAC发送到UAS，响应消息则反之。每个SIP消息包含起始行（Start-line）、标题头（Message header）、空行（CRLF）和可选的消息体（Message ...
sip消息头功能详解
12-22
主要介绍了sip header的主要功能作用，很好的ppt
sip协议中文（1）
清明宁静
09-08 3513
1、SIP协议介绍Internet的许多应用都需要建立和管理一个会话，会话在这里的含义是在参与者之间的数据的交换。由于考虑到参与者的实际情况，这些应用的实现往往是很复杂的：参与者可能是在代理间移动，他们可能可以有多个名字，他们中间的通讯可能是基于不同的媒介（比如文本，多媒体，视频，音频等）－有时候是多种媒介一起交互。人们创造了无数种通讯协议应用于实时的多媒体会话数据比如声音，影像，或者文本。本SI
【转载】SIP穿越NAT的rport机制（Via中的rport 和 received 参数）
Rookie_Manito的博客
01-20 4235
【转载】SIP穿越NAT的rport机制 2014年03月04日 15:07:00 irwin_chen 阅读数：8948 调试asterisk时发现从公网发来的INVITE的响应都不能正常返回到客户端，抓包发现响应都发到via头域中写明的那个port上去了，而实际asterisk是从NAT转换后的地址和端口接收的INVITE请求。最终发现需要在via中加入rport字段，使得asterisk使用rport机制路由响应。 具体的RFC文档参见RFC3581。 RPORT机制： 客户端需要在top most
SIP消息结构详解
弘毅_hao的博客
07-16 3102
sip消息结构详解
sip响应路由规则,rport 机制
ttomqq的专栏
10-14 7615
sip服务器收到一个请求，路由到下一跳的时候，会在请求的第一条via后面添加收到这个请求的ip和端口信息，然后再添加一条自己的via。这样，当这个请求的响应路由到sip服务器的时候，sip服务器就可以根据via来决定下一跳的ip和端口。     sip服务器191收到请求                     INVITE sip:13751812778@183.232.75.191
SIP协议的传输层原理&报文解析(解读rfc3581)(待排版)
weixin_30245867的博客
07-24 1342
关于rfc3581/rport参数的阐述 一：简述 一般情况下，服务器在接收到request后，应答发向哪里呢？服务器在计算回应应答的算法是一种混合模式，具体说来是这样的： 1，IP：从哪里接收到的就会给哪里，即ip包上记录的源地址 2，port：根据sip报文的头解析出来， 对于处理被NAT包裹的环境中的客户端，请求是可以发出去的，但是应答却无法穿透NAT，就要借助rport这个位于v...
理解SIP对话
冰的城
09-11 1万+
Dialog是SIP中的一个关键概念。根据RFC3261，会话是两个UA之间持续一段时间的点到点的SIP连接，即是记录两者已经连接上的相关内容实体，方便在对话中请求进行识别和处理。     对话都是有对话ID来标识的，包括Call-ID，一个本地标签（From-tag）和一个远端标签（To-tag）。即是说三者确定了某个对话的存在。     对话中还包括一些对话中的后续消息所需的状态，
sip协议详解(三)
热门推荐
I_O_fly的博客
10-29 1万+
21应答代码 应答码是包含了，并且扩展了HTTP/1.1应答码。并不是所有的HTTP/1.1应答码都适当应用，只有在这里指出的是适当的。其他HTTP/1.1应答码不应当使用。并且，SIP也定义了新的应答码系列，6xx。 21.1临时应答1xx 临时应答，也就是消息性质的应答，标志了对方服务器正在处理请求，并且还没有决定最后的应答。如果服务器处理请求需要花200ms以上才能产生终结应...
sip中继路由和外线路由的区别
最新发布
11-21
<think> SIP中继路由和外线路由是VoIP通信中常见的两种路由方式，主要区别在于应用场景和路由目标： 1. **SIP中继路由（Trunk Routing）**： - 用于连接企业PBX与运营商或ITSP（互联网电话服务提供商） - 实现企业内部分机通过运营商的SIP中继拨打外部电话 - 通常基于被叫号码模式（如国际/国内前缀）选择不同中继 2. **外线路由（Outbound Routing）**： - 更广义的概念，指从本地网络向外部网络发送呼叫的路由 - 包含SIP中继路由，但也可包括其他出站路径（如PSTN网关、其他PBX等） 关键差异点： | 特性 | SIP中继路由 | 外线路由 | |--------------|-----------------------------|-----------------------------| | **物理媒介** | 纯IP（SIP协议） | 可能包含模拟/数字线路 | | **连接对象** | 运营商/ITSP | 运营商、其他分支机构、PSTN等 | | **配置目标** | 优化运营商链路使用 | 实现最经济/可靠的出局路径 | | **典型应用** | 企业拨打外线电话 | 包括中继在内的所有出局呼叫 | 实际系统中，SIP中继路由通常是外线路由的子集。例如： - 外线路由表可能包含： 1. 国际长途 -> 选择廉价SIP中继A 2. 本地固话 -> 选择传统PSTN网关 3. 紧急呼叫 -> 强制走PSTN（法规要求） 技术实现差异： - **SIP中继路由**依赖注册状态和SDP协商，通常需处理NAT穿越 - **外线路由**可能涉及协议转换（如SIP到ISDN） 总结：SIP中继是特定技术（SIP）的实现方式，外线路由是功能层面的概念。 </think> ### SIP中继路由与外线路由的区别 在SIP通信系统中，**中继路由（Trunk Routing）** 和 **外线路由（Outbound Routing）** 是两种不同的路由机制，主要区别如下： | **维度** | **SIP中继路由 (Trunk Routing)** | **外线路由 (Outbound Routing)** | |------------------|---------------------------------------------------|-----------------------------------------------| | **定义** | 运营商之间的SIP主干链路连接 | 本地网络向外部网络发起的呼叫路由 | | **主要目的** | 实现不同运营商/服务商之间的互联互通 | 处理用户设备向外部号码发起的呼叫 | | **路由方向** | 横向（运营商↔运营商） | 纵向（用户终端→外部网络） | | **典型应用场景** | 跨运营商呼叫、企业多线路切换、灾备路由 | 用户拨打外线电话、国际长途、特服号码 | | **技术特点** | 基于SIP URI路由<br>支持负载均衡<br>需要SIP协议协商 | 基于号码分析<br>支持呼叫权限控制<br>需要NAT穿越 | | **配置要素** | SIP对端IP/域名<br>认证凭证<br>容量限制 | 拨号规则<br>费率表<br>呼叫限制策略 | #### 具体说明： 1. **中继路由**： - 本质是**网络与网络之间的连接通道** - 例如：企业PBX通过SIP中继连接到电信运营商 - 关键技术：SIP TLS加密、SRTP媒体流、负载均衡算法 ```mermaid graph LR A[企业PBX] -- SIP中继 --> B[运营商A] A -- SIP中继 --> C[运营商B] ``` 2. **外线路由**： - 本质是**呼叫出站规则引擎** - 例如：员工拨打"0086..."自动选择最便宜运营商 - 关键技术：号码规范化、LCR（最低成本路由）、呼叫限制 ```mermaid graph TB D[分机1001] --> E{路由决策} E -->|国内长途| F[运营商A] E -->|国际长途| G[运营商B] ``` #### 典型配置差异： **中继路由配置示例**： ```ini [Trunk_OperatorA] type = sip host = sip.operatorA.com port = 5060 auth_user = company123 auth_pass = ******** max_calls = 30 ``` **外线路由配置示例**： ```ini [Outbound_Rule1] pattern = ^00\d+ # 国际号码 trunk = Trunk_OperatorB cost = 0.05/min # 费率 block = 001881 # 禁止拨打特定国家 ``` ---
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值