TROUBLESHOOTING MANUAL

INTRODUCTION:
SIP: Session Initiation Protocol

PROXY, PROXY SERVER

An intermediary entity that acts as both a server and a client for the purpose of making
requests on behalf of other clients.

A proxy server primarily plays the role of routing, which means its job is to ensure that a
request is sent to another entity "closer" to the targeted user.

Proxies are also useful for enforcing policy (for example, making sure a user is allowed to
make a call). A proxy interprets, and, if necessary, rewrites specific parts of a request
message before forwarding it.

STATEFUL PROXY
A logical entity that maintains the client and server transaction state machines defined by
specification during the processing of a request, also known as a transaction stateful proxy.
A (transaction) stateful proxy is not the same as a call stateful proxy.

FORKING PROXY
A proxy server can send a request (say INVITE) to a number of locations at the same time.
This type of parallel search is known as FORKING. A Forking Proxy must be a Stateful Proxy.

STATELESS PROXY
A logical entity that does not maintain the client or server transaction state machines
defined in specification when it processes requests.

A stateless proxy forwards every request it receives downstream and every response it
receives upstream.

REDIRECT SERVER
A redirect server is a user agent server that generates 3xx responses to requests it receives,
directing the client to contact an alternate set of URIs.

SUPPORTDOCUMENT

PAGE 1
 TROUBLESHOOTING MANUAL
REGISTRAR
A registrar is a server that accepts REGISTER requests and places the information it
receives in those requests into the location service for the domain it handles.

USER AGENT(UA)
A logical entity that can act as both a user agent client and user agent server.

USER AGENT CLIENT(UAC):

A user agent client is a logical entity that creates a new request, and then uses the client
transaction state machinery to send it. The role of UAC lasts only for the duration of that
transaction. If it receives a request later, it assumes the role of a user agent server for the
processing of that transaction.

USER AGENT SERVER (UAS):

A user agent server is a logical entity that generates a response to a SIP request. The
response accepts, rejects, or redirects the request. This role lasts only for the duration of
that transaction. If it generates a request later, it assumes the role of a user agent client for
the processing of that transaction.

LOCATION SERVICE
A location service is used by a SIP redirect or proxy server to obtain information about a
callee’s possible location(s). It contains a list of bindings of address-of record keys to zero
or more contact addresses.

REQUEST
A SIP message sent from a client to a server, for the purpose of invoking a particular
operation.

SIP requests are distinguished by having a Request-Line for a start line. A Request-Line
contains a method name, a Request-URI, and the protocol version separated by a single
space (SP) character.

Request-Line = Method SP Request-URI SP SIP-Version CRLF

SUPPORTDOCUMENT

PAGE 2
 TROUBLESHOOTING MANUAL
REGISTER
The REGISTER requests add, remove, and query bindings. A REGISTER request can add a
new binding between an address-of-record and one or more contact addresses. A REGISTER
request does not establish a dialog.

OPTIONS
The SIP method OPTIONS allows a UA to query another UA or a proxy server as to its
capabilities. This allows a client to discover information about the supported methods,
content types, extensions, codecs, etc. without "ringing" the other party.

An OPTIONS request MAY be sent as part of an established dialog to query the peer on
capabilities that may be utilized later in the dialog.

INVITE
The INVITE method is the only way to establish a dialog. It indicates that the user or service
is being invited to participate in a session. The message body may contain a description of
the session to which the callee is being invited.

ACK
The ACK request confirms that the client has received a final response to an INVITE request.
(ACK is used only with INVITE requests.) 2xx responses are acknowledged by client user
agents, all other final responses by the first proxy or client user agent to receive the
response.

BYE
The user agent client uses BYE to indicate to the server that it wishes to release the call. A
BYE request is forwarded like an INVITE request and MAY be issued by either caller or callee.

A party to a call SHOULD issue a BYE request before releasing a call ("hanging up"). A party
receiving a BYE request MUST cease transmitting media streams specifically directed at the
party issuing the BYE request.

SUPPORTDOCUMENT

PAGE 3
 TROUBLESHOOTING MANUAL
CANCEL
The CANCEL request MUST be used to cancel the preconnected call, which is in Calling /
Ringing state.

The CANCEL request cancels a pending request with the same Call-ID, To, From and CSeq
(sequence number only) header field values, but does not affect a completed request. (A
request is considered completed if the server has returned a final status response).

The CANCEL request can be used to cancel branches of a parallel search, since several
branches may, through intermediate proxies, find the same user agent server and then
terminate the call.

REFER
The REFER method indicates that the recipient (identified by the Request-URI) should
contact a third party using the contact information provided in the request. Unless stated
otherwise, the protocol for emitting and responding to a REFER request are identical to
those for a BYE request

RESPONSE
A SIP message sent from a server to a client, for indicating the status of a request sent
from the client to the server

SIP responses are distinguished from requests by having a Status-Line as their start-line. A
Status-Line consists of the protocol version followed by a numeric Status-Code and its
associated textual phrase, with each element separated by a single SP character.

Status-Line = SIP-Version SP Status-Code SP Reason-Phrase CRLF

1xx: PROVISIONAL
Request received, continuing to process the request.

Provisional responses, also known as informational responses, indicate that the server
contacted is performing some further action and does not yet have a definitive response. A

SUPPORTDOCUMENT

PAGE 4
 TROUBLESHOOTING MANUAL
server sends a 1xx response if it expects to take more than 200 ms to obtain a final
response.

100 Trying
This response indicates that the request has been received by the next-hop server
and that some unspecified action is being taken on behalf of this call.

180 Ringing
The UA receiving the INVITE is trying to alert the user. This response MAY be used to
initiate local ringback.

183 Session Progress :

The 183 (Session Progress) responses is used to convey information about the
progress of the call that is not otherwise classified. The Reason-Phrase, header fields,
or message body MAY be used to convey more details about the call progress.

2xx: SUCCESS
The action was successfully received, understood, and accepted.

200 OK
The request has succeeded. The information returned with the response depends on
the method used in the request.

3xx: REDIRECTION
Further action needs to be taken in order to complete the request. The 3xx responses give
information about the user’s new location, or about alternative services that might be able
to satisfy the call.

4xx: CLIENT ERROR

The request contains bad syntax or cannot be fulfilled at this server. The 4xx responses are
definite failure responses from a particular server. The client SHOULD NOT retry the same
request without modification (for example, adding appropriate authorization).

SUPPORTDOCUMENT

PAGE 5
 TROUBLESHOOTING MANUAL
400 Bad Request
In cases if the Request is invalid then this error will be returned.

401 Unauthorized
Used only by registrars. This is will be returned if the subscriberID is Invalid.

403 Forbidden
If there is no balance, invalid billing plan and if there is no Rights available.

404 Not Found

If GW's are not configured and user doesn't exist in Proxy

407 Proxy Authentication Required

User not registered.

415 Unsupported Media Type

If the codec negatiotation is failed, or invalid codec

423 Interval Too Brief

If the Register Timeout interval is low in Device settings.

486 Busy Here

Callee is Busy.

487 Request Terminated

if the caller hangup the call.

5xx: SERVER ERROR

The server failed to fulfill an apparently valid request. The 5xx responses are failure
responses given when a server itself has erred.
500 Server Internal Error

501 Not Implemented

The SIP request method is not implemented here

502 Bad Gateway

503 Service Unavailable

504 Server Time-out

6xx: GLOBAL FAILURE

The request cannot be fulfilled at any server. The 6xx responses indicate that a server has
definitive information about a particular user, not just the particular instance indicated in
the Request-URI.
SUPPORTDOCUMENT

PAGE 6
 TROUBLESHOOTING MANUAL

600 Busy Everywhere

603 Decline
604 Does Not Exist Anywhere
606 Not Acceptable

SUPPORTDOCUMENT

PAGE 7
 TROUBLESHOOTING MANUAL
Description of Log files and its location:

All the logs will be rotated on an hourly basis, so if any thing to be searched related to the
on going call then you need to edit the current hour log.

SIPProxy

Location: /voip/SIPProxy/Logs
Log File name: Call-ddmmyy-hh.log , Progress-ddmmyyyy-hh.log, Error-ddmmyyyy-
hh.log and IPDR-ddmmyyyy-hh.log

Ex: Call-19May2006-23.log, Progress-19May2006-23.log, Error-19May2006-23.log,

IPDR-19May2006-23.log.

MediaServer

Location: /voip/MediaServer/Logs
Log File name: IVRProgress-ddmmyyyy-hh.log and IVRError-ddmmyyyy-hh.log

Ex: IVRProgress-19May2006-23.log and IVRError-19May2006-23.log

For tracing the logs you need to be comfortable with vi, tail and grep commands.
Details about this can viewed in the site or in UNXI server using “man” command. If
you do “man vi” in UNXI it will give you various option available in vi. Similarly you
can find help for all the UNIX commands.

Find below is the Call log and Progress log for successful call. For every call the
syntax will look similar to that. This will change based on the scenario. For every call
there will be a uniquecallid, to trace the call you need to take the uniquecallid and match
it with the Call log to get minimum information, to need to get more details then check in
Progress log. By doing so we will get the exact issue related to it.

Example of SIP Call Log for Successful Call:

[email protected]; 2006 May 18 11:0:1; 1565663194;

61.246.199.9/61.246.199.9; SIP; 19033348784; ; ; ;INVITE Received;

UniqueCallID SIP Messages

Destination Number Caller Number

SUPPORTDOCUMENT

PAGE 8
 TROUBLESHOOTING MANUAL

[email protected]; 2006 May 18 11:0:1; 1565663194;

61.246.199.9/61.246.199.9; SIP; 19033348784; ; ; Prefix Matching;MATCHED;

[email protected]; 2006 May 18 11:0:1; 1565663194;

61.246.199.9/61.246.199.9; SIP; 19033348784; Route Selection; 19033348784; Matched
Routes;Net2Phone, Net2Phone, ;

[email protected]; 2006 May 18 11:0:1; 1565663194;

61.246.199.9/61.246.199.9; SIP; 19033348784; Route Selection; 19033348784; Adding-
Tech-Prefix;19033348784;

[email protected]; 2006 May 18 11:0:2; 1565663194;

61.246.199.9/61.246.199.9; SIP; 19033348784; Authorizing; 19033348784; Authorized

[email protected]; 2006 May 18 11:0:11; 1565663194;

61.246.199.9/61.246.199.9; SIP; 19033348784; Authorized; 19033348784; Trying
Net2Phone;Session Progress;

[email protected]; 2006 May 18 11:0:12; 1565663194;

61.246.199.9/61.246.199.9; SIP; 19033348784; Authorized; 19033348784; Trying
Net2Phone;Connected;

[email protected]; 2006 May 18 11:0:27; 1565663194;

61.246.199.9/61.246.199.9; SIP; 19033348784; Authorized; 19033348784; Callee
Disconnecting; Disconnected;

Example of SIP Progress Log for Successful Call:

INVITE sip:[email protected] SIP/2.0

Content-Length: 187
Max-Forwards: 70
From: <sip:[email protected]>;tag=1146760531974
Contact: <sip:[email protected]>
Allow: REGISTER,OPTIONS,INVITE,ACK,CANCEL,BYE,INFO
To: <sip:[email protected]>
Content-Type: application/sdp
Via: SIP/2.0/UDP 203.115.71.75:41025;branch=z9hG4bK1146760531974
CSeq: 1 INVITE
Call-ID: [email protected] UniqueCallID

v=0
o=999881 1234 120 IN IP4 202.164.39.58
s=- This is SDP(Session Description
c=IN IP4 202.164.39.58 Protocol) message which contains
t=3355749331 0 callers RTP port, supporting codec
m=audio 20004 RTP/AVP 4 18 0 and Media transporting IP address.
a=RTPMAP:4 G723/8000
a=RTPMAP:18 G729/8000
a=RTPMAP:0 PCMU/8000
SUPPORTDOCUMENT

PAGE 9
 TROUBLESHOOTING MANUAL
[Select GW] CallerName: 999881
[Select GW] CalleeName: 13033372500
2006-05-04 22:05:32.146 - Progress [email protected] 999881 13033372500
INVITE -1 JBoss-Authorized
Application Server authorize the call to proceed
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 203.115.71.75:5060;branch=z9hG4bK1146760531979,SIP/2.0/UDP
203.115.71.75:41025;branch=z9hG4bK1146760531974
From: <sip:[email protected]>;tag=1146760531974
To: <sip:[email protected]:5060>;tag=FD6B8B40-1AC8
Date: Thu, 04 May 2006 14:30:39 GMT
Call-ID: [email protected]
Server: Cisco-SIPGateway/IOS-12.x
CSeq: 1 INVITE
Allow-Events: telephone-event
Content-Length: 0

SIP/2.0 183 Session Progress

Via: SIP/2.0/UDP 203.115.71.75:5060;branch=z9hG4bK1146760531979,SIP/2.0/UDP
203.115.71.75:41025;branch=z9hG4bK1146760531974
From: <sip:[email protected]>;tag=1146760531974
To: <sip:[email protected]:5060>;tag=FD6B8B40-1AC8
Date: Thu, 04 May 2006 14:30:39 GMT
Call-ID: [email protected]
Server: Cisco-SIPGateway/IOS-12.x
CSeq: 1 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO, UPDATE,
REGISTER
Allow-Events: telephone-event
Contact: <sip:[email protected]:5060>
Content-Disposition: session;handling=required
Content-Type: application/sdp
Content-Length: 199

v=0
o=CiscoSystemsSIP-GW-UserAgent 3991 1544 IN IP4 69.90.169.20

s=SIP Call
This is SDP message which
c=IN IP4 69.90.169.20
contains caller information like RTP
t=0 0
port, supporting codec and Media IP
m=audio 18034 RTP/AVP 4
address.
c=IN IP4 69.90.169.20
a=rtpmap:4 G723/8000
a=fmtp:4 annexa=no

SIP/2.0 200 OK
Via: SIP/2.0/UDP 203.115.71.75:5060;branch=z9hG4bK1146760531979,SIP/2.0/UDP
203.115.71.75:41025;branch=z9hG4bK1146760531974
From: <sip:[email protected]>;tag=1146760531974
To: <sip:[email protected]:5060>;tag=FD6B8B40-1AC8
Date: Thu, 04 May 2006 14:30:39 GMT
Call-ID: [email protected]
Server: Cisco-SIPGateway/IOS-12.x
CSeq: 1 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO, UPDATE,
REGISTER
Allow-Events: telephone-event
Contact: <sip:[email protected]:5060>
Content-Type: application/sdp
Content-Length: 199

v=0
This is SDP message which
SUPPORTDOCUMENT
contains callee information like RTP

PAGE 10
port, supporting codec and Media IP
address.
 TROUBLESHOOTING MANUAL
o=CiscoSystemsSIP-GW-UserAgent 3991 1544 IN IP4 69.90.169.20
s=SIP Call
c=IN IP4 69.90.169.20
t=0 0
m=audio 18034 RTP/AVP 4
c=IN IP4 69.90.169.20
a=rtpmap:4 G723/8000
a=fmtp:4 annexa=no

ACK sip:[email protected] SIP/2.0

Via: SIP/2.0/UDP 203.115.71.75:41025;branch=z9hG4bK1146760531974
Content-Length: 187
Acknowledgment given
Max-Forwards: 70
by the caller to start the
From: <sip:[email protected]>;tag=1146760531974
conversation. After this message
Contact: <sip:[email protected]>
RTP flow between the caller and
Allow: REGISTER,OPTIONS,INVITE,ACK,CANCEL,BYE,INFO
callee device.
To: <sip:[email protected]>;tag=FD6B8B40-1AC8
Content-Type: application/sdp
CSeq: 1 ACK
Call-ID: [email protected]

v=0
o=999881 1234 120 IN IP4 202.164.39.58
s=-
c=IN IP4 202.164.39.58
t=3355749331 0
m=audio 20004 RTP/AVP 4 18 0
a=RTPMAP:4 G723/8000
a=RTPMAP:18 G729/8000
a=RTPMAP:0 PCMU/8000

2006-05-04 22:05:41.002 - Progress [email protected] 999881 13033372500 ACK

-1 CONNECTED

BYE sip:[email protected] SIP/2.0

Max-Forwards: 70
From: <sip:[email protected]>;tag=1146760531974
To: <sip:[email protected]>;tag=FD6B8B40-1AC8
Via: SIP/2.0/UDP 203.115.71.75:41025;branch=z9hG4bK1146760531974
CSeq: 2 BYE
Call-ID: [email protected]
Content-Length: 0

2006-05-04 22:05:48.505 - Progress [email protected] 999881 13033372500 BYE

-1 DISCONNECTING
2006-05-04 22:05:48.505 - 85 - Request processed : BYE [email protected] true
2006-05-04 22:05:48.825 - 63 - The message received(Raw message before parsing) is :

SIP/2.0 200 OK
Via: SIP/2.0/UDP 203.115.71.75:5060;branch=z9hG4bK1146760531979,SIP/2.0/UDP
203.115.71.75:41025;branch=z9hG4bK1146760531974
From: <sip:[email protected]>;tag=1146760531974
To: <sip:[email protected]:5060>;tag=FD6B8B40-1AC8
Date: Thu, 04 May 2006 14:30:55 GMT
Call-ID: [email protected]
Server: Cisco-SIPGateway/IOS-12.x
Content-Length: 0
CSeq: 2 BYE

Note:

SUPPORTDOCUMENT

PAGE 11
 TROUBLESHOOTING MANUAL
As mentioned, the above logs of Call Log and Progress Log is for successful call. If the call
fails then based the failure cause the log will show the appropriate error message.

Case: Registration is not happening

1. Login to the CLI interface and check whether the account id is registered or not. This
can be done by logging in to the CLI prompt and by providing appropriate option.
# telnet <sip proxy server IP> 50000
2. If the device is registered then it will be shown in registered user list in CLI.
3. To make sure registration is hitting the SIPProxy or not. Login to CLI as mentioned
above and check whether request is reaching SIPProxy. If it is reaching then you find
log similar to the one given below.
[email protected]; 2006 Aug 16 06:26:26;
1624803954537; 202.133.60.239/202.133.60.239; SIP; ; ; ;
REGISTER;REGISTERED;
4. If the device is not registered then check the connectivity between the device and
SIPProxy.
5. If the connectivity is proper and still the device is not registered, make sure the
device configuration is proper.
6. If the device configuration is proper and still it is not registering, check SIPProxy is
responding or not. If not refer to the maintenance document for restarting the
process.

Case: Calls are not going through

If the subscribers are from Media Gateway then check the following

1. Once the subscriber makes a call from his PSTN phone, if there is engaged tone.
Make sure that E1 connectivity between PSTN Switch and MediaGW is properly
established.
2. If the connectivity is proper and still calls is not going through. Then check IP
connectivity between MediaGW and SIPProxy. This can be checked by executing
Ping command from SIPProxy server.
Ping <MediaGW IP>

SUPPORTDOCUMENT

PAGE 12
 TROUBLESHOOTING MANUAL
3. If you get response for the Ping command and then make sure that Routing
configuration is made properly in the MediaGW.
4. If there is no such error in MediaGW and if the Invite request is forwarded to
SIPProxy and in turn it responded with 100 Trying. But after 100 Trying if there is no
response then check whether the MediaGW IP’s are configured in the SIPProxy
Routing Table for both Incoming(Internal GW) and for Outgoing(External GW).
5. This can be checked by logging in to the CLI prompt and by executing the
appropriate option. If the gateways are not shown then configure the Gateways.
Default user name and password is nexge / nexge. For routing configuration details
please check the configuration document.
# telnet <sip proxy server IP> 50000
6. If all the above conditions are fulfilled then the call will be terminated if the
subscriber is valid and having enough balance.
7. If still the call is not going through, then check whether SIPProxy is responding. If
not refer to Maintenance document for restarting the service.

Suppose a subscriber made a call and it reached the Softswitch, but call is not
established. Follow the step given below to go through the log.

1. Once the subscriber made a call and if the call reached the SoftSwitch, but there is a
disconnect message. To check the reason for this you need to login to the SIPProxy
Server and edit Call log and Progress log.
2. Goto to SIPProxy log location as mentioned above and edit current hour Call log
using vi editor and search for the number that subscriber dialed.
3. If the call hit the server and if you need to identify the cause for this, you need get
the unique call id using the dialed number. Editing the call log and search for
destination number dialed, from the output you can identify unique call id. If u find
similar to this line in call log, then u can take the unique call id from that.
[email protected]; 2006 May 18 11:0:1; 1565663194;
61.246.199.9/61.246.199.9; SIP; 19033348784; ; ; ;INVITE Received;

UniqueCallID SIP Messages

Destination Number Caller Number

SUPPORTDOCUMENT

PAGE 13
 TROUBLESHOOTING MANUAL
4. If you want to check the complete Call log for the particular call then grep the call
log using the unique call id that you found. This can be executed using below
command.
grep “[email protected]” Call-19May2006-16.log
5. The above command will give you the complete call details for the uniquecallid,
which is mentioned above. If authorize fails then log for this will looks similar to this.
Similarly the call log will vary based on the messages that you are getting.
[email protected]; 2006 May 19 00:1:0; 64100102;
131.10.20.27/131.10.20.27; SIP; 100; ; ; ;INVITE Received;

[email protected]; 2006 May 19 00:1:0; 64100102;

131.10.20.27/131.10.20.27; SIP; 100; ; ; Prefix Matching;NO MATCH;

[email protected]; 2006 May 19 00:1:0; 64100102;

131.10.20.27/131.10.20.27; SIP; 100; Routing; 100; Callee: Registered User;100;

[email protected]; 2006 May 19 00:1:0; 64100102;

131.10.20.27/131.10.20.27; SIP; 100; ; ; Authorizing;AuthorizedNot ;

[email protected]; 2006 May 19 00:1:0; 64100102;

131.10.20.27/131.10.20.27; SIP; 100; ; ; Authorization Failed;Forbidden;

6. If you want to go through the detailed log then edit Progress log and check exact
reason. If you find positive response from Radius like given below and still the call is
not through, then there is no balance. Check for balance.

2006-08-16 01:00:25.533 - [SSRC]Received Response From Radius in HexDump :

025d00a1c633e892bb4d28de180d971972655fa819255342522d434c20444e3d22303
83432373034343733313734222041543d2232303022001a360000000918306833323
32d636f6e662d69643d39336663383562352d3665306434353530403232302e32323
52e35322e313831001a1700000009d311683332332d436c6173733d343230001a1b0
00000096615683332332d6372656469742d74696d653d3000
2006-08-16 01:00:25.533 - [SSRC]Returning Radius Request For Identifier 93
2006-08-16 01:00:25.533 - [SSRC]Removed Radius Request For Identifier 93
2006-08-16 01:00:25.533 - Attribute Type is =25
2006-08-16 01:00:25.533 - AttributeType = 25, AttributeLength = 37 ,
AttributeValue =

SUPPORTDOCUMENT

PAGE 14
 TROUBLESHOOTING MANUAL
5342522d434c20444e3d2230383432373034343733313734222041543d2232303022
00
2006-08-16 01:00:25.533 - Attribute Type is =26
2006-08-16 01:00:25.533 - attribute 24 is not handled
2006-08-16 01:00:25.533 - AttributeType = 26, AttributeLength = 54 ,
AttributeValue =
000000091830683332332d636f6e662d69643d39336663383562352d366530643435
3530403232302e3232352e35322e31383100
2006-08-16 01:00:25.534 - Attribute Type is =26
2006-08-16 01:00:25.534 - Class Value = h323-Class=420^@
2006-08-16 01:00:25.534 - AttributeType = 211, AttributeLength = 23 ,
AttributeValue = 00000009d311683332332d436c6173733d34323000
2006-08-16 01:00:25.534 - Attribute Type is =26
2006-08-16 01:00:25.534 - VSA Value Ends with Hex - 00, so we are ignoring it
2006-08-16 01:00:25.534 - [checkRadiusPacket()] Permitted time: 0
2006-08-16 01:00:25.534 - Permitted Value is =0
2006-08-16 01:00:25.534 - AttributeType = 102, AttributeLength = 1 ,
AttributeValue = 30
2006-08-16 01:00:25.534 - Authentication Successful For Object Identifier 93 and
Identifier 0842704473174
2006-08-16 01:00:25.534 - [SSRC]INVITE Message Response Found.
2006-08-16 01:00:25.534 - [RadiusClientManager]Get the user from
RadiusClientTable [email protected]
2006-08-16 01:00:25.534 - [SSRC]Found response for the call with callId 93fc85b5-
[email protected]
2006-08-16 01:00:25.534 - [RadiusClientManager]Removing the user from
RadiusClientTable [email protected]
2006-08-16 01:00:25.535 - [RadiusClientManager]Add the user from
RadiusClientTable [email protected] RadiusServerIds []
2006-08-16 01:00:25.535 - Long value of time is 0
2006-08-16 01:00:25.535 - Class Value is h323-Class=420^@
2006-08-16 01:00:25.535 - [SSRC]Class Value returned from RADIUS is h323-
Class=420^@

SUPPORTDOCUMENT

PAGE 15
 TROUBLESHOOTING MANUAL
2006-08-16 01:00:25.535 - [SSRC]Call has been authorised by
RadiusServer,proceed.
2006-08-16 01:00:25.535 - Class Value is h323-Class=420^@
2006-08-16 01:00:25.535 - [SSRC]Added Radius Class Value For Call Id93fc85b5-
[email protected]
2006-08-16 01:00:25.535 - [RadCliInterface]Allowing the call 93fc85b5-
[email protected]
2006-08-16 01:00:25.535 - [RadCliInterface]Since the permitted is invalid, reject
the call : [email protected]
2006-08-16 01:00:25.535 - [RadCliInterface]Rejecting the call
2006-08-16 01:00:25.535 - [RadCliInterface]Response to send:
SIP/2.0 403 Forbidden
From: "084270447"
<sip:[email protected]>;tag=9a809271367c3fc4o1
To: <sip:[email protected]>
Via: SIP/2.0/UDP 220.225.52.181:5061;branch=z9hG4bK-a5737e0c
CSeq: 101 INVITE
Call-ID: [email protected]
Content-Length: 0

7. If there is negative response from Radius like given below, then call will fail. Check
the Radius and Billing why this call is rejecting.

2006-08-16 01:00:25.533 - [SSRC]Received Response From Radius in HexDump :

035d00a1c633e892bb4d28de180d971972655fa819255342522d434c20444e3d22303
83432373034343733313734222041543d2232303022001a360000000918306833323
32d636f6e662d69643d39336663383562352d3665306434353530403232302e32323
52e35322e313831001a1700000009d311683332332d436c6173733d343230001a1b0
00000096615683332332d6372656469742d74696d653d3000

SUPPORTDOCUMENT

PAGE 16