B2BUA

Implementing Class-5 Telephony features in SIP

SIP User Agents (UA) are "smart" entities that hold call state and can implement a wide range of telephony features end-to-end without the need for a centralized control entity such as PBX. Nevertheless(tuy nhiên) some features do require a centralized entity such as a PBX or Class-5 switch and these types of entities may increase interoperability.

Can a SIP Proxy do the job?

A SIP Proxy is an intermediary (trung gian) entity that mainly plays the role of routing. It decides about call routing and forking(rẽ nhánh) and also may apply policy and authorize certain calls to certain users. A SIP Proxy may not alter (thay đổi) SIP messages and change message headers or body (except routing related headers such as Via). Additionally a SIP Proxy may not initiate disconnection of a call or creation of a call between 2 UAs.

SIP Back-To-Back User Agent Figure 1: Basic B2BUA functionality 

A SIP Back-To-Back User Agent (B2BUA) takes what is traditionally a SIP end-to-end call and mediates it through a central SIP server. The B2BUA enables service providers to manage and track a call from beginning to end, integrate and offer new value added features, and bring Class-5 type functionality to IP networks.

The SIP standard briefly defines a B2BUA as a logical entity that receives requests as a User Agent Server (UAS) and in order to respond to them, it acts as a User Agent Client (UAC) and generates requests. Additionally it maintains dialog state and must participate

in all of the requests sent on the dialogs it has established. The standard defines it as a concatenation of a UAC and UAS and therefore doesn't provide additional definition for this entity.

Issues in B2BUA functionality

The B2BUA functionality breaks one of SIP's advantages of end-to-end service because it prevents a UA to directly contact the destination UA by mediating(gián tiếp) the call between them. This prevents direct implementation of features such as REFER and exchange of secured bodies using S/MIME. Therefore a B2BUA should be used only in cases where such mediation is required/desired, usually when central call control is required.

Development with B2BUA

From the application perspective(bối cảnh), the B2BUA enables deployment of voice and multimedia telecommunications equipment that seamlessly interwork with other communications networks and deliver centralized call and feature management. Products that benefit from SIP B2BUA include softswitches, application servers, SIP-based IP-PBXs, conference bridges, firewall/NAT traversal applications, 3G servers, call center applications, media servers and voice mail applications.

With the B2BUA module, the SIP server becomes an active participant in the call from beginning to end as all signaling messages pass through and are processed by the B2BUA at all times. A B2BUA maintains call state and actively participates in sending requests and responses for dialogs in which it is involved.

This B2BUA functionality provides major new applications including:

centralized call management interworking with alternative networks SIP--based VoIP interworking between LAN and WAN management and monitoring(giám sát) of the entire call state cloaking of endpoint location

One of the most common uses of a SIP B2BUA is for development of Class-5 Switches, PBXs and Call Center applications. The B2BUA provides centralized call management with its active participation in a call. This feature gives the application tight system/call management. This opens the door for a wide range of features a B2BUA can implement:

Automatic Disconnection of call - A Pre Paid application requires the ability of warning the caller prior to exhaustion of credit and disconnection of call when credit is exhausted. A B2BUA can manipulate call signaling and SDP in order to play a warning from a media server, this can be done for example by opening an additional leg of the call to the media server and sending re-INVITE message to the caller UA with proper SDP making sure only the caller will hear the warning message.

Automatic connection of two party call - A B2BUA may act as what the standard defines as Third Party Call Control (3PCC) and connect a call between 2 UAs. The draft draft-ietf-sipping-3pcc-xx.txt (xx stands for version number that may change, current version at time of this publication is 04, please see IETF WEB site for latest version - www.ietf.org) defines different possible scenarios, 2 of them (1 & 4) are the most recommended ones where 1 should be used when the destination is an automatic machine such as voice mail or media server and scenario 4 is recommended for other cases such as calling someone's SIP phone. This type of functionality has many implementations one example can be in a call center where calls can be done according to a certain data base or queue of customers who requested a call at a certain time. This will require the application to detect a free agent and connect a call between the agent and the customer. This will require the B2BUA to act as the controller, initiate messages and manipulate SDP. In some cases it will be required that a supervisor will join the call in listen only or whisper mode (to instruct the agent) and therefore B2BUA will need tight control over call signaling and participate in entire call duration.

Figure 2: Third Party Call Control

Figure 2 may seem complicated but this message flow is required to avoid a timeout problem. Theoretically it is possible to follow scenario 1 defined in the 3PCC draft (scenario not illustrated in this article) and send to UA1 INVITE with no SDP that will require it to answer with an SDP offer that will be placed in the INVITE sent to UA2. In this case the SDP of UA2 will be sent to UA1 only in the ACK and therefore the ACK of the first INVITE to UA1 would need to be delayed until UA2 answers the INVITE with

200 OK and SDP answer. Since UA2 can be any type of UA the answer may be delayed and as a result of that UA1 will retransmit the 200 OK. UA1 will continue to retransmit the 200 OK for T1*64 seconds and if by then the ACK will not arrive the call will fail. The scenario presented here (numbered 4 in the 3PCC draft) avoids this possibility. The conclusion is that these 2 scenarios should be used with caution and in any case a B2BUA is the natural entity to implement the controller functionality.

Call Transfer - SIP defines the method REFER and other headers for the implementation of Call Transfer. Call Transfer functionality can be implemented end-to-end without any centralized intervention. There are reasons (some technical and some financial) to implement this functionality in a centralized entity such as Class-5 switch/PBX. For example SIP UAs may support different versions of the REFER draft or one may not support REFER at all, this will cause interoperability problems. A centralized entity that implements this will enhance interoperability in such a case.

Interworking with alternative networks

The B2BUA can be used for implementation of interworking applications for example between H.323 and SIP. Since the B2BUA is acting as a UA in the call and is actively processing signaling and message bodies throughout the duration of the call it may have one leg in the SIP network and another leg in a different VoIP network such as H.323. This feature is important for service providers with next generation networks who currently have to support both SIP and H.323 entities.

SIP--based VoIP interworking between LAN and WAN

FW and NAT traversal is yet another cavity of VoIP deployment. Different solutions are introduces in the market and standard bodies. For example Interactive Connectivity Establishment (ICE) that defines a methodology that uses existing protocols such as Simple Traversal of UDP through NAT (STUN), Traversal Using Relay NAT (TURN) and Real Specific IP (RSIP) for NAT traversal. Another common solution is a Protocol aware FW that does stateful inspection of packets and maintains call state for allowing VoIP traffic traversal. A third option that some criticize but yet is deployed and provides a quite simple solution is an Application Server. This entity typically resides in the DMZ (Dematerialized Zone) and bridges between public to private network addresses by changing VoIP message contents and by routing RTP traffic via an RTP Proxy.

In order to implement such functionality in SIP A B2BUA is required because it needs to be an active participant in the call and have the ability to modify SIP message headers and SDP (Session Description Protocol) body content in order to switch between public and private addresses.

Management and monitoring of the entire call state

Certain applications such as billing systems require monitoring of call state and call history. This type of functionality can be implemented by both a Call Stateful Proxy and B2BUA since both hold call state. A Call Stateful Proxy may require to be on the routing path of all SIP messages related to a certain call and a B2BUA is taking an active part of the call. On the other hand a B2BUA may also manage the call and decide for example to disconnect a call that is running out of pre paid credit.

Cloaking of endpoint location.

The B2BUA by its nature allows for cloaking of endpoint location, enabling both custom anonymizing services as well as replicating circuit-switched private number telephony services. Since all signaling passes through and is processed by the B2BUA, developers can now offer applications and platforms that dynamically cloak the identification of endpoints. SIP also defines several privacy documents that allow keeping the privacy of the caller without usage of B2BUA.

Summary

As we have seen in other VoIP protocols, one of the barriers for deployment was providing basic telephony functionality such as supplementary services. Users first want the basics such as Transfer before they consider deployment of VoIP and its new exciting features. Additionally, even though a SIP UA (as in H.323) is a "smart" entity that can implement all required functionality such as Transfer and other supplementary services, service providers as well as many PBX manufacturers prefer having a centralized control server for financial and technical reasons. A centralized control entity will help bridge between different standard implementations (e.g. will enable execution of Transfer even if the transferor doesn't support REFER or different versions of REFER are supported by different UAs). Since a B2BUA provides a solution to all these challenges, I personally believe it will be an accelerator for SIP deployment. 

As the experts in voice and video over IP, RADVISION is the global technology leader in real-time IP communications for next generation networks. RADVISION products and enabling technology provide the "building blocks" needed to enable the Internet infrastructure to support real-time voice and video communications. As the technology partner of choice for both industry giants and innovative startups, RADVISION's products and technology are used by hundreds of companies vying for market position in the rapidly growing, multi-billion dollar IP telephony arena.  

Asterisk, as a server, is a SIP registrar and location server and also acts as a useragent endpoint (softphone). (Asterisk hoạt động như một Registrar Server và một Location Server và cũng hoạt động như một đầu cuối user agent).Nếu như nó quản lý và chuyển tiếp một cuộc gọi từ một SIP phone đến một SIP phone khác , thì đơn giản nó hoạt động như một User Agent để thiết lập cuộc gọi và tạo ra một cuộc gọi mớiIf it is 'controlling' or relaying a call from a SIP phone to another SIP phone, it simply

acts as an endpoint UA to the originating call leg and then creates a new call to the receiving phone. Vì thế nó ở trạng thái “giữa cuộc gọi”, duy trì trạng thái và điều khiển, và bắt cầu tùy ý giữa các thiết bị đầu cuối từ xa. Kênh thoại RTP có thể đi trực tiếp từ điện thoại này đến điện thoại kia hoặc có thể thông qua Asterisk.Therefore, it stays "in the middle of the call," maintaining state and controlling, and optionally bridging, each remote endpoint. The audio channels (RTP) may go directly from phone to phone or may go through Asterisk's media bridge. Asterisk có thể được mô tả như một B2BUA, và nó cũng được coi là một PBX.Asterisk can thus be described best as a "back-to-back user agent" (B2BUA), which is also consistent with the use of the term "PBX". Because of this architecture, fairly simple SIP functions, such as REFER (transfer) involve more aspects of the Asterisk core. On the other hand, the architecture provides additional power and flexibility, because each call leg can just as easily be replaced with a different technology channel (ZAP, H323, MGCP, etc) and, thus, Asterisk becomes a powerful media gateway.Asterisk còn được gọi là B2BUA. Điều này có nghĩa là asterisk hoạt động giống như một User Agent trong vai trò hoặc là Servver(bên nhận) hoặc là client (bên gửi). Vì thế khi điện thoại của chúng ta quay một số extension, cuộc gọi sẽ được thiết lập giữa softphone và asterisk một cách trực tiếp với nhau. Về logic, chúng ta đã xây dựng hệ thống của chúng ta sao cho Asterisk xác định rằng khi bạn muốn gọi đến một user agent khác(bị gọi), thì asterisk sẽ hoạt động như một UAC và thiết lập một kết nối đến điện thoại bị gọi. Kênh thoại giữa hai điện thoại này sẽ được kết nối thông qua Asterisk Asterisk, on the other hand, is called a Back-To-Back User Agent (B2BUA). This meansthat Asterisk acts like a user agent in either the server (receiving) or client (sending)role. So when our softphone dials an extension number, the call is set up between thesoftphone and Asterisk directly. If the logic we’ve built into Asterisk determines thatyou mean to call another user agent, then Asterisk acts as a user agent client and setsup another connection (known as a channel) to the other phone. The media betweenthe two phones then flows directly through Asterisk.‖ From the viewpoint of thephones, they are talking with Asterisk directly.;;;;;;;;;;;;;;;;;;;;;;;;;

Introduction ¶B2BUA là một thành phần dùng để điều khiển cuộc gọi SIP. Không giống như một SIP Proxy chỉ duy trì trạng thái cuộc gọi, B2BUA còn dùy trì toàn bộ trạng thái cuộc gọi và tham gia vào mọi yêu cầu của cuộc gọi. Vì thế B2BUA có thể thực hiện một số chức năng mà Proxy không thể thực hiện được, như tính chính xác cước cuộc gọi, hay lỗi định tuyến…B2BUA có chức năng thiết lập quản lý và kết thúc cuộc gọi.

Architecture ¶

B2BUA High Level Architecture ¶

B2NUA bao gồm 3 thành phần chính sau đây:

- SIP UA trả lời cuộc gọi.- Điều khiển cuộc gọi.

- SIP UA khởi tạo cuộc gọi.

Hình vẽ sau đây mô tả kiến trúc của B2BUA và các thành phần chính của nó:

Figure 1 — B2BUA High Level Architecture

Các thành phần tương tác với nhau sử dụng các sự kiện vắn tắt. Mỗi UA đại diện cho một máy trạm sẽ nhận bản tin SIP từ một đầu cuối và chuyển đổi bản tin đó thành các sự kiện dựa trên loại của bản tin và trạng thái hiện tại của các UA đó.

Control Logic hoạt động chính giữa, chuyển tiếp các sự kiện cho các UA. Dựa vào trạng thái hiện tại của nó và trạng thái của các UA, Call control logic sẽ loại bỏ một vài sự kiện, thay đổi loại sự kiện trong quá trình chuyển đổi.

The components interact with each other using abstract events. Each User Agent (UA) represents a state machine, which receives SIP messages from the endpoint and converts them into events based on the type of message and the agent’s own current state. The Call Control Logic acts as a go-between, passing events between the UAs. Depending on its own current state and the states of the UAs, the Call Control Logic could drop some events, convert even type in transition, or inject additional events. It can also remove one of the UAs and replace it with another one on different stages of the call, which allows implementing such features as failover call routing, controlled call transfer and so on.

Since the number of parameters passed by each event is well defined the B2BUA can isolate call legs from each other, allowing only controlled amount of information to pass through.

This architecture allows implementing different functionality by replacing the Call Control Logic, which consists of a small fraction of the B2BUA code. Two such implementations are described in the next section.

Typicall Call Process ¶

1. Một cuộc gọi được khởi tạo khi Answering SIP UA nhận một bản tin INVITE từ đầu cuối SIP nguồn.

1. A call is initiated when the Answering SIP UA receives an incoming INVITE message from the Originating SIP Endpoint.

2. Sau khi nhận được bản tin này, Answering SIP UA tạo bản tin Try và gửi nó qua Call Control Logic, như hình dưới đây

Figure 2 — Try Event (2) passed to Call Control Logic

Call control logic nhận được bản tin Try, nó sẽ thực thi quá trình chứng thực và cấp phép, tạo Originating SIP UA, sửa bản tin Try để cung cấp cho bất kỳ thông số của quá trình giao dịch nào. Và nó sẽ đi dọc theo tuyến đường của gói tin đến Originating SIP UA.

3. The Call Control Logic receives the Try event, performs authentication and authorization, creates the Originating SIP UA, modifies the Try event to accommodate for any parameter translation logic, and passes it along with the routing information to the Originating SIP UA (3).

4. The Originating SIP UA receives the Try event and generates INVITE message (4) as shown in the following diagram.

Figure 3 — Originating SIP UA generating INVITE Message (4)

5. After the Answering SIP endpoint receives the INVITE message, it starts ringing and sends back an 18x SIP provisional response (5).

6. The Originating SIP UA receives the message, generates a Ringing event, and passes it to the Call Control Logic (6).

7. The Call Control Logic receives the Ringing event and passes it to the Answering SIP UA (7), and in response, the Answering SIP UA sends an 18x SIP provisional response to the Originating SIP endpoint (8).

Figure 4 — Answering SIP UA sending response to Originating SIP endpoint

8. When the user at the Answering SIP endpoint picks up the phone, the endpoint generates a 200 OK SIP response and sends it back to the Originating SIP UA (9).

9. The UA generates a Connect event and passes it to the Call Control Logic (10), following which the Call Control Logic hands the event over to the Answering SIP UA (11).

10. The UA sends a 200 OK message to the Originating SIP endpoint (12). At this point, the session is established and endpoints start exchanging RTP media (13).

Figure 5 — Endpoints receiving RTP Media

11. When either party hangs up, the respective SIP endpoint generates a SIP BYE message and sends the message to the associated SIP UA (14).

12. The UA generates a Disconnect event, which propagates to the other side of the B2BUA via the Call Control Logic (15), (16) and results in a BYE message, which is sent to the other endpoint (17).

Figure 6 — BYE message sent to Originating SIP endpoint

13. The session ends.

B2BUA Implementations ¶

Simple B2BUA ¶

Description ¶

Simple B2BUA represents very basic SIP back to back user agent. It accepts incoming SIP calls on the specified IP address and for each incoming call leg establishes outgoing call leg to the pre-defined IP address. It doesn't perform any authentication or authorization for incoming calls and passes all main parameters (CLD, CLI, SDP body, Caller Name, Callee Name) from incoming call leg to outgoing call leg verbatim. The main purpose of this B2BUA is to serve as an example for building more complex call control logic.

The B2BUA requires   Python language interpreter version 2.4 or later and   Twisted framework to run.

Synopsis ¶

To invoke the B2BUA use the following command:

python b2bua_simple.py [-f] [-l local_ip] [-p local_port] [-n remote_ip]

Options enclosed in square brackets are optional. The following options are available:

-f - run in the foreground (by default B2BUA becomes daemon after invocation); -l local_ip – specific IP address for listening for incoming SIP messages at; -p local_port – specific UDP port number for listening for incoming SIP

messages at (by default the B2BUA uses port 5060); -n remote_ip - IP address of the target for the outgoing call legs.

For example, the following command will instruct B2BUA to listen for incoming SIP calls on IP address 192.168.0.15 and forward all outgoing calls to SIP endpoint with IP address of 192.168.1.25:

python b2bua_simple.py -l 192.168.0.15 -n 192.168.1.25

There are several environment variables that can be used to control how B2BUA logs its SIP-related activities:

SIPLOG_BEND – specifies which method of reporting to use. Available methods are logfile and stderr (default);

SIPLOG_LVL – specifies logging level, that is how detailed the log file should be. The following levels are available: DBUG, INFO (default), WARN, ERR, CRIT (from the most verbose to the least verbose);

SIPLOG_LOGFILE_FILE – when logfile method is selected allows specifying location of the logfile (/var/log/sip.log by default).

RADIUS B2BUA ¶

Description ¶

RADIUS B2BUA represents advanced SIP back to back user agent designed to be used with RFC2865/RFC2866-compliant RADIUS billing engines. It accepts incoming SIP calls on the specified IP address, performs authentication and authorization using RADIUS protocol and if it has been successful establishes outgoing call leg to either pre-defined IP address or address returned by the RADIUS server in a custom attribute. It also allows RADIUS server to alter number of parameters in the outgoing call leg (CLD, CLI, Caller Name, Callee Name). Once the call has been completed or has been failed it can send RADIUS accounting.

The B2BUA uses RADIUS AAA attributes as per Cisco   CDR Accounting for Cisco IOS Voice Gateways, which provides compatibility with many billing platforms. The authentication could be performed either using Cisco-compatible Remote IP method, or by using secure digest method proposed in   RADIUS Extension for Digest Authentication IEFT draft.

The B2BUA requires   Python language interpreter version 2.4 or later,   Radius Client package version 0.5.0 or later from and   Twisted framework version 2.4 or later to run.

Synopsis ¶

python b2bua_radius.py [-fDu] [–l local_ip] [-p local_port] [-P pidfile] [-L logfile] [-s static_route] [-a ip1[,..[,ipN]]] [-k 0-3] [-m max_ctime] [-A 0-2] [-r rtp_proxy_contact1] [-r rtp_proxy_contact2] … [-r rtp_proxy_contactN]

Options enclosed in square brackets are optional. The following options are available:

-f - run in the foreground (by default, B2BUA becomes the daemon after invocation)

-D - do not use secure digest authentication -u - disable (do not send) RADIUS Authentication/Authorization. If this flag is

specified, the B2BUA does not send any Authentication/Authorization requests to the RADIUS server. Unless the –a option is also specified, the B2BUA in this mode will accept incoming sessions from any IP address without any limitations. This flag depends on the –s flag, since in this case, B2BUA is not able to get routing information from the RADIUS replies.

-A 0-2 - RADIUS accounting level. Argument in the range 0-2 specifies the level as follows:

o 0 – disable (do not send) RADIUS accounting o 1 – enable sending Stop RADIUS accounting records (this mode is

default) o 2 – enable sending both Start and Stop RADIUS accounting records

-l local_ip - specific IP address to listen for incoming SIP messages -p local_port - specific UDP port number to listen for incoming SIP messages (by

default, B2BUA uses port 5060) -P pidfile - path to the pidfile, that is, the file that contains the PID of the B2BUA

(by default, B2BUA uses /var/run/b2bua.pid) -L logfile - path to the file into which B2BUA should redirect its stdout and stderr

(by default, B2BUA uses /var/log/b2bua.log) -s static_route - instead of expecting RADIUS returning routing information in

reply, use static_route as the single “static” route. Note See the section Call Routing for the exact format of the static_route parameter

-a ip1[,..[,ipN]] - accept incoming calls only from the IP addresses specified in the ip1[,..[,ipN]] list

-k 0-3 - enable keep-alives, or re-INVITE messages, which are periodically sent to both parties participating in a call in order to detect if either party goes offline. Argument in the range 0-3 specifies mode:

o 0 – keep-alives disabled (default) o 1 – enabled for answering call leg o 2 – enabled for originate call leg o 3 – enabled for both call legs

-m max_ctime - limit maximum duration of all calls to max_ctime seconds -r rtp_proxy_contact - force media for all calls to go through RTP Proxy media

relay specified by the rtp_proxy_contact parameter. The rtp_proxy_contact can either be the path to the local unix-domain socket at which the RTP Proxy listens

for commands, or the address of the remote RTP Proxy in the format udp:hostname[:port]

-F pt1[,...[,ptN]] - list of numeric RTP payload types (  RFC3551 )that should only be allowed in the SDP offer of INVITE that the B2BUA sends to the egress call leg. Essentially this means that the B2BUA won't pass any payload types not in this list preventing answering party from using them. In the case when ingress INVITE doesn't have any payload types from this list in the SDP offer the request would be rejected with 488 Not Acceptable Here response

-R radconf_path - path to radiusclient.conf -h header1[,...[,headerN]] - list of SIP header field names that the B2BUA should

pass verbatim from ingress to egress call leg -c cmd_path - path to the control socket.

If the port is not specified, a default port value (22222) is used. It is possible to specify the –r option multiple times, in which case, B2BUA will select a particular RTP Proxy randomly for each call, effectively distributing the load evenly among all of them. In addition, the B2BUA periodically tests for and keeps track of the accessibility of each RTP Proxy and avoids sending new calls to ones that are not accessible at the moment.

Call Routing ¶

The B2BUA routes incoming calls based on dynamic information returned by the RADIUS server with each authentication accept response, or alternatively, by statically using information provided in the command line. In the former case, it is expected that any positive response should contain one or more routing entries placed into the h323-ivr-in the Cisco VSA attribute. The format of the routing entries is as follows:

h323-ivr-in=Routing:[[cld]@]hostname[:port][;credit-time=seconds][;expires=seconds][;auth=username:password][;cli=cli][;ash=ash][;np_expires=seconds]

Options in square brackets are optional parameters. The underlined words denote variables to be filled in by the RADIUS server. If more than a single routing entry is present, routing entries will be tried one by one until either there are no more routes left or the call is successfully connected. The following parameters are available:

cld - CLD to be used for the outgoing call hostname - IP address or DNS name of the SIP peer to which the call must be sent port - UDP port at which the SIP peer to which the call must be sent accepts SIP

signaling messages credit-time - maximum session time to be allowed before the call is forcefully

disconnected by the B2BUA expires - maximum time to wait until the call sent to a particular route is

connected. If this time has been exceeded, the B2BUA proceeds to processing the next route if one or more routes is available, or reports a failure condition to the caller if not available.

auth - username/password pair for SIP authentication with a remote SIP peer at hostname

cli - CLI to be used for the outgoing call ash - insert arbitrary SIP header field into INVITE of the originate call leg. The

parameter value should be a valid SIP header field in the format Name:Value, transformed using URL quoting rules set forth in RFC 1738.

np_expires - maximum time to wait until non-100 provisional response on the call sent to a particular route is received or the call is connected (whichever happens first). If this time has been exceeded, the B2BUA proceeds to processing the next route if one or more routes is available, or reports a failure condition to the caller if not available.

The following is an example of a routing string in the RADIUS attribute:

h323-ivr-in = 'Routing:[email protected];cli=16046288900;rid=-1;expires=30;np_expires=5;ash=Name%3AValue'

The same as the static route in the command line would be:

b2bua_radius.py ... -s '[email protected];cli=16046288900;rid=-1;expires=30;np_expires=5;ash=Name%3AValue' ...

FAQ ¶

General ¶

Why using Python? Isn't it slow?

For certain class of application Python provides adequate performance. Being 100% text based protocol, SIP appears to be one of such applications. Also, when telecommunication applications are considered some other factors, such as reliability and resilence, have much more importance than pure performance. With the performance numbers outlined above (150-200 calls/second) one server running Sippy B2BUA can handle tenth of millions billable minites per month. Any network that operates with such vast amount of traffic has no choice but become distributed to grow further, which limits usefullness of using unsafe languages such as C or C++ to improve performance of a single B2BUA instance beyond that point.

Can the Sippy B2BUA determine if one of the peer in a session gone without a BYE message (eg. disconnected the network interface) and then send a BYE message to the other peer?

Yes, it's possible. There are two methods for determining that the one of the parties is gone: the first is by sending periodical re-INVITE to both parties (so-called SIP keep-alives), and another one is by monitoring state of the RTP session in the proxy. The first one is already supported by the B2BUA.

Installation and Configuration ¶

How to install and configure RADIUS client?

For radiusclient-ng you should do the following:

Install radiusclent-ng from source

~# tar xvfz radiusclient-ng-X.Y.Z.tar.gz~# cd radiusclient-ng-X.Y.Z~# ./configure~# make~# make install

Edit /usr/local/etc/radiusclient-ng/radiusclient.conf and set address of authentication and accounting servers

authserver homero.lucio01.netacctserver homero.lucio01.net

Edit /usr/local/etc/radiusclient-ng/servers and add shared secret for each server the client comunicates with.

homero.lucio01.net testing123

Include dictionary included in sippy b2bua dist into radiusclient-ng by copying dictionary file from Sippy distribution into /usr/local/etc/radiusclient-ng.

How to install and configure RADIUS server?

There are many RADIUS servers, both open source and commercial ones. You should refer to documentation of the selected server software on how to install and configure it. For a good GPL RADIUS server you can check   FreeRADIUS .

ImportError: No module named twisted.internet when trying to run B2BUA

As it is mentioned above, the B2BUA requires   Twisted framework version 2.4 or later to run. Please check the   twistedmatrix.com website for information on how to install it on your system.

Troubleshooting ¶

The B2BUA responds with 403 Auth Failed to all incoming calls, what's wrong?

There are two possible reasons for this negative response:

RADIUS server rejects authentication request. In this case you should check the RADIUS server logs to find a problem.

RADIUS client is not configured properly. This case can be identified by the following message in the B2BUA log:

07 Jan 19:51:55/[email protected]/b2bua: Error sending AAA request (delay is 0.003)

You should check your system log, usually /var/log/messages, to see detailed error(s) generated by the RADIUS client in this case.

by colinm » Tue Aug 09, 2005 4:22 pm

Hi everybody ... A few days agos a have installed a asterisk sip server im my network. It works perfectly, except that my sip server in acting as a sip proxy. I mean, all "conversation" cross through my sip, and its not P2P. For example: client1 has ip 10.0.0.1 client2 has ip 192.168.0.1 sip server has ip 10.0.0.5.

All conversation is between client1 <-> sip_server <-> client2, But i want client1 <-> client2 (they talking direclly). Is that possible ?

Before somebody answer, two things: first, sorry about my "english" (and don't know speek very well); and second, sorry for my silly question (maybe stupid for you all).

Asterisk will attempt to do this by itself by default when possible. The call control layer will pass through Asterisk for billing purposes, but if it determines two phones can talk to each other it will send a REINVITE message to let the phones directly transmit audio to each other.

Depending on your sip.conf settings, this may be disabled. If you've set canreinvite=no either globally or for a specific phone, Asterisk will not issue the REINVITE and will act as a bridge between the two endpoints.

Direct connections area also generally not possible if your phones are behind NAT, since there's no way for outside phones to establish communications with them through the firewall.

Mon, 23 Jul 2007 02:19:58 -0700

Asterisk is not a sip proxy but it *can* partly act as a sip proxy if reinvites are enabled ( canreinvite=yes in sip.conf ) only then asterisk connects 2 end points directly and does signalling between them .

Asterisk is a PBX now suppose u need to record all calls ..do conferencing stuff then rtp stream need to pass from asterisk ( openser cant do this bcoz it just connects 2 endpoints and only does signalling ) .. If you do canreinvite=yes in sip.conf for both peers then asterisk does only signalling ( also dial command should not have transfer parameters tT .. ) .If both peers are behind NAT then asterisk reinvites may not work properly .

Since telephony transport is digital, we do transport separately voice and signalling. Each domain should be efficient in different places, performances are different and the way providing service has been adapted on specific architectures and machines. The purpose of this article is to explore how Asterisk fit with regards to these two domains that have been kept for telephony over IP.(kể từ khi hệ thống điện thoại số ra đời, chúng ta đã có thể truyền thoại và báo hiệu trên hai kênh khác nhau. Mỗi miền phải hoạt động sao cho có hiệu quả ở những nơi khác nhau. Những hoạt động khác nhau và cách thức cung cấp dịch vụ đã được làm cho thích nghi với từng kiểu kiến trúc và máy móc riêng. Mục đích của bài này là khám phá ra làm thế nào để Asterisk có hoạt động phù hợp trên cả hai lĩnh vực mạng điện thoại và mạng IP.

For private telephony, that can be from home to enterprise, signalling and voice transport functions are separated from a functional point of view, but some times they are tied together inside the same machine, let call it a PBX. This is mainly the case for solution provided by the manufacturer of legacy voice systems. The new entrants, mainly arriving from the data side, generally separate functions on different machines, more specific and able to scale with customer need.

Đối với mạng điện thoại riêng, từ nhà đến doanh nghiệp, chức năng vận chuyển báo hiệu và thoại được chia ra từ một điểm chức năng, nhưng đôi khi chúng kết hợp với nhau trong cùng một kiến trúc, người ta gọi đó là PBX.

Đối với điện thoại tư nhân, mà có thể được từ nhà đến doanh nghiệp, tín hiệu và tiếng nói chức năng vận chuyển được tách ra từ một điểm chức năng của xem, nhưng một số lần họ được gắn kết cùng nhau trong cùng một máy, chúng ta hãy gọi nó là một PBX. Điều này chủ yếu là trường hợp của giải pháp cung cấp bởi nhà sản xuất của các hệ thống thoại di sản. Các diện mới, chủ yếu là đến từ phía các dữ liệu, thường tách biệt chức năng trên các máy khác nhau, cụ thể hơn và có thể cần phải có quy mô với khách hàng.

In the Asterisk world, by default the two functions are linked together; further more calls are forced to flow on the same path as signalling. This is mainly due to the orientation of the product: a back-to-back user agent solution. But, we can configure the Asterisk solution in order to be more compliant to strict separation of voice and signalling, like in the SIP or H.323 models.

Trong các hệ thống Asterisk trên thế giới, mặc định có hai chức năng được liên kết với nhau, càng nhiều cuộc gọi hơn nữa thì bắt buộc phải lưu trên một đường báo hiệu. Điều này chủ yếu là do sự định hướng của sản phẩm: giải pháp B2BUA. Nhưng chúng ta có

thể cấu hình Asterisk để phù hợp hơn nhầm tách biết tín hiệu thoại và báo hiệu, giống như SIP và H323.

The normal Asterisk model is keeping voice and signalling to flow inside the Asterisk box because it is easier to propose enhanced services like call forwarding, voice mail or call monitoring. In that aspect Asterisk is what we call a “stateful proxy” in the SIP world.

Thông thường Asterisk giữ tín hiệu thoại và tín hiệu báo hiệu lưu thông bên trong hộp Asterisk bởi vì như thế sẽ dễ dàng hơn để tăng cường các dịch vụ như call forwarding, voice mail, call monitoring. Thật sự ta có thể thể gọi asterisk là một Stateful Proxy trong mạng SIP trên thế giới.

Asterisk is proposed with an open but proprietary voice interconnection protocol called IAX for Inter Asterisk Exchange. This protocol has been designed in order to allow a simple, quick and straightforward interconnection of two Asterisk PBX without any hassle on the network configuration, port forwarding or TCP stack usage. On the other hand, SIP is really an only signalling protocol, not specific for voice but more for any kind of communication, including video, application or instant messaging. SIP is not taking care of how the communication will be transported afterwards, it is only putting user agent into contact and helping these in exchanging there capacities and how to talk.

Asterisk là một hệ mở, nhưng nó thuộc về giao thức liên kết nối tín hiệu thoại được gọi là IAX (Inter Asterisk Exchange). Giao thức này được thiết kế để cho phép hai Asterisk PBX có thể liên kết với nhau một cách nhanh chóng và dễ dàng mà không cần bất cứ một cấu hình mạng rắc rối nào, chỉ sử dụng port TCP. Mặt khác, SIP thật sự chỉ là một giao thức báo hiệu, không dành riêng cho thoại mà cho bất kỳ một loại thông tin nào, bao gồm cả vedio, các ứng dụng về tin nhắn tức thời. SIP ko chỉ quan tâm đến làm cách nào để thông tin có thể được

When using Asterisk with SIP phones, voice is not flowing straight between these ones but through the Asterisk. The main advantages we could find with this solution are:

Khi dùng asterisk với SIP phone, âm thoại không truyền trực tiếp giữa các SIP mà phải thông qua Asterisk. Ưu điểm chính của nó là:

- Asterisk có thể phân tích nếu phím điện thoại được nhấn và thực thi cho phù hợp với các phím nhấn này.

- Giải pháp là sự phụ thuộc với các điện thoại khác nhau để thực thi các chức năng riêng, vì thế dễ dàng cho việc ,,,

- Asterisk có thể quản lý một số lượng lớn các codecs và chuyển đổi giữa các

Asterisk can analyze if phone keys are pushed and handle function associated with those (see features.conf).

the solution is independent with regards various phones with regards to specific functions (transfer, voice mail, …), thus easier for migration or phone change.

Asterisk is able to handle a large list of codec and can translate between phones and Centrex not sharing a common one.

But, the voice in transit in the server hosting the Asterisk is stressing this one. It should handle large amount of frames and transform their content. Each call is putting more stress on the server and can impact performances which are critical for voice transport. Further more, this solution with a central point where calls are handled from a voice perspective is not efficient for phone not located on the same site. Two phones located at the same remote location and managed by the Asterisk on a central site would see their voice traffic flowing via the central site which is not efficient. This one of the reason why the SIP distributed model has been designed in a way voice is flowing direct and signalling can go to a central point.

The following datagram shows the call flow using SIP inside an Asterisk system:

We can clearly see the signalling part is going through the Asterisk, but also the voice. This stateful proxy mode is mainly used today in SBC1 for security reason.

When Asterisk is not wanted in the voice path, we should respect three rules:

the Dial application command should not use in the last argument a function forcing the traffic to flow outside the bridge like t or T.

the sip.conf should not specify the canreinvite=yes option for one of the two SIP phones

the IP phones should be able to accept specific SIP INVITE messages when the call is already engaged.

First rule is easy to put in place and check, the easiest way is to use a Dial application command without any argument but the timeout2 – see extensions.conf.

The Re-INVITE thing is a bit trickier. The way Asterisk handle a call outside the bridge is the following:

establish the call with an indirect voice path in the initial INVITE messages3. when the call is established, if the voice path needs to be direct, a new INVITE

message is sent to both parties telling these to modify the voice path to a direct one. This is where IP phones should be able to handle this specific message used to initiate a session and used here to modify an existing one. The SIP protocol is authorizing this behaviour but not every one is able to handle it properly.

The diagram of such an outside bridge call is the following:

First phase is similar to what we saw previously for the bridged call. Phase 2 is showing what changed: the new INVITE message is sent to both engaged parties. These messages are explaining how the voice path should go direct by modifying the RTP IP addresses and port numbers. But the phone call is already engaged, each phone will have to switch the destination without loosing a voice frame.

If one of the phone is not able to handle correctly the INVITE message we can arrive to a half bridge call or a call on which only one path is working well.

If the process is successful, the call will be outside the bridge, which means the signalling path remains through Asterisk but the voice path is now direct. This model is closer to the SIP one and less stressing for Asterisk that could handle this way far more simultaneous call. Gotcha.

If the voice system requires direct voice paths, we will have to validate IP phones supporting the Re-INVITE messages. It will also be mandatory to align codecs used on each phone since Asterisk will not be translating any of these. Some tests and validation steps are thus required prior going to production.

Last but not least, some features proposed by Asterisk staying in the call flow will not anymore be available, like the transfer. Each SIP phone is able to transfer a call but requires specific actions that should be documented and provided to end-users. For example, low end phones are using the Flash key for supervised transfer, some other are smarter and propose a one key transfer mode, it can be either blind or supervised.

INVITE sip:[email protected] SIP/2.0Via: SIP/2.0/UDP 192.168.70.1:23762;branch=z9hG4bK-d8754z-b57ee02a8e25c85f-1---d8754z-;rportMax-Forwards: 70Contact: <sip:[email protected]:23762>To: "101"<sip:[email protected]>From: "100"<sip:[email protected]>;tag=6a122732Call-ID: MTM0NDJlNzFiZTY4YTVhN2YwMGMzOWI5OGUzY2I4NmQ.CSeq: 1 INVITEAllow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFOContent-Type: application/sdpUser-Agent: X-Lite release 1104o stamp 56125Content-Length: 364

v=0o=- 6 2 IN IP4 192.168.70.1s=CounterPath X-Lite 3.0c=IN IP4 192.168.70.1t=0 0m=audio 44206 RTP/AVP 107 0 8 101a=alt:1 3 : gpm9O/uP E3VgLHXv 192.168.1.2 44206a=alt:2 2 : 5bi1qIjn F/H8bZOM 192.168.126.1 44206a=alt:3 1 : O4tXIsnV way+jzCj 192.168.70.1 44206a=fmtp:101 0-15a=rtpmap:107 BV32/16000a=rtpmap:101 telephone-event/8000a=sendrecv

<------------->--- (12 headers 13 lines) ---Sending to 192.168.70.1 : 23762 (NAT)Using INVITE request as basis request - MTM0NDJlNzFiZTY4YTVhN2YwMGMzOWI5OGUzY2I4NmQ.

<--- Reliably Transmitting (no NAT) to 192.168.70.1:23762 --->SIP/2.0 407 Proxy Authentication RequiredVia: SIP/2.0/UDP 192.168.70.1:23762;branch=z9hG4bK-d8754z-b57ee02a8e25c85f-1---d8754z-;received=192.168.70.1;rport=23762From: "100"<sip:[email protected]>;tag=6a122732To: "101"<sip:[email protected]>;tag=as401c60a8Call-ID: MTM0NDJlNzFiZTY4YTVhN2YwMGMzOWI5OGUzY2I4NmQ.CSeq: 1 INVITEUser-Agent: Asterisk PBXAllow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFYSupported: replacesProxy-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="1f056cd9"Content-Length: 0

<------------>Scheduling destruction of SIP dialog 'MTM0NDJlNzFiZTY4YTVhN2YwMGMzOWI5OGUzY2I4NmQ.' in 32000 ms (Method: INVITE)Found user '100'

<--- SIP read from 192.168.70.1:23762 --->ACK sip:[email protected] SIP/2.0Via: SIP/2.0/UDP 192.168.70.1:23762;branch=z9hG4bK-d8754z-b57ee02a8e25c85f-1---d8754z-;rportTo: "101"<sip:[email protected]>;tag=as401c60a8From: "100"<sip:[email protected]>;tag=6a122732Call-ID: MTM0NDJlNzFiZTY4YTVhN2YwMGMzOWI5OGUzY2I4NmQ.CSeq: 1 ACKContent-Length: 0

<------------->--- (7 headers 0 lines) ---

<--- SIP read from 192.168.70.1:23762 --->INVITE sip:[email protected] SIP/2.0Via: SIP/2.0/UDP 192.168.70.1:23762;branch=z9hG4bK-d8754z-db4b6a547b3a9f47-1---d8754z-;rportMax-Forwards: 70Contact: <sip:[email protected]:23762>To: "101"<sip:[email protected]>From: "100"<sip:[email protected]>;tag=6a122732Call-ID: MTM0NDJlNzFiZTY4YTVhN2YwMGMzOWI5OGUzY2I4NmQ.CSeq: 2 INVITEAllow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE,

SUBSCRIBE, INFOContent-Type: application/sdpProxy-Authorization: Digest username="100",realm="asterisk",nonce="1f056cd9",uri="sip:[email protected]",response="e6ee3be8c15baa045d83a3de08daa862",algorithm=MD5User-Agent: X-Lite release 1104o stamp 56125Content-Length: 364

v=0o=- 6 2 IN IP4 192.168.70.1s=CounterPath X-Lite 3.0c=IN IP4 192.168.70.1t=0 0m=audio 44206 RTP/AVP 107 0 8 101a=alt:1 3 : gpm9O/uP E3VgLHXv 192.168.1.2 44206a=alt:2 2 : 5bi1qIjn F/H8bZOM 192.168.126.1 44206a=alt:3 1 : O4tXIsnV way+jzCj 192.168.70.1 44206a=fmtp:101 0-15a=rtpmap:107 BV32/16000a=rtpmap:101 telephone-event/8000a=sendrecv

<------------->--- (13 headers 13 lines) ---Sending to 192.168.70.1 : 23762 (NAT)Using INVITE request as basis request - MTM0NDJlNzFiZTY4YTVhN2YwMGMzOWI5OGUzY2I4NmQ.Found user '100'Found RTP audio format 107Found RTP audio format 0Found RTP audio format 8Found RTP audio format 101Peer audio RTP is at port 192.168.70.1:44206Found unknown media description format BV32 for ID 107Found audio description format telephone-event for ID 101Capabilities: us - 0xc (ulaw|alaw), peer - audio=0xc (ulaw|alaw)/video=0x0 (nothing), combined - 0xc (ulaw|alaw)Non-codec capabilities (dtmf): us - 0x1 (telephone-event), peer - 0x1 (telephone-event), combined - 0x1 (telephone-event)Peer audio RTP is at port 192.168.70.1:44206Looking for 101 in internal (domain 192.168.70.129)list_route: hop: <sip:[email protected]:23762>

<--- Transmitting (no NAT) to 192.168.70.1:23762 --->SIP/2.0 100 TryingVia: SIP/2.0/UDP 192.168.70.1:23762;branch=z9hG4bK-d8754z-db4b6a547b3a9f47-

1---d8754z-;received=192.168.70.1;rport=23762From: "100"<sip:[email protected]>;tag=6a122732To: "101"<sip:[email protected]>Call-ID: MTM0NDJlNzFiZTY4YTVhN2YwMGMzOWI5OGUzY2I4NmQ.CSeq: 2 INVITEUser-Agent: Asterisk PBXAllow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFYSupported: replacesContact: <sip:[email protected]>Content-Length: 0

<------------>    -- Executing [101@internal:1] Dial("SIP/100-08210e28", "Sip/101") in new stackAudio is at 192.168.70.129 port 11444Adding codec 0x4 (ulaw) to SDPAdding codec 0x8 (alaw) to SDPAdding non-codec 0x1 (telephone-event) to SDPReliably Transmitting (no NAT) to 192.168.1.2:5060:INVITE sip:[email protected]:5060;transport=UDP SIP/2.0Via: SIP/2.0/UDP 192.168.70.129:5060;branch=z9hG4bK260efc79;rportFrom: "100" <sip:[email protected]>;tag=as2cad8232To: <sip:[email protected]:5060;transport=UDP>Contact: <sip:[email protected]>Call-ID: [email protected]: 102 INVITEUser-Agent: Asterisk PBXMax-Forwards: 70Date: Wed, 25 Aug 2010 15:04:49 GMTAllow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFYSupported: replacesContent-Type: application/sdpContent-Length: 266

v=0o=root 5582 5582 IN IP4 192.168.70.129s=sessionc=IN IP4 192.168.70.129t=0 0m=audio 11444 RTP/AVP 0 8 101a=rtpmap:0 PCMU/8000a=rtpmap:8 PCMA/8000a=rtpmap:101 telephone-event/8000a=fmtp:101 0-16a=silenceSupp:off - - - -a=ptime:20

a=sendrecv

---    -- Called 101ngan-desktop*CLI> <--- SIP read from 192.168.1.2:5060 --->SIP/2.0 100 TryingVia: SIP/2.0/UDP 192.168.70.129:5060;rport=3482;received=192.168.1.2;branch=z9hG4bK260efc79Call-ID: [email protected]: "100" <sip:[email protected]>;tag=as2cad8232To: <sip:[email protected]>CSeq: 102 INVITEContent-Length: 0

<------------->--- (7 headers 0 lines) ---ngan-desktop*CLI> <--- SIP read from 192.168.1.2:5060 --->SIP/2.0 180 RingingVia: SIP/2.0/UDP 192.168.70.129:5060;rport=3482;received=192.168.1.2;branch=z9hG4bK260efc79Call-ID: [email protected]: "100" <sip:[email protected]>;tag=as2cad8232To: <sip:[email protected]>;tag=3dd0b5f06a1d41b4a80a8a1bc181d06fCSeq: 102 INVITEContact: <sip:192.168.1.2:5060;transport=UDP>Content-Length: 0

<------------->--- (8 headers 0 lines) ---    -- SIP/101-08215ae8 is ringing

<--- Transmitting (no NAT) to 192.168.70.1:23762 --->SIP/2.0 180 RingingVia: SIP/2.0/UDP 192.168.70.1:23762;branch=z9hG4bK-d8754z-db4b6a547b3a9f47-1---d8754z-;received=192.168.70.1;rport=23762From: "100"<sip:[email protected]>;tag=6a122732To: "101"<sip:[email protected]>;tag=as7b40993aCall-ID: MTM0NDJlNzFiZTY4YTVhN2YwMGMzOWI5OGUzY2I4NmQ.CSeq: 2 INVITEUser-Agent: Asterisk PBXAllow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFYSupported: replaces

Contact: <sip:[email protected]>Content-Length: 0

<------------>ngan-desktop*CLI> <--- SIP read from 192.168.1.2:5060 --->SIP/2.0 200 OKVia: SIP/2.0/UDP 192.168.70.129:5060;rport=3482;received=192.168.1.2;branch=z9hG4bK260efc79Call-ID: [email protected]: "100" <sip:[email protected]>;tag=as2cad8232To: <sip:[email protected]>;tag=3dd0b5f06a1d41b4a80a8a1bc181d06fCSeq: 102 INVITEContact: <sip:192.168.1.2:5060;transport=UDP>Allow: INVITE, ACK, BYE, CANCEL, SUBSCRIBE, NOTIFY, PUBLISH, REFER, MESSAGE, OPTIONSSupported: replaces, norefersubContent-Type: application/sdpContent-Length: 239

v=0o=- 3491762680 3491762681 IN IP4 192.168.1.2s=sessionc=IN IP4 192.168.1.2t=0 0m=audio 23000 RTP/AVP 0 101a=rtcp:23001 IN IP4 192.168.1.2a=rtpmap:0 PCMU/8000a=sendrecva=rtpmap:101 telephone-event/8000a=fmtp:101 0-15

<------------->--- (11 headers 11 lines) ---Found RTP audio format 0Found RTP audio format 101Peer audio RTP is at port 192.168.1.2:23000Found audio description format PCMU for ID 0Found audio description format telephone-event for ID 101Capabilities: us - 0xc (ulaw|alaw), peer - audio=0x4 (ulaw)/video=0x0 (nothing), combined - 0x4 (ulaw)Non-codec capabilities (dtmf): us - 0x1 (telephone-event), peer - 0x1 (telephone-event), combined - 0x1 (telephone-event)Peer audio RTP is at port 192.168.1.2:23000list_route: hop: <sip:192.168.1.2:5060;transport=UDP>

set_destination: Parsing <sip:192.168.1.2:5060;transport=UDP> for address/port to send toset_destination: set destination to 192.168.1.2, port 5060Transmitting (no NAT) to 192.168.1.2:5060:ACK sip:192.168.1.2:5060;transport=UDP SIP/2.0Via: SIP/2.0/UDP 192.168.70.129:5060;branch=z9hG4bK4b9f79d7;rportFrom: "100" <sip:[email protected]>;tag=as2cad8232To: <sip:[email protected]:5060;transport=UDP>;tag=3dd0b5f06a1d41b4a80a8a1bc181d06fContact: <sip:[email protected]>Call-ID: [email protected]: 102 ACKUser-Agent: Asterisk PBXMax-Forwards: 70Content-Length: 0

---    -- SIP/101-08215ae8 answered SIP/100-08210e28Audio is at 192.168.70.129 port 15894Adding codec 0x4 (ulaw) to SDPAdding codec 0x8 (alaw) to SDPAdding non-codec 0x1 (telephone-event) to SDP

<--- Reliably Transmitting (no NAT) to 192.168.70.1:23762 --->SIP/2.0 200 OKVia: SIP/2.0/UDP 192.168.70.1:23762;branch=z9hG4bK-d8754z-db4b6a547b3a9f47-1---d8754z-;received=192.168.70.1;rport=23762From: "100"<sip:[email protected]>;tag=6a122732To: "101"<sip:[email protected]>;tag=as7b40993aCall-ID: MTM0NDJlNzFiZTY4YTVhN2YwMGMzOWI5OGUzY2I4NmQ.CSeq: 2 INVITEUser-Agent: Asterisk PBXAllow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFYSupported: replacesContact: <sip:[email protected]>Content-Type: application/sdpContent-Length: 266

v=0o=root 5582 5582 IN IP4 192.168.70.129s=sessionc=IN IP4 192.168.70.129t=0 0m=audio 15894 RTP/AVP 0 8 101a=rtpmap:0 PCMU/8000

a=rtpmap:8 PCMA/8000a=rtpmap:101 telephone-event/8000a=fmtp:101 0-16a=silenceSupp:off - - - -a=ptime:20a=sendrecv

<------------>    -- Native bridging SIP/100-08210e28 and SIP/101-08215ae8set_destination: Parsing <sip:192.168.1.2:5060;transport=UDP> for address/port to send toset_destination: set destination to 192.168.1.2, port 5060Audio is at 192.168.70.129 port 11444Adding codec 0x4 (ulaw) to SDPAdding non-codec 0x1 (telephone-event) to SDPReliably Transmitting (no NAT) to 192.168.1.2:5060:INVITE sip:192.168.1.2:5060;transport=UDP SIP/2.0Via: SIP/2.0/UDP 192.168.70.129:5060;branch=z9hG4bK704c3ce6;rportFrom: "100" <sip:[email protected]>;tag=as2cad8232To: <sip:[email protected]:5060;transport=UDP>;tag=3dd0b5f06a1d41b4a80a8a1bc181d06fContact: <sip:[email protected]>Call-ID: [email protected]: 103 INVITEUser-Agent: Asterisk PBXMax-Forwards: 70Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFYSupported: replacesX-asterisk-Info: SIP re-invite (External RTP bridge)Content-Type: application/sdpContent-Length: 238

v=0o=root 5582 5583 IN IP4 192.168.70.1s=sessionc=IN IP4 192.168.70.1t=0 0m=audio 44206 RTP/AVP 0 101a=rtpmap:0 PCMU/8000a=rtpmap:101 telephone-event/8000a=fmtp:101 0-16a=silenceSupp:off - - - -a=ptime:20a=sendrecv

---

ngan-desktop*CLI> <--- SIP read from 192.168.70.1:23762 --->ACK sip:[email protected] SIP/2.0Via: SIP/2.0/UDP 192.168.70.1:23762;branch=z9hG4bK-d8754z-b31688467b0ca107-1---d8754z-;rportMax-Forwards: 70Contact: <sip:[email protected]:23762>To: "101"<sip:[email protected]>;tag=as7b40993aFrom: "100"<sip:[email protected]>;tag=6a122732Call-ID: MTM0NDJlNzFiZTY4YTVhN2YwMGMzOWI5OGUzY2I4NmQ.CSeq: 2 ACKProxy-Authorization: Digest username="100",realm="asterisk",nonce="1f056cd9",uri="sip:[email protected]",response="e6ee3be8c15baa045d83a3de08daa862",algorithm=MD5User-Agent: X-Lite release 1104o stamp 56125Content-Length: 0

<------------->--- (11 headers 0 lines) ---set_destination: Parsing <sip:[email protected]:23762> for address/port to send toset_destination: set destination to 192.168.70.1, port 23762Audio is at 192.168.70.129 port 15894Adding codec 0x4 (ulaw) to SDPAdding non-codec 0x1 (telephone-event) to SDPReliably Transmitting (no NAT) to 192.168.70.1:23762:INVITE sip:[email protected]:23762 SIP/2.0Via: SIP/2.0/UDP 192.168.70.129:5060;branch=z9hG4bK2f4d62bb;rportFrom: "101"<sip:[email protected]>;tag=as7b40993aTo: "100"<sip:[email protected]>;tag=6a122732Contact: <sip:[email protected]>Call-ID: MTM0NDJlNzFiZTY4YTVhN2YwMGMzOWI5OGUzY2I4NmQ.CSeq: 102 INVITEUser-Agent: Asterisk PBXMax-Forwards: 70Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFYSupported: replacesX-asterisk-Info: SIP re-invite (External RTP bridge)Content-Type: application/sdpContent-Length: 236

v=0o=root 5582 5583 IN IP4 192.168.1.2s=sessionc=IN IP4 192.168.1.2t=0 0

m=audio 23000 RTP/AVP 0 101a=rtpmap:0 PCMU/8000a=rtpmap:101 telephone-event/8000a=fmtp:101 0-16a=silenceSupp:off - - - -a=ptime:20a=sendrecv

---ngan-desktop*CLI> <--- SIP read from 192.168.70.1:23762 --->SIP/2.0 200 OKVia: SIP/2.0/UDP 192.168.70.129:5060;branch=z9hG4bK2f4d62bb;rport=5060Contact: <sip:[email protected]:23762>To: "100"<sip:[email protected]>;tag=6a122732From: "101"<sip:[email protected]>;tag=as7b40993aCall-ID: MTM0NDJlNzFiZTY4YTVhN2YwMGMzOWI5OGUzY2I4NmQ.CSeq: 102 INVITEAllow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFOContent-Type: application/sdpUser-Agent: X-Lite release 1104o stamp 56125Content-Length: 183

v=0o=- 6 3 IN IP4 192.168.70.1s=CounterPath X-Lite 3.0c=IN IP4 192.168.70.1t=0 0m=audio 44206 RTP/AVP 0 101a=fmtp:101 0-15a=rtpmap:101 telephone-event/8000a=sendrecv

<------------->--- (11 headers 9 lines) ---Found RTP audio format 0Found RTP audio format 101Peer audio RTP is at port 192.168.70.1:44206Found audio description format telephone-event for ID 101Capabilities: us - 0x4 (ulaw), peer - audio=0x4 (ulaw)/video=0x0 (nothing), combined - 0x4 (ulaw)Non-codec capabilities (dtmf): us - 0x1 (telephone-event), peer - 0x1 (telephone-event), combined - 0x1 (telephone-event)Peer audio RTP is at port 192.168.70.1:44206set_destination: Parsing <sip:[email protected]:23762> for address/port to send to

set_destination: set destination to 192.168.70.1, port 23762Transmitting (no NAT) to 192.168.70.1:23762:ACK sip:[email protected]:23762 SIP/2.0Via: SIP/2.0/UDP 192.168.70.129:5060;branch=z9hG4bK6cb757d8;rportFrom: "101"<sip:[email protected]>;tag=as7b40993aTo: "100"<sip:[email protected]>;tag=6a122732Contact: <sip:[email protected]>Call-ID: MTM0NDJlNzFiZTY4YTVhN2YwMGMzOWI5OGUzY2I4NmQ.CSeq: 102 ACKUser-Agent: Asterisk PBXMax-Forwards: 70Content-Length: 0

---ngan-desktop*CLI> <--- SIP read from 192.168.1.2:5060 --->SIP/2.0 200 OKVia: SIP/2.0/UDP 192.168.70.129:5060;rport=3482;received=192.168.1.2;branch=z9hG4bK704c3ce6Call-ID: [email protected]: "100" <sip:[email protected]>;tag=as2cad8232To: <sip:[email protected]>;tag=3dd0b5f06a1d41b4a80a8a1bc181d06fCSeq: 103 INVITEContact: <sip:192.168.1.2:5060;transport=UDP>Allow: INVITE, ACK, BYE, CANCEL, SUBSCRIBE, NOTIFY, PUBLISH, REFER, MESSAGE, OPTIONSSupported: replaces, norefersubContent-Type: application/sdpContent-Length: 239

v=0o=- 3491762683 3491762682 IN IP4 192.168.1.2s=sessionc=IN IP4 192.168.1.2t=0 0m=audio 23000 RTP/AVP 0 101a=rtcp:23001 IN IP4 192.168.1.2a=rtpmap:0 PCMU/8000a=sendrecva=rtpmap:101 telephone-event/8000a=fmtp:101 0-15

<------------->--- (11 headers 11 lines) ---Found RTP audio format 0

Found RTP audio format 101Peer audio RTP is at port 192.168.1.2:23000Found audio description format PCMU for ID 0Found audio description format telephone-event for ID 101Capabilities: us - 0xc (ulaw|alaw), peer - audio=0x4 (ulaw)/video=0x0 (nothing), combined - 0x4 (ulaw)Non-codec capabilities (dtmf): us - 0x1 (telephone-event), peer - 0x1 (telephone-event), combined - 0x1 (telephone-event)Peer audio RTP is at port 192.168.1.2:23000set_destination: Parsing <sip:192.168.1.2:5060;transport=UDP> for address/port to send toset_destination: set destination to 192.168.1.2, port 5060Transmitting (no NAT) to 192.168.1.2:5060:ACK sip:192.168.1.2:5060;transport=UDP SIP/2.0Via: SIP/2.0/UDP 192.168.70.129:5060;branch=z9hG4bK41ab1bfe;rportFrom: "100" <sip:[email protected]>;tag=as2cad8232To: <sip:[email protected]:5060;transport=UDP>;tag=3dd0b5f06a1d41b4a80a8a1bc181d06fContact: <sip:[email protected]>Call-ID: [email protected]: 103 ACKUser-Agent: Asterisk PBXMax-Forwards: 70Content-Length: 0

---ngan-desktop*CLI> <--- SIP read from 192.168.70.1:5060 --->BYE sip:[email protected] SIP/2.0Via: SIP/2.0/UDP 192.168.1.2:5060;rport;branch=z9hG4bKPj04eed753bf4e4a3ab357ca325d6c0278Max-Forwards: 70From: <sip:[email protected]>;tag=3dd0b5f06a1d41b4a80a8a1bc181d06fTo: "100" <sip:[email protected]>;tag=as2cad8232Call-ID: [email protected]: 1674275836 BYEUser-Agent: VidoSIP/1.5Content-Length: 0

<------------->--- (9 headers 0 lines) ---Sending to 192.168.70.1 : 5060 (NAT)

<--- Transmitting (NAT) to 192.168.70.1:5060 --->

SIP/2.0 200 OKVia: SIP/2.0/UDP 192.168.1.2:5060;branch=z9hG4bKPj04eed753bf4e4a3ab357ca325d6c0278;received=192.168.70.1;rport=5060From: <sip:[email protected]>;tag=3dd0b5f06a1d41b4a80a8a1bc181d06fTo: "100" <sip:[email protected]>;tag=as2cad8232Call-ID: [email protected]: 1674275836 BYEUser-Agent: Asterisk PBXAllow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFYSupported: replacesContact: <sip:[email protected]>Content-Length: 0

<------------>set_destination: Parsing <sip:[email protected]:23762> for address/port to send toset_destination: set destination to 192.168.70.1, port 23762Audio is at 192.168.70.129 port 15894Adding codec 0x4 (ulaw) to SDPAdding non-codec 0x1 (telephone-event) to SDPReliably Transmitting (no NAT) to 192.168.70.1:23762:INVITE sip:[email protected]:23762 SIP/2.0Via: SIP/2.0/UDP 192.168.70.129:5060;branch=z9hG4bK2a7461d3;rportFrom: "101"<sip:[email protected]>;tag=as7b40993aTo: "100"<sip:[email protected]>;tag=6a122732Contact: <sip:[email protected]>Call-ID: MTM0NDJlNzFiZTY4YTVhN2YwMGMzOWI5OGUzY2I4NmQ.CSeq: 103 INVITEUser-Agent: Asterisk PBXMax-Forwards: 70Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFYSupported: replacesX-asterisk-Info: SIP re-invite (External RTP bridge)Content-Type: application/sdpContent-Length: 242

v=0o=root 5582 5584 IN IP4 192.168.70.129s=sessionc=IN IP4 192.168.70.129t=0 0m=audio 15894 RTP/AVP 0 101a=rtpmap:0 PCMU/8000a=rtpmap:101 telephone-event/8000a=fmtp:101 0-16

a=silenceSupp:off - - - -a=ptime:20a=sendrecv

---  == Spawn extension (internal, 101, 1) exited non-zero on 'SIP/100-08210e28'Scheduling destruction of SIP dialog 'MTM0NDJlNzFiZTY4YTVhN2YwMGMzOWI5OGUzY2I4NmQ.' in 32000 ms (Method: ACK)

<--- SIP read from 192.168.70.1:5060 --->REGISTER sip:192.168.70.129:5060 SIP/2.0Via: SIP/2.0/UDP 192.168.1.2:5060;rport;branch=z9hG4bKPjb0b2109116e94409b6724d1e2b7d9d61Max-Forwards: 70From: <sip:[email protected]>;tag=203c01ed87fd450b998ab892d7e5ddb9To: <sip:[email protected]>Call-ID: a052a313dd01423bacf93e7054fe12a8CSeq: 18 REGISTERUser-Agent: VidoSIP/1.5Contact: <sip:[email protected]:5060;transport=UDP>;methods="INVITE, INFO, OPTIONS, BYE, CANCEL, ACK"Expires: 600Content-Length: 0

<------------->--- (11 headers 0 lines) ---Using latest REGISTER request as basis requestSending to 192.168.70.1 : 5060 (NAT)

<--- Transmitting (no NAT) to 192.168.1.2:5060 --->SIP/2.0 100 TryingVia: SIP/2.0/UDP 192.168.1.2:5060;branch=z9hG4bKPjb0b2109116e94409b6724d1e2b7d9d61;received=192.168.70.1;rport=5060From: <sip:[email protected]>;tag=203c01ed87fd450b998ab892d7e5ddb9To: <sip:[email protected]>Call-ID: a052a313dd01423bacf93e7054fe12a8CSeq: 18 REGISTERUser-Agent: Asterisk PBXAllow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFYSupported: replacesContact: <sip:[email protected]>Content-Length: 0

<------------>

<--- Transmitting (no NAT) to 192.168.1.2:5060 --->SIP/2.0 401 UnauthorizedVia: SIP/2.0/UDP 192.168.1.2:5060;branch=z9hG4bKPjb0b2109116e94409b6724d1e2b7d9d61;received=192.168.70.1;rport=5060From: <sip:[email protected]>;tag=203c01ed87fd450b998ab892d7e5ddb9To: <sip:[email protected]>;tag=as0a628145Call-ID: a052a313dd01423bacf93e7054fe12a8CSeq: 18 REGISTERUser-Agent: Asterisk PBXAllow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFYSupported: replacesWWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="22844f1e"Content-Length: 0

<------------>Scheduling destruction of SIP dialog 'a052a313dd01423bacf93e7054fe12a8' in 32000 ms (Method: REGISTER)Really destroying SIP dialog '[email protected]' Method: BYE

<--- SIP read from 192.168.70.1:5060 --->REGISTER sip:192.168.70.129:5060 SIP/2.0Via: SIP/2.0/UDP 192.168.1.2:5060;rport;branch=z9hG4bKPj380b5eaa086348d4a683e8bfbf90c75cMax-Forwards: 70From: <sip:[email protected]>;tag=203c01ed87fd450b998ab892d7e5ddb9To: <sip:[email protected]>Call-ID: a052a313dd01423bacf93e7054fe12a8CSeq: 19 REGISTERUser-Agent: VidoSIP/1.5Contact: <sip:[email protected]:5060;transport=UDP>;methods="INVITE, INFO, OPTIONS, BYE, CANCEL, ACK"Expires: 600Authorization: Digest username="101", realm="asterisk", nonce="22844f1e", uri="sip:192.168.70.129:5060", response="689bb0c816c6ffa9e2d4dc2e9917a61a", algorithm=md5Content-Length: 0

<------------->--- (12 headers 0 lines) ---

Using latest REGISTER request as basis requestSending to 192.168.70.1 : 5060 (NAT)

<--- Transmitting (no NAT) to 192.168.1.2:5060 --->SIP/2.0 100 TryingVia: SIP/2.0/UDP 192.168.1.2:5060;branch=z9hG4bKPj380b5eaa086348d4a683e8bfbf90c75c;received=192.168.70.1;rport=5060From: <sip:[email protected]>;tag=203c01ed87fd450b998ab892d7e5ddb9To: <sip:[email protected]>Call-ID: a052a313dd01423bacf93e7054fe12a8CSeq: 19 REGISTERUser-Agent: Asterisk PBXAllow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFYSupported: replacesContact: <sip:[email protected]>Content-Length: 0

<------------>ngan-desktop*CLI> <--- Transmitting (no NAT) to 192.168.1.2:5060 --->SIP/2.0 200 OKVia: SIP/2.0/UDP 192.168.1.2:5060;branch=z9hG4bKPj380b5eaa086348d4a683e8bfbf90c75c;received=192.168.70.1;rport=5060From: <sip:[email protected]>;tag=203c01ed87fd450b998ab892d7e5ddb9To: <sip:[email protected]>;tag=as0a628145Call-ID: a052a313dd01423bacf93e7054fe12a8CSeq: 19 REGISTERUser-Agent: Asterisk PBXAllow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFYSupported: replacesExpires: 600Contact: <sip:[email protected]:5060;transport=UDP>;expires=600Date: Wed, 25 Aug 2010 15:04:53 GMTContent-Length: 0

<------------>Scheduling destruction of SIP dialog 'a052a313dd01423bacf93e7054fe12a8' in 32000 ms (Method: REGISTER)ngan-desktop*CLI> <--- SIP read from 192.168.70.1:23762 --->SIP/2.0 200 OKVia: SIP/2.0/UDP 192.168.70.129:5060;branch=z9hG4bK2a7461d3;rport=5060

Contact: <sip:[email protected]:23762>To: "100"<sip:[email protected]>;tag=6a122732From: "101"<sip:[email protected]>;tag=as7b40993aCall-ID: MTM0NDJlNzFiZTY4YTVhN2YwMGMzOWI5OGUzY2I4NmQ.CSeq: 103 INVITEAllow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFOContent-Type: application/sdpUser-Agent: X-Lite release 1104o stamp 56125Content-Length: 183

v=0o=- 6 3 IN IP4 192.168.70.1s=CounterPath X-Lite 3.0c=IN IP4 192.168.70.1t=0 0m=audio 44206 RTP/AVP 0 101a=fmtp:101 0-15a=rtpmap:101 telephone-event/8000a=sendrecv

<------------->--- (11 headers 9 lines) ---Found RTP audio format 0Found RTP audio format 101Peer audio RTP is at port 192.168.70.1:44206Found audio description format telephone-event for ID 101Capabilities: us - 0x4 (ulaw), peer - audio=0x4 (ulaw)/video=0x0 (nothing), combined - 0x4 (ulaw)Non-codec capabilities (dtmf): us - 0x1 (telephone-event), peer - 0x1 (telephone-event), combined - 0x1 (telephone-event)Peer audio RTP is at port 192.168.70.1:44206set_destination: Parsing <sip:[email protected]:23762> for address/port to send toset_destination: set destination to 192.168.70.1, port 23762Transmitting (no NAT) to 192.168.70.1:23762:ACK sip:[email protected]:23762 SIP/2.0Via: SIP/2.0/UDP 192.168.70.129:5060;branch=z9hG4bK11a6317c;rportFrom: "101"<sip:[email protected]>;tag=as7b40993aTo: "100"<sip:[email protected]>;tag=6a122732Contact: <sip:[email protected]>Call-ID: MTM0NDJlNzFiZTY4YTVhN2YwMGMzOWI5OGUzY2I4NmQ.CSeq: 103 ACKUser-Agent: Asterisk PBXMax-Forwards: 70Content-Length: 0

---set_destination: Parsing <sip:[email protected]:23762> for address/port to send toset_destination: set destination to 192.168.70.1, port 23762Reliably Transmitting (no NAT) to 192.168.70.1:23762:BYE sip:[email protected]:23762 SIP/2.0Via: SIP/2.0/UDP 192.168.70.129:5060;branch=z9hG4bK752a72b1;rportFrom: "101"<sip:[email protected]>;tag=as7b40993aTo: "100"<sip:[email protected]>;tag=6a122732Call-ID: MTM0NDJlNzFiZTY4YTVhN2YwMGMzOWI5OGUzY2I4NmQ.CSeq: 104 BYEUser-Agent: Asterisk PBXMax-Forwards: 70Content-Length: 0

---Scheduling destruction of SIP dialog 'MTM0NDJlNzFiZTY4YTVhN2YwMGMzOWI5OGUzY2I4NmQ.' in 32000 ms (Method: ACK)ngan-desktop*CLI> <--- SIP read from 192.168.70.1:23762 --->SIP/2.0 200 OKVia: SIP/2.0/UDP 192.168.70.129:5060;branch=z9hG4bK752a72b1;rport=5060Contact: <sip:[email protected]:23762>To: "100"<sip:[email protected]>;tag=6a122732From: "101"<sip:[email protected]>;tag=as7b40993aCall-ID: MTM0NDJlNzFiZTY4YTVhN2YwMGMzOWI5OGUzY2I4NmQ.CSeq: 104 BYEUser-Agent: X-Lite release 1104o stamp 56125Content-Length: 0

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

B2BUA là một server mạnh mẽ nhất trong các loại SIP Server. Được sử dụng để hỗ trợ các cuộc gọi điểm điểm và quản lý các cuộc gọi đa điểm.

Chức năng của B2BUA:

- Chức năng tính cược online.- Dịch vụ hội thoại đa điểm.

- IVR

- Tổng đài PBX và Soft Switch.

- Trong suốt với NAT

- Các dịch vụ riêng.

- Ứng dụng cho các cuộc gọi 3 thành phần(3PCC)

- …

Định nghĩa:

IETF định nghĩa B2BUA là một thực thể logic có thể nhận một Request và xử lí Request như một UA. Không giống với Proxy Server, nó sẽ duy trì trạng thái trong suốt quá trình hội thoại trong tất cả các request được gửi trong suốt quá trình hội thoại,

B2BUA quản lý cuộc gọi Point- to- Point

Trong các cuộc gọi Point to Point, B2BUA xử lý các Request nhận được từ UAC như một UAS để quyết định Request có được Respone lại hay không.

Sự khác nhau giữa B2BUA và Proxy Server

B2BUA và Proxy Server có thể cung cấp những chức năng tương tự nhau trong việc quản lý cuộc gọi. Tuy nhiên kiến trúc và khả năng của chúng lại rất khác nhau. Proxy giới hạn việc xử lí các hoạt động trong phiên giao dịch thông qua Proxy trong khi đó B2BUA lại thông minh hơn

Proxy Server được coi như một Stateful. Proxy server rât hiệu quả trong việc thiết lập phiên nhưng lại thụ động khi phiên đã được thiết lập. Proxy có thể hoặc không cho các yêu cầu trong phiên giao dịch thông qua nó.

B2BUA thì hoạt động năng động hơn bởi vì nó hoạt động như một UAC và UAS, vì thế tất cả các phiên phải được thông qua B2BUA.