TD 92685EN
28 June 2012 / Ver. A
Troubleshooting Guide
Ascom i62 VoWiFi Handset
44
6. Troubleshooting
6.1.2 PBX Basic Call Analysis
A more common architecture than the RFC example describe
d in section 6.1.1 Attended
Transfer Example on page
40 above is a network architecture that relays calls between two
or more parties via an IP-PBX, which may also be called a Back-to-Back User
Agent (B2BUA).
It is this kind of scenario where a detailed knowledge of a call flow is required because a PBX
performs functions that a proxy does not perform, such as hiding the identity of the initiator
of the call from the destination, enabling header modification and SDP manipulation of
codecs, media IP and Port, and so on.
A B2BUA acts as an endpoint to the calling party and then creates a new ca
ll to the called
party. The B2BUA therefore is an intermediate point in the call between remote endpoints.
The PBX contains functions to manage and control the call between the remote endpoints.
Other SIP functions, for example when calls are tr
ansferred to an additional party using
REFER, involve additional PBX functionality.
A call established through a PBX requires that a s
ignaling connection initially be established
by the calling party to the PBX and then for the PBX to establish a connection to the called
party. From a SIP perspective, there are two different calls established with two different
Call-IDs.
The following is a real-life example of a basic SIP call
setup via a PBX where:
• The calling party has the extension of 9910.
•
The called party has the extension 9920.
• A SIP server has the IP address of 10.11.24.244. The server functions as a
registrar and
defines the locations of users registered with it, for example 9910@10.11.24.244 and
9920@10.11.24.244.
•
The first call has the Call-ID of **4af6 and the second call a Call-ID of **02fd.
To facilitate the analysis of the call flow, the handse
t needs to be setup to support Remote
Packet Capture (RPCAP) logging and a trace is taken using Wireshark. For additional
information, see Appendix D.2.
Note that for the sake of clarity in the following example, only th
e last four characters of the
call ids are used.The asterisks denote the excluded part of the respective Call-IDs.
After these calls have been setup, RTP streams are transmitted from Party 9910 to Party
9920 and vice versa via the P
BX.
The first call setup is established with an INVITE from the calling party to the called party,
and the creation of the call ID **4af6 bet
ween the calling party and the PBX:
INVITE sip:9920@10.11.24.244
From: "9910"<sip:9910@10.11.24.244>;epid=00013e124af6;
tag=2363920757
To: <sip:9920@10.11.24.244;user=phone>
Call ID: ab5e5a3de909d311b77400013e124af6@10.11.24.177
P-Preferred-Identity: "9910" <sip:9910@10.11.24.244;user=phone>
Referred-by <sip: user2@serverb.com>
The P-Preferred-Identity header field is used from a user agent to the PBX to ca
rry th
e
identity the user sending the SIP message wishes to be used for the P-Asserted-Header field
value that the PBX will insert. Using this method the PBX can indicate what identity should
be presented to the called party and what identity should be used for authenticating the
call. This feature is also useful when the PBX redirects an incoming call to a PSTN number, for
example a cell phone, to preserve the original Caller ID.
In the next message, the PBX issues a Proxy-Authent
i
cate header consisting of a challenge
that indicates the authentication scheme and parameters applicable to the proxy:
SIP/2.0 407 Proxy Authentication Required
To Next Page
Loading...
Need help?
General
