Implementing Class-5 Telephony Features in SIP

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ới
If 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 means
that 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 the
softphone and Asterisk directly. If the logic we’ve built into Asterisk determines that
you mean to call another user agent, then Asterisk acts as a user agent client and sets
up another connection (known as a channel) to the other phone. The media between
the two phones then flows directly through Asterisk.
‖
From the viewpoint of the
phones, 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:200110508667@b2bua.org;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 '200110508667@b2bua.org;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.net
acctserver 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/1231244226691@172.18.1.197/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:101@192.168.70.129 SIP/2.0

Via: SIP/2.0/UDP 192.168.70.1:23762;branch=z9hG4bK-d8754z-b57ee02a8e25c85f-1---
d8754z-;rport
Max-Forwards: 70
Contact: <sip:100@192.168.70.1:23762>
To: "101"<sip:101@192.168.70.129>
From: "100"<sip:100@192.168.70.129>;tag=6a122732
Call-ID: MTM0NDJlNzFiZTY4YTVhN2YwMGMzOWI5OGUzY2I4NmQ.
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE,
SUBSCRIBE, INFO
Content-Type: application/sdp
User-Agent: X-Lite release 1104o stamp 56125
Content-Length: 364
v=0
o=- 6 2 IN IP4 192.168.70.1
s=CounterPath X-Lite 3.0
c=IN IP4 192.168.70.1
t=0 0
m=audio 44206 RTP/AVP 107 0 8 101
a=alt:1 3 : gpm9O/uP E3VgLHXv 192.168.1.2 44206
a=alt:2 2 : 5bi1qIjn F/H8bZOM 192.168.126.1 44206
a=alt:3 1 : O4tXIsnV way+jzCj 192.168.70.1 44206
a=fmtp:101 0-15
a=rtpmap:107 BV32/16000
a=rtpmap:101 telephone-event/8000
a=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 Required
d8754z-;received=192.168.70.1;rport=23762
From: "100"<sip:100@192.168.70.129>;tag=6a122732
To: "101"<sip:101@192.168.70.129>;tag=as401c60a8
CSeq: 1 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Proxy-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:101@192.168.70.129 SIP/2.0
d8754z-;rport
To: "101"<sip:101@192.168.70.129>;tag=as401c60a8
From: "100"<sip:100@192.168.70.129>;tag=6a122732
CSeq: 1 ACK
Content-Length: 0
<------------->
<--- SIP read from 192.168.70.1:23762 --->

INVITE sip:101@192.168.70.129 SIP/2.0
Via: SIP/2.0/UDP 192.168.70.1:23762;branch=z9hG4bK-d8754z-db4b6a547b3a9f47-
1---d8754z-;rport
Max-Forwards: 70
Contact: <sip:100@192.168.70.1:23762>
To: "101"<sip:101@192.168.70.129>
From: "100"<sip:100@192.168.70.129>;tag=6a122732
CSeq: 2 INVITE
SUBSCRIBE, INFO
Proxy-Authorization: Digest
username="100",realm="asterisk",nonce="1f056cd9",uri="sip:101@192.168.70.129",res
ponse="e6ee3be8c15baa045d83a3de08daa862",algorithm=MD5
Content-Length: 364
v=0
o=- 6 2 IN IP4 192.168.70.1
c=IN IP4 192.168.70.1
t=0 0
m=audio 44206 RTP/AVP 107 0 8 101
a=alt:1 3 : gpm9O/uP E3VgLHXv 192.168.1.2 44206
a=alt:2 2 : 5bi1qIjn F/H8bZOM 192.168.126.1 44206
a=alt:3 1 : O4tXIsnV way+jzCj 192.168.70.1 44206
a=fmtp:101 0-15
a=rtpmap:107 BV32/16000
a=sendrecv
<------------->
Sending to 192.168.70.1 : 23762 (NAT)
Using INVITE request as basis request -
MTM0NDJlNzFiZTY4YTVhN2YwMGMzOWI5OGUzY2I4NmQ.
Found user '100'
Found RTP audio format 107
Peer audio RTP is at port 192.168.70.1:44206
Found unknown media description format BV32 for ID 107
Found audio description format telephone-event for ID 101
Capabilities: 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)
Looking for 101 in internal (domain 192.168.70.129)
list_route: hop: <sip:100@192.168.70.1:23762>
<--- Transmitting (no NAT) to 192.168.70.1:23762 --->

SIP/2.0 100 Trying
1---d8754z-;received=192.168.70.1;rport=23762
From: "100"<sip:100@192.168.70.129>;tag=6a122732
To: "101"<sip:101@192.168.70.129>
CSeq: 2 INVITE
Supported: replaces
Contact: <sip:101@192.168.70.129>
Content-Length: 0
<------------>
-- Executing [101@internal:1] Dial("SIP/100-08210e28", "Sip/101") in new stack
Audio is at 192.168.70.129 port 11444
Adding codec 0x4 (ulaw) to SDP
Adding codec 0x8 (alaw) to SDP
Adding non-codec 0x1 (telephone-event) to SDP
Reliably Transmitting (no NAT) to 192.168.1.2:5060:
INVITE sip:101@192.168.1.2:5060;transport=UDP SIP/2.0
Via: SIP/2.0/UDP 192.168.70.129:5060;branch=z9hG4bK260efc79;rport
From: "100" <sip:100@192.168.70.129>;tag=as2cad8232
To: <sip:101@192.168.1.2:5060;transport=UDP>
Contact: <sip:100@192.168.70.129>
Call-ID: 15b5cdea5b7a8c2256f761672f1dc319@192.168.70.129
CSeq: 102 INVITE
Max-Forwards: 70
Date: Wed, 25 Aug 2010 15:04:49 GMT
Supported: replaces
Content-Length: 266
v=0
o=root 5582 5582 IN IP4 192.168.70.129
s=session
c=IN IP4 192.168.70.129
t=0 0
m=audio 11444 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv
---
-- Called 101
ngan-desktop*CLI>
<--- SIP read from 192.168.1.2:5060 --->
SIP/2.0 100 Trying
Via: SIP/2.0/UDP
192.168.70.129:5060;rport=3482;received=192.168.1.2;branch=z9hG4bK260efc79
To: <sip:101@192.168.1.2>
CSeq: 102 INVITE
Content-Length: 0
<------------->
ngan-desktop*CLI>
<--- SIP read from 192.168.1.2:5060 --->
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP
To: <sip:101@192.168.1.2>;tag=3dd0b5f06a1d41b4a80a8a1bc181d06f
CSeq: 102 INVITE
Contact: <sip:192.168.1.2:5060;transport=UDP>
Content-Length: 0
<------------->
-- SIP/101-08215ae8 is ringing

SIP/2.0 180 Ringing
From: "100"<sip:100@192.168.70.129>;tag=6a122732
To: "101"<sip:101@192.168.70.129>;tag=as7b40993a
CSeq: 2 INVITE
Supported: replaces
Contact: <sip:101@192.168.70.129>
Content-Length: 0
<------------>
ngan-desktop*CLI>
<--- SIP read from 192.168.1.2:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP
CSeq: 102 INVITE
Allow: INVITE, ACK, BYE, CANCEL, SUBSCRIBE, NOTIFY, PUBLISH, REFER,
MESSAGE, OPTIONS
Supported: replaces, norefersub
Content-Length: 239
v=0
o=- 3491762680 3491762681 IN IP4 192.168.1.2
s=session
c=IN IP4 192.168.1.2
t=0 0
m=audio 23000 RTP/AVP 0 101
a=rtcp:23001 IN IP4 192.168.1.2
a=sendrecv
a=fmtp:101 0-15
<------------->
Found audio description format PCMU for ID 0
Capabilities: us - 0xc (ulaw|alaw), peer - audio=0x4 (ulaw)/video=0x0 (nothing),
combined - 0x4 (ulaw)
list_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
to
set_destination: set destination to 192.168.1.2, port 5060
Transmitting (no NAT) to 192.168.1.2:5060:
ACK sip:192.168.1.2:5060;transport=UDP SIP/2.0
Via: SIP/2.0/UDP 192.168.70.129:5060;branch=z9hG4bK4b9f79d7;rport
To:
<sip:101@192.168.1.2:5060;transport=UDP>;tag=3dd0b5f06a1d41b4a80a8a1bc181d06f
Contact: <sip:100@192.168.70.129>
CSeq: 102 ACK
Max-Forwards: 70
Content-Length: 0
---
-- SIP/101-08215ae8 answered SIP/100-08210e28
Audio is at 192.168.70.129 port 15894
Adding codec 0x8 (alaw) to SDP
<--- Reliably Transmitting (no NAT) to 192.168.70.1:23762 --->

SIP/2.0 200 OK
From: "100"<sip:100@192.168.70.129>;tag=6a122732
To: "101"<sip:101@192.168.70.129>;tag=as7b40993a
CSeq: 2 INVITE
Supported: replaces
Contact: <sip:101@192.168.70.129>
Content-Length: 266
v=0
o=root 5582 5582 IN IP4 192.168.70.129
s=session
c=IN IP4 192.168.70.129
t=0 0
m=audio 15894 RTP/AVP 0 8 101
a=rtpmap:8 PCMA/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv
<------------>
-- Native bridging SIP/100-08210e28 and SIP/101-08215ae8
to
Audio is at 192.168.70.129 port 11444
INVITE sip:192.168.1.2:5060;transport=UDP SIP/2.0
Via: SIP/2.0/UDP 192.168.70.129:5060;branch=z9hG4bK704c3ce6;rport
To:
Contact: <sip:100@192.168.70.129>
CSeq: 103 INVITE
Max-Forwards: 70
Supported: replaces
X-asterisk-Info: SIP re-invite (External RTP bridge)
Content-Length: 238
v=0
o=root 5582 5583 IN IP4 192.168.70.1
s=session
c=IN IP4 192.168.70.1
t=0 0
a=fmtp:101 0-16
a=ptime:20
a=sendrecv
---
ngan-desktop*CLI>
<--- SIP read from 192.168.70.1:23762 --->
ACK sip:101@192.168.70.129 SIP/2.0
Via: SIP/2.0/UDP 192.168.70.1:23762;branch=z9hG4bK-d8754z-b31688467b0ca107-
1---d8754z-;rport
Max-Forwards: 70
Contact: <sip:100@192.168.70.1:23762>
To: "101"<sip:101@192.168.70.129>;tag=as7b40993a
From: "100"<sip:100@192.168.70.129>;tag=6a122732
CSeq: 2 ACK
Proxy-Authorization: Digest
username="100",realm="asterisk",nonce="1f056cd9",uri="sip:101@192.168.70.129",res
ponse="e6ee3be8c15baa045d83a3de08daa862",algorithm=MD5
Content-Length: 0
<------------->
set_destination: Parsing <sip:100@192.168.70.1:23762> for address/port to send to
Audio is at 192.168.70.129 port 15894
INVITE sip:100@192.168.70.1:23762 SIP/2.0
Via: SIP/2.0/UDP 192.168.70.129:5060;branch=z9hG4bK2f4d62bb;rport
From: "101"<sip:101@192.168.70.129>;tag=as7b40993a
To: "100"<sip:100@192.168.70.129>;tag=6a122732
Contact: <sip:101@192.168.70.129>
CSeq: 102 INVITE
Max-Forwards: 70
Supported: replaces
Content-Length: 236
v=0
o=root 5582 5583 IN IP4 192.168.1.2
s=session
c=IN IP4 192.168.1.2
t=0 0
a=fmtp:101 0-16
a=ptime:20
a=sendrecv
---
ngan-desktop*CLI>
<--- SIP read from 192.168.70.1:23762 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.70.129:5060;branch=z9hG4bK2f4d62bb;rport=5060
Contact: <sip:100@192.168.70.1:23762>
To: "100"<sip:100@192.168.70.129>;tag=6a122732
From: "101"<sip:101@192.168.70.129>;tag=as7b40993a
CSeq: 102 INVITE
SUBSCRIBE, INFO
Content-Length: 183
v=0
o=- 6 3 IN IP4 192.168.70.1
c=IN IP4 192.168.70.1
t=0 0
a=fmtp:101 0-15
a=sendrecv
<------------->
Capabilities: us - 0x4 (ulaw), peer - audio=0x4 (ulaw)/video=0x0 (nothing), combined -
0x4 (ulaw)
ACK sip:100@192.168.70.1:23762 SIP/2.0
Via: SIP/2.0/UDP 192.168.70.129:5060;branch=z9hG4bK6cb757d8;rport
From: "101"<sip:101@192.168.70.129>;tag=as7b40993a
To: "100"<sip:100@192.168.70.129>;tag=6a122732
Contact: <sip:101@192.168.70.129>
CSeq: 102 ACK
Max-Forwards: 70
Content-Length: 0
---
ngan-desktop*CLI>
<--- SIP read from 192.168.1.2:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP
192.168.70.129:5060;rport=3482;received=192.168.1.2;branch=z9hG4bK704c3ce6
CSeq: 103 INVITE
Allow: INVITE, ACK, BYE, CANCEL, SUBSCRIBE, NOTIFY, PUBLISH, REFER,
MESSAGE, OPTIONS
Supported: replaces, norefersub
Content-Length: 239
v=0
o=- 3491762683 3491762682 IN IP4 192.168.1.2
s=session
c=IN IP4 192.168.1.2
t=0 0
a=rtcp:23001 IN IP4 192.168.1.2
a=sendrecv
a=fmtp:101 0-15
<------------->
Found audio description format PCMU for ID 0
Capabilities: us - 0xc (ulaw|alaw), peer - audio=0x4 (ulaw)/video=0x0 (nothing),
combined - 0x4 (ulaw)
to
ACK sip:192.168.1.2:5060;transport=UDP SIP/2.0
Via: SIP/2.0/UDP 192.168.70.129:5060;branch=z9hG4bK41ab1bfe;rport
To:
Contact: <sip:100@192.168.70.129>
CSeq: 103 ACK
Max-Forwards: 70
Content-Length: 0
---
ngan-desktop*CLI>
<--- SIP read from 192.168.70.1:5060 --->
BYE sip:100@192.168.70.129 SIP/2.0
Via: SIP/2.0/UDP
192.168.1.2:5060;rport;branch=z9hG4bKPj04eed753bf4e4a3ab357ca325d6c0278
Max-Forwards: 70
From: <sip:101@192.168.1.2>;tag=3dd0b5f06a1d41b4a80a8a1bc181d06f
To: "100" <sip:100@192.168.70.129>;tag=as2cad8232
CSeq: 1674275836 BYE
User-Agent: VidoSIP/1.5
Content-Length: 0
<------------->
Sending to 192.168.70.1 : 5060 (NAT)
<--- Transmitting (NAT) to 192.168.70.1:5060 --->

SIP/2.0 200 OK
Via: SIP/2.0/UDP
192.168.1.2:5060;branch=z9hG4bKPj04eed753bf4e4a3ab357ca325d6c0278;received=19
2.168.70.1;rport=5060
From: <sip:101@192.168.1.2>;tag=3dd0b5f06a1d41b4a80a8a1bc181d06f
To: "100" <sip:100@192.168.70.129>;tag=as2cad8232
CSeq: 1674275836 BYE
Supported: replaces
Contact: <sip:100@192.168.70.129>
Content-Length: 0
<------------>
Audio is at 192.168.70.129 port 15894
INVITE sip:100@192.168.70.1:23762 SIP/2.0
Via: SIP/2.0/UDP 192.168.70.129:5060;branch=z9hG4bK2a7461d3;rport
From: "101"<sip:101@192.168.70.129>;tag=as7b40993a
To: "100"<sip:100@192.168.70.129>;tag=6a122732
Contact: <sip:101@192.168.70.129>
CSeq: 103 INVITE
Max-Forwards: 70
Supported: replaces
Content-Length: 242
v=0
o=root 5582 5584 IN IP4 192.168.70.129
s=session
c=IN IP4 192.168.70.129
t=0 0
a=fmtp:101 0-16
a=ptime:20
a=sendrecv
---
== Spawn extension (internal, 101, 1) exited non-zero on 'SIP/100-08210e28'
(Method: ACK)
<--- SIP read from 192.168.70.1:5060 --->

REGISTER sip:192.168.70.129:5060 SIP/2.0
Via: SIP/2.0/UDP
192.168.1.2:5060;rport;branch=z9hG4bKPjb0b2109116e94409b6724d1e2b7d9d61
Max-Forwards: 70
From: <sip:101@192.168.70.129>;tag=203c01ed87fd450b998ab892d7e5ddb9
To: <sip:101@192.168.70.129>
Call-ID: a052a313dd01423bacf93e7054fe12a8
CSeq: 18 REGISTER
Contact: <sip:101@192.168.1.2:5060;transport=UDP>;methods="INVITE, INFO,
OPTIONS, BYE, CANCEL, ACK"
Expires: 600
Content-Length: 0
<------------->
Using latest REGISTER request as basis request
Sending to 192.168.70.1 : 5060 (NAT)

SIP/2.0 100 Trying
Via: SIP/2.0/UDP
192.168.1.2:5060;branch=z9hG4bKPjb0b2109116e94409b6724d1e2b7d9d61;received=1
92.168.70.1;rport=5060
To: <sip:101@192.168.70.129>
CSeq: 18 REGISTER
Supported: replaces
Contact: <sip:101@192.168.70.129>
Content-Length: 0
<------------>

SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP
192.168.1.2:5060;branch=z9hG4bKPjb0b2109116e94409b6724d1e2b7d9d61;received=1
92.168.70.1;rport=5060
To: <sip:101@192.168.70.129>;tag=as0a628145
CSeq: 18 REGISTER
Supported: replaces
WWW-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 '15b5cdea5b7a8c2256f761672f1dc319@192.168.70.129'
Method: BYE
<--- SIP read from 192.168.70.1:5060 --->

REGISTER sip:192.168.70.129:5060 SIP/2.0
Via: SIP/2.0/UDP
192.168.1.2:5060;rport;branch=z9hG4bKPj380b5eaa086348d4a683e8bfbf90c75c
Max-Forwards: 70
To: <sip:101@192.168.70.129>
CSeq: 19 REGISTER
Contact: <sip:101@192.168.1.2:5060;transport=UDP>;methods="INVITE, INFO,
OPTIONS, BYE, CANCEL, ACK"
Expires: 600
Authorization: Digest username="101", realm="asterisk", nonce="22844f1e",
uri="sip:192.168.70.129:5060", response="689bb0c816c6ffa9e2d4dc2e9917a61a",
algorithm=md5
Content-Length: 0
<------------->
Using latest REGISTER request as basis request
Sending to 192.168.70.1 : 5060 (NAT)

SIP/2.0 100 Trying
Via: SIP/2.0/UDP
192.168.1.2:5060;branch=z9hG4bKPj380b5eaa086348d4a683e8bfbf90c75c;received=19
2.168.70.1;rport=5060
To: <sip:101@192.168.70.129>
CSeq: 19 REGISTER
Supported: replaces
Contact: <sip:101@192.168.70.129>
Content-Length: 0
<------------>
ngan-desktop*CLI>
SIP/2.0 200 OK
Via: SIP/2.0/UDP
192.168.1.2:5060;branch=z9hG4bKPj380b5eaa086348d4a683e8bfbf90c75c;received=19
2.168.70.1;rport=5060
To: <sip:101@192.168.70.129>;tag=as0a628145
CSeq: 19 REGISTER
Supported: replaces
Expires: 600
Contact: <sip:101@192.168.1.2:5060;transport=UDP>;expires=600
Date: Wed, 25 Aug 2010 15:04:53 GMT
Content-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 OK
Via: SIP/2.0/UDP 192.168.70.129:5060;branch=z9hG4bK2a7461d3;rport=5060
Contact: <sip:100@192.168.70.1:23762>
To: "100"<sip:100@192.168.70.129>;tag=6a122732
From: "101"<sip:101@192.168.70.129>;tag=as7b40993a
CSeq: 103 INVITE
SUBSCRIBE, INFO
Content-Length: 183
v=0
o=- 6 3 IN IP4 192.168.70.1
c=IN IP4 192.168.70.1
t=0 0
a=fmtp:101 0-15
a=sendrecv
<------------->
Capabilities: us - 0x4 (ulaw), peer - audio=0x4 (ulaw)/video=0x0 (nothing), combined -
0x4 (ulaw)
ACK sip:100@192.168.70.1:23762 SIP/2.0
Via: SIP/2.0/UDP 192.168.70.129:5060;branch=z9hG4bK11a6317c;rport
From: "101"<sip:101@192.168.70.129>;tag=as7b40993a
To: "100"<sip:100@192.168.70.129>;tag=6a122732
Contact: <sip:101@192.168.70.129>
CSeq: 103 ACK
Max-Forwards: 70
Content-Length: 0
---
BYE sip:100@192.168.70.1:23762 SIP/2.0
Via: SIP/2.0/UDP 192.168.70.129:5060;branch=z9hG4bK752a72b1;rport
From: "101"<sip:101@192.168.70.129>;tag=as7b40993a
To: "100"<sip:100@192.168.70.129>;tag=6a122732
CSeq: 104 BYE
Max-Forwards: 70
Content-Length: 0
---
(Method: ACK)
ngan-desktop*CLI>
<--- SIP read from 192.168.70.1:23762 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.70.129:5060;branch=z9hG4bK752a72b1;rport=5060
Contact: <sip:100@192.168.70.1:23762>
To: "100"<sip:100@192.168.70.129>;tag=6a122732
From: "101"<sip:101@192.168.70.129>;tag=as7b40993a
CSeq: 104 BYE
Content-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.

Implementing Class-5 Telephony Features in SIP

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Implementing Class-5 Telephony Features in SIP

Uploaded by

Copyright:

Available Formats

Implementing Class-5 Telephony features in SIP

Can a SIP Proxy do the job?

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

Issues in B2BUA functionality

Development with B2BUA

This B2BUA functionality provides major new applications including:

• centralized call management

Figure 2: Third Party Call Control

Interworking with alternative networks

SIP--based VoIP interworking between LAN and WAN

In order to implement such functionality in SIP A B2BUA is required because it needs to

Management and monitoring of the entire call state

Cloaking of endpoint location.

- SIP UA trả lời cuộc gọi.

Figure 1 — B2BUA High Level Architecture

This architecture allows implementing different functionality by replacing the Call

Typicall Call Process ¶

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

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

Figure 5 — Endpoints receiving RTP Media

13. The session ends.

To invoke the B2BUA use the following command:

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

python b2bua_simple.py -l 192.168.0.15 -n 192.168.1.25

• SIPLOG_BEND – specifies which method of reporting to use. Available methods

• cld - CLD to be used for the outgoing call

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

b2bua_radius.py ... -s '200110508667@b2bua.org;cli=16046288900;rid=-

For radiusclient-ng you should do the following:

• Install radiusclent-ng from source

~# tar xvfz radiusclient-ng-X.Y.Z.tar.gz

• Edit /usr/local/etc/radiusclient-ng/radiusclient.conf and set address of

• Include dictionary included in sippy b2bua dist into radiusclient-ng by copying

How to install and configure RADIUS server?

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

There are two possible reasons for this negative response:

07 Jan 19:51:55/1231244226691@172.18.1.197/b2bua: Error sending AAA

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

All conversation is between client1 <-> sip_server <-> client2,

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

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

INVITE sip:101@192.168.70.129 SIP/2.0

<--- SIP read from 192.168.70.1:23762 --->

<--- SIP read from 192.168.70.1:23762 --->

<--- Transmitting (no NAT) to 192.168.70.1:23762 --->

<--- Transmitting (no NAT) to 192.168.70.1:23762 --->

<--- Reliably Transmitting (no NAT) to 192.168.70.1:23762 --->

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

<--- SIP read from 192.168.70.1:5060 --->

<--- Transmitting (no NAT) to 192.168.1.2:5060 --->

<--- Transmitting (no NAT) to 192.168.1.2:5060 --->

<--- SIP read from 192.168.70.1:5060 --->

<--- Transmitting (no NAT) to 192.168.1.2:5060 --->

Chức năng của B2BUA:

- Chức năng tính cược online.

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

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

You might also like