TECHNICAL COMMUNICATION No. TC1269 Ed.

01

OmniPCX Enterprise Nb of pages : 6 Date : 10 December 2009

URGENT

NOT URGENT TEMPORARY PERMANENT

SUBJECT: INCIDENTS 5814, 5815 AND 5816 (FAILURE IN SIP COMPONENT)

CONTENTS

1. PRESENTATION OF THE INCIDENTS ............................................3

2. PRESENTATION OF THE SIPALARM FILES .....................................3

3. EXAMPLE OF INCIDENTS .............................................................4

3.1 Incident without disturbance on the SIP functioning.................................. 4
3.2 Incident with disturbance of the proper SIPMOTOR functioning ................ 4

4. TRACES WHERE INCIDENTS AFFECTING THE GOOD

FUNCTIONING OF THE SIP..........................................................5
4.1 On Call Handling...................................................................................... 5
4.2 On SIPMOTOR .......................................................................................... 5
4.3 Under root ................................................................................................ 5

5. CONCLUSION .............................................................................6

1
2
 OmniPCX Enterprise
INCIDENTS 5814, 5815 AND 5816
(FAILURE IN SIP COMPONENT)

1. PRESENTATION OF THE INCIDENTS

The incidents 5814, 5815 and 5816 can be displayed on the OmniPCX Enterprise linked to SIP
equipments (On communication or out of communication):
• SIP Extension
• SIP Device (Previous external set)
• Local SIP gateway
• External SIP gateway
• External SIP Voicemail
These incidents are used to advise you that something happens on the SIP level. That can not affect
the OmniPCX Enterprise functioning or can disturb the SIP communications.
Each incident has is own severity level:
• 5814= Critical failure in SIP component
• 5815= Major failure in SIP component
• 5816= Minor failure in SIP component

2. PRESENTATION OF THE SIPALARM FILES

If one of these incidents appears, the checking of the SIPALARM files, under /tmpd has to be done
to know the reason why.
10 files exist in maximum:
-rw-rw-rw- 1 mtcl tel 7317 Nov 30 10:59 sipalarm.log
-rw-rw-rw- 1 mtcl tel 10468 Nov 24 17:05 sipalarm1.log
-rw-rw-rw- 1 mtcl tel 10505 Nov 23 15:25 sipalarm2.log
-rw-rw-rw- 1 mtcl tel 10562 Nov 20 16:23 sipalarm3.log
-rw-rw-rw- 1 mtcl tel 10265 Nov 19 22:20 sipalarm4.log
-rw-rw-rw- 1 mtcl tel 10458 Nov 15 13:56 sipalarm5.log
-rw-rw-rw- 1 mtcl tel 10658 Nov 15 14:45 sipalarm6.log
-rw-rw-rw- 1 mtcl tel 10469 Nov 14 13:44 sipalarm7.log
-rw-rw-rw- 1 mtcl tel 10564 Nov 12 11:38 sipalarm8.log
-rw-rw-rw- 1 mtcl tel 10425 Nov 10 10:56 sipalarm9.log

The sipalarm.log is the file containing the last incidents, the others are stored.
• If sipalarm.log is full, its content is put in sipalarm1.log.
• If sipalarm.log is full and sipalarm1.log is already created, its content is put in
sipmalarm2.log.
• …
• If sipalarm.log is full and sipalarm9.log is already created, its contain is put in
sipalarm1.log (deleting the old contain)

The size of a file is limited to 11 KB.

Ed. 01 / 10 December 2009 3 TC1269

 OmniPCX Enterprise
INCIDENTS 5814, 5815 AND 5816
(FAILURE IN SIP COMPONENT)

3. EXAMPLE OF INCIDENTS

3.1 Incident without disturbance on the SIP functioning

When an incident is generated, check the date and time of its creation, for example:

30/11/09 10:52:31 000001M|---/--/-/---|=3:5816=Minor failure in SIP component

After we check the sipalarm files to find the corresponding entry according to the date and time
incident creation and get the next information:

> 11/30/09 - 10:52:31 Minor alarm

[receiveSuccessfulMessage] Call: 61e850385888d87cf8deb9063c062548@172.27.141.151
eqt: 1487 PROCEEDING_STATE tag not present.

If you look in details, we observe some interesting information:

• The incident severity is "Minor", which means that the problem does not affect the proper
functioning of the SIP in the OmniPCX Enterprise.
• The Call-ID "61e850385888d87cf8deb9063c062548@172.27.141.151", which allows to
link with a trace motortrace or "wireshark" type, to find out which exchanges are associated
with this SIP incident.
• The equipment number "eqt : 1487" which corresponds in this case to SIP ISDN TG, with this
information, we are able to more easily identifying the SIP equipment involved for the
incident.
• The last information, after the equipment number, give us the incident cause, for instance
"PROCEEDING_STATE received a message", the "PROCEEDING" corresponds to call
establishment phase of a SIP communication. In that case, on a receiving message, the "tag"
doesn’t correspond to a call in progress (call terminated or existent).

3.2 Incident with disturbance of the proper SIPMOTOR functioning

In this example, the incident 5816 is generated, but the message 5816 is followed by the message
287 and these two messages appears more and more often over time, there is a good probability to
get a stop of the SIPMOTOR functioning…
Incidents:
03/07/09 11:54:24 000001M|---/--/-/---|=3:5816=Minor failure in SIP component SIP
03/07/09 11:54:44 000001M|019/00/0/007|=3:0287= Header msg pb (T2, T0 or S0), (1 10958 -
1) especially TEI or flag

(In that case the position 19/0/7 corresponds to a SIP TG).

TC1269 4 Ed. 01 / 10 December 2009

 OmniPCX Enterprise
INCIDENTS 5814, 5815 AND 5816
(FAILURE IN SIP COMPONENT)

Sipalarm:
> 07/03/09 - 11:54:24 Minor alarm
[receiveInviteEvent] Call: eqt: 10567 INITIAL_STATE failed to emit an Invite
message.

If we look at well the message corresponding in the sipalarm.log file, the problem is that the
OmniPCX Enterprise could not send an INVITE, which in itself is not considered a major incident.
The problem was that the RASFO (callback on busy TG) was validated in OmniPCX Enterprise, which
is strictly prohibited.

4. TRACES WHERE INCIDENTS AFFECTING THE GOOD

FUNCTIONING OF THE SIP
If you find that one type of SIP call, you see an incident that appears each time, in this case, it is
important to make the following trace on the OmniPCX Enterprise:

4.1 On Call Handling

• tuner km
• tuner clear-traces
• tuner hybrid=on
• tuner +at
• actdbg sip=on csip=on abcf=on ei=on
• mtracer –a > "Name_of_the_file.log"
• Do Ctrl-c to stop the trace
• tuner km
We can adapt the choices on actdbg according to the call type, if it is a SIP Device, we don’t need to
use ei=on for instance, etc…

4.2 On SIPMOTOR

• motortrace 3
• traced > "Name_of_the_file.log"
• Do Ctrl-c to stop the trace
We can used "motortrace 6" if a DNS configuration is done for the SIP call.

4.3 Under root

• tcpdump –s 2000 –w “Name_of_the_file.cap” host “IP_address_SIP_equipement”

• Do Ctrl-c to stop the trace

Ed. 01 / 10 December 2009 5 TC1269

 OmniPCX Enterprise
INCIDENTS 5814, 5815 AND 5816
(FAILURE IN SIP COMPONENT)

Send the traces to Alcatel-Lucent for analyses, by adding the incidents (incvisu command) and all the
sipalarm files under /tmpd/, specify each time the calling/called number, the IP addresses of the
different equipments involved in that call, then the contains of the command "motortrace c".

5. CONCLUSION
When these incidents appear on the OmniPCX Enterprise, a minimum of analyses can be done
thanks to the sipalarm files, id these incidents disturb the proper functioning of the SIP, it is important
to make the requested traces, by adapting them according to the type of calls and to transmit them
via an opened SR for deeper analyses.
The SIP traces given can be done every time when you have SIP issue.

TC1269 6 Ed. 01 / 10 December 2009