To kamailio/opensips single-step debugging, you need to understand the structure and operation of its code, kamailio/opensips using reactor and Proactor combined IO network model, using the main process is responsible for monitoring the network, When a connection is generated or the first packet arrives, the file is described character to the worker process through a pipe, and the worker process is responsible for the data fetching, business processing, data sending, etc. of the connection, and then waits for the socket event again. When we want to debug a piece of code, we first confirm that this code is running in what type of process, usually the code used to process the SIP logic is executed in the worker process, the following is an instance of the Kamailio process startup:
[[email protected] sipserver]# kamctl PS
Process:: Id=0 pid=6651 type=attendant
Process:: id=1 pid=6653 type=udp receiver Child=0 sock=172.16.0.16:53
Process:: id=2 pid=6654 type=udp receiver child=1 sock=172.16.0.16:53
Process:: id=3 pid=6656 type=udp receiver child=2 sock=172.16.0.16:53
Process:: id=4 pid=6658 type=udp receiver child=3 sock=172.16.0.16:53
Process:: id=5 pid=6661 type=slow Timer
Process:: id=6 pid=6662 Type=timer
Process:: id=7 pid=6665 Type=mi FIFO
Process:: id=8 pid=6668 Type=ctl Handler
Process:: id=9 pid=6669 type=snmp Agentx
Process:: id=10 pid=6672 type=tcp Receiver (generic) child=0
Process:: id=11 pid=6674 type=tcp Receiver (generic) child=1
Process:: id=12 pid=6676 type=tcp Receiver (generic) child=2
Process:: id=13 pid=6677 type=tcp Receiver (generic) child=3
Process:: id=14 pid=6679 type=tcp main process In the above example, both the TYPE=TCP receiver and UDP receiver processes are processing SIP messages. The route segments included in the KAMAILIO.CFG configuration are executed in this process, and the modules that we develop for processing the SIP protocol are also executed in this process. Kamailio and Opensips are consistent on the code core architecture, with Kamailio as an example to illustrate how to debug with GDB. There are two ways to debug a program: Method 1 runs Kamailio directly with GDB: KAMAILIO.CFG is configured as Fork=no so that the Kamailio will run as a single process, so the logic will be executed in one process, but the single-process mode does not support TCP listen. Therefore, to debug TCP logic, you cannot use this method. Debugging the Kamailio main program directly with GDB is the line:
[Email protected] ~]# Gdb/usr/sbin/kamailio
GNU gdb (gdb) Red Hat Enterprise Linux (7.0.1-45.EL5)
Copyright (C) Software Foundation, Inc.
License gplv3+: GNU GPL version 3 or later This was free software:you was free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "Show copying"
and "Show warranty" for details.
This GDB is configured as "X86_64-redhat-linux-gnu".
For bugs reporting instructions, please see:
Reading symbols From/usr/sbin/kamailio...done.
(gdb) b main.c:10
Breakpoint 1 at 0x45725c:file Main.c, line ten.
(GDB) run
Method 2 will run Kamailio, and then debug with GDB Attach: The disadvantage of the first method is very obvious, can not debug TCP process, nor can the advantages of Kamailio multi-process play out. Configuring Kamailio.cfg to Fork=yes will start in a multi-process manner, with two parameters associated with it: children=1, configuring the number of processes handling UDP port data tcp_children=1; Configuring process data to process TCP port data, If this parameter is not configured, the children parameter is used by default. If you start the program with the above parameters, if the listen parameter has a corresponding port, you will start 1 UDP processing processes and a TCP processing process with the following example:
[[email protected] sipserver]# Kamctl PS
Process:: Id=0 pid=6651 type=attendant
Process:: id=1 pid=6653 type=udp receiver Child=0 sock=172.16.0.16:53
Process:: id=5 pid=6661 type=slow Timer
Process:: id=6 pid=6662 Type=timer
Process:: id=7 pid=6665 Type=mi FIFO
Process:: id=8 pid=6668 Type=ctl Handler
Process:: id=9 pid=6669 type=snmp Agentx
Process:: id=10 pid=6672 type=tcp Receiver (generic) child=0
Process:: id=14 pid=6679 type=tcp main process When Kamailio receives TCP data, it is handled by a 6672 process, and we can debug it using GDB attach to the specified process, as follows:
[[email protected] ~]# GDB
GNU gdb (gdb) Red Hat Enterprise Linux (7.0.1-45.EL5)
Copyright (C) Software Foundation, Inc.
License gplv3+: GNU GPL version 3 or later This was free software:you was free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "Show copying"
and "Show warranty" for details.
This GDB is configured as "X86_64-redhat-linux-gnu".
For bugs reporting instructions, please see:
(GDB) Attach 6672
Attaching to process 6672
......
(GDB) B redis_base.c:100
Breakpoint 1 at 0x2b6c45e70082:file redis_base.c, line 100.
(GDB) C
Continuing.
Then set a breakpoint, execute run, when the server receives the SIP message and run to the specified code can be single-step debugging, in the debugging process and then combine the log output, is very helpful to locate the problem. For information on how to use GDB, refer to the documentation: HTTP://WENKU.BAIDU.COM/LINK?URL=UNUB8A6F2OGT_KJXU4P7-DF-J9QFW2Z2CFN6NCJ4SMZIJX_ Uimikutfh7jloe-byiylp2ygfatbtkppogr3lhtd09p3ntqtzdprwp9n5pmu
Sina Weibo: @ The quiet mad persone-mail: dennis.yu (@) live.cnqq:229675152focus on the field of mobile Internet audio and video communications, welcome to exchange; This article is original, reproduced please retain the copyright and contact the author
Kamailio/opensips Technology QQ Group: 118791050
Opensips/kamailio GDB Code Debugging method detailed
