[OpenSIPS-Devel] [ opensips-Bugs-2936843 ] db_check_from fails if From header contains double quotes.
Bugs item #2936843, was opened at 2010-01-22 04:22 Message generated for change (Comment added) made by ibc_sf You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=2936843group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: 1.6.x Status: Open Resolution: None Priority: 5 Private: No Submitted By: seadweller (seadweller) Assigned to: Nobody/Anonymous (nobody) Summary: db_check_from fails if From header contains double quotes. Initial Comment: Running OpenSIPS 1.6.1 with uri_db module. If db_check_from receives a From header containing a double quoted value, it fails even if the from username is valid. An example From header would be as such: From: Test User sip:testu...@10.1.1.1;tag=as4b4ca259 Client was reporting a 403 Forbidden. When I duplicated this From header using an IAX client through Asterisk, I too received the 403. When I removed the extra set of quotes, db_check_from returned properly. -- Comment By: Iñaki Baz Castillo (ibc_sf) Date: 2010-01-22 10:11 Message: This bug report is invalid as RFC 3261 BNF grammar doesn't a llow a display-name with double quotes inside. I've tested it. This is, the display-name in a From/To/Contact URI can be enclosed between double quotes, but it cannot contain double quotes inside. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=2936843group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] SF.net SVN: opensips:[6519] trunk/mem
Revision: 6519 http://opensips.svn.sourceforge.net/opensips/?rev=6519view=rev Author: andreidragus Date: 2010-01-22 10:27:22 + (Fri, 22 Jan 2010) Log Message: --- Added warning before defrag starts Modified Paths: -- trunk/mem/f_malloc.c trunk/mem/mem.h This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] SF.net SVN: opensips:[6520] branches/1.6/mem
Revision: 6520 http://opensips.svn.sourceforge.net/opensips/?rev=6520view=rev Author: andreidragus Date: 2010-01-22 10:34:54 + (Fri, 22 Jan 2010) Log Message: --- Backported warning to f_malloc Modified Paths: -- branches/1.6/mem/f_malloc.c branches/1.6/mem/mem.h This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] SF.net SVN: opensips:[6521] trunk/mem/f_malloc.c
Revision: 6521 http://opensips.svn.sourceforge.net/opensips/?rev=6521view=rev Author: andreidragus Date: 2010-01-22 10:41:55 + (Fri, 22 Jan 2010) Log Message: --- Fixed potential overflow Modified Paths: -- trunk/mem/f_malloc.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] SF.net SVN: opensips:[6522] branches/1.6/mem/f_malloc.c
Revision: 6522 http://opensips.svn.sourceforge.net/opensips/?rev=6522view=rev Author: andreidragus Date: 2010-01-22 10:46:08 + (Fri, 22 Jan 2010) Log Message: --- backport from trunk Modified Paths: -- branches/1.6/mem/f_malloc.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-2936843 ] db_check_from fails if From header contains double quotes.
Bugs item #2936843, was opened at 2010-01-22 05:22 Message generated for change (Comment added) made by bogdan_iancu You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=2936843group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: 1.6.x Status: Closed Resolution: Invalid Priority: 5 Private: No Submitted By: seadweller (seadweller) Assigned to: Nobody/Anonymous (nobody) Summary: db_check_from fails if From header contains double quotes. Initial Comment: Running OpenSIPS 1.6.1 with uri_db module. If db_check_from receives a From header containing a double quoted value, it fails even if the from username is valid. An example From header would be as such: From: Test User sip:testu...@10.1.1.1;tag=as4b4ca259 Client was reporting a 403 Forbidden. When I duplicated this From header using an IAX client through Asterisk, I too received the 403. When I removed the extra set of quotes, db_check_from returned properly. -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2010-01-22 14:42 Message: I agree with Inaki: display Test User is invalid from SIP grammar point of view . The correct format should be \Test User\' Regards, Bogdan -- Comment By: Iñaki Baz Castillo (ibc_sf) Date: 2010-01-22 11:11 Message: This bug report is invalid as RFC 3261 BNF grammar doesn't a llow a display-name with double quotes inside. I've tested it. This is, the display-name in a From/To/Contact URI can be enclosed between double quotes, but it cannot contain double quotes inside. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=2936843group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [B2B_ENTITIES] ACK Strategy
2010/1/21 Olivier Détour chino540off+kamai...@gmail.com: Hi, I'm having a hard time using b2b_entities: After sending a 4xx error (long after the invite), I'd like to be notified when the client sends the ACK. I'd want to be able to close the call context when my module receives the client's ACK, but I never see it, b2b_entities silently processes it. Is it possible to change this behaviour? I saw in the debug trace (debug=9) that the ACK is not for the server_address parameter (in opensips.cfg), could this be a part of the problem? For example I've got a 404 error being resent continuously until phone timeout. If I missed documentation on the subject I will gladly RTFM if someone points me in the right direction. Thanks, Regards, Sorry about that, configuration problems, thanks, -- Olivier Détour ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] SIP introduction is the next webinar
Next webinar is scheduled for 28th of January 2010. The topic is SIP Introduction - detailed explanation and examples of SIP fundamentals: Requests and Replies, Initial and sequential requests, SIP transactions, SIP dialogs, SIP and RTP; A good understanding of SIP protocol is essential for working with OpenSIPS. Free registration - http://www.opensips.org/Training/Webinars#toc5 The list with all the next scheduled webinars is available under http://www.opensips.org/Training/Webinars#toc4 Best regards, Bogdan -- Bogdan-Andrei Iancu www.voice-system.ro ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-2936343 ] 'opensipsctl fifo get_statistics all' crashes opensips
Bugs item #2936343, was opened at 2010-01-21 15:51
Message generated for change (Comment added) made by cupotka2008
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=1086410aid=2936343group_id=232389
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.6.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Alex Massover (cupotka2008)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: 'opensipsctl fifo get_statistics all' crashes opensips
Initial Comment:
Hi!
'opensipsctl fifo get_statistics all' always crashes opensips. Core is somehow
not produced.
Always reproducible for me on 1.6.1.
Here's a strace of parent process:
Process 9509 attached - interrupt to quit
pause() = ? ERESTARTNOHAND (To be restarted)
--- SIGUSR2 (User defined signal 2) @ 0 (0) ---
sigreturn() = ? (mask now [])
pause() = ? ERESTARTNOHAND (To be restarted)
--- SIGCHLD (Child exited) @ 0 (0) ---
sigreturn() = ? (mask now [])
waitpid(-1, [{WIFSIGNALED(s) WTERMSIG(s) == SIGUSR2}], WNOHANG) = 9520
waitpid(-1, 0xbf84b4c8, WNOHANG)= 0
kill(0, SIGTERM)= 0
--- SIGTERM (Terminated) @ 0 (0) ---
--- SIGCHLD (Child exited) @ 0 (0) ---
sigreturn() = ? (mask now [TERM])
sigreturn() = ? (mask now [])
rt_sigaction(SIGALRM, {0x8065920, [ALRM], SA_RESTART}, {SIG_DFL}, 8) = 0
alarm(60) = 0
wait4(-1, NULL, 0, NULL)= 9514
wait4(-1, NULL, 0, NULL)= 9519
wait4(-1, NULL, 0, NULL)= 9521
wait4(-1, NULL, 0, NULL)= 9522
wait4(-1, NULL, 0, NULL)= 9512
--- SIGCHLD (Child exited) @ 0 (0) ---
sigreturn() = ? (mask now [])
--- SIGCHLD (Child exited) @ 0 (0) ---
sigreturn() = ? (mask now [])
wait4(-1, NULL, 0, NULL)= 9510
wait4(-1, NULL, 0, NULL)= 9516
--- SIGCHLD (Child exited) @ 0 (0) ---
sigreturn() = ? (mask now [])
--- SIGCHLD (Child exited) @ 0 (0) ---
sigreturn() = ? (mask now [])
wait4(-1, NULL, 0, NULL)= 9515
wait4(-1, NULL, 0, NULL)= 9517
wait4(-1, NULL, 0, NULL)= 9524
wait4(-1, NULL, 0, NULL)= 9525
--- SIGCHLD (Child exited) @ 0 (0) ---
sigreturn() = ? (mask now [])
--- SIGCHLD (Child exited) @ 0 (0) ---
sigreturn() = ? (mask now [])
--- SIGCHLD (Child exited) @ 0 (0) ---
sigreturn() = ? (mask now [])
--- SIGCHLD (Child exited) @ 0 (0) ---
sigreturn() = ? (mask now [])
wait4(-1, NULL, 0, NULL)= 9511
wait4(-1, NULL, 0, NULL)= 9513
wait4(-1, NULL, 0, NULL)= 9518
wait4(-1, NULL, 0, NULL)= 9523
wait4(-1, NULL, 0, NULL)= -1 ECHILD (No child processes)
rt_sigaction(SIGALRM, {0x8066080, [ALRM], SA_RESTART}, {0x8065920, [ALRM],
SA_RESTART}, 8) = 0 stat64(/tmp/opensips_fifo, {st_mode=S_IFIFO|0660,
st_size=0, ...}) = 0
unlink(/tmp/opensips_fifo)= 0
munmap(0xaed25000, 134217728) = 0
unlink(/var/run/opensips/opensips.pid) = 0
alarm(0)= 60
rt_sigaction(SIGALRM, {SIG_IGN}, {0x8066080, [ALRM], SA_RESTART}, 8) = 0
exit_group(0) = ?
Process 9509 detached
--
Comment By: Alex Massover (cupotka2008)
Date: 2010-01-22 16:51
Message:
I just discovered 'fifo ps' command :)
read(7, :get_statistics:opensips_receiver..., 4096) = 45
open(/tmp/opensips_receiver_18361, O_WRONLY|O_NONBLOCK) = 10
fstat64(10, {st_mode=S_IFIFO|0666, st_size=0, ...}) = 0
lstat64(/tmp/opensips_receiver_18361, {st_mode=S_IFIFO|0666, st_size=0,
...}) = 0
fcntl64(10, F_GETFL)= 0x801 (flags
O_WRONLY|O_NONBLOCK)
fcntl64(10, F_SETFL, O_WRONLY) = 0
fcntl64(10, F_GETFL)= 0x1 (flags O_WRONLY)
fstat64(10, {st_mode=S_IFIFO|0666, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0xb7252000
_llseek(10, 0, 0xbfd1c5d8, SEEK_CUR)= -1 ESPIPE (Illegal seek)
open(/proc/net/udp, O_RDONLY) = 11
fstat64(11, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0xb7251000
read(11, sl local_address rem_address ..., 1024) = 1024
read(11, 67: 017F:0035 :..., 1024) = 640
read(11, ..., 1024) = 0
close(11) = 0
munmap(0xb7251000, 4096)
[OpenSIPS-Devel] [ opensips-Bugs-2936343 ] 'opensipsctl fifo get_statistics all' crashes opensips
Bugs item #2936343, was opened at 2010-01-21 15:51
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=1086410aid=2936343group_id=232389
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.6.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Alex Massover (cupotka2008)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: 'opensipsctl fifo get_statistics all' crashes opensips
Initial Comment:
Hi!
'opensipsctl fifo get_statistics all' always crashes opensips. Core is somehow
not produced.
Always reproducible for me on 1.6.1.
Here's a strace of parent process:
Process 9509 attached - interrupt to quit
pause() = ? ERESTARTNOHAND (To be restarted)
--- SIGUSR2 (User defined signal 2) @ 0 (0) ---
sigreturn() = ? (mask now [])
pause() = ? ERESTARTNOHAND (To be restarted)
--- SIGCHLD (Child exited) @ 0 (0) ---
sigreturn() = ? (mask now [])
waitpid(-1, [{WIFSIGNALED(s) WTERMSIG(s) == SIGUSR2}], WNOHANG) = 9520
waitpid(-1, 0xbf84b4c8, WNOHANG)= 0
kill(0, SIGTERM)= 0
--- SIGTERM (Terminated) @ 0 (0) ---
--- SIGCHLD (Child exited) @ 0 (0) ---
sigreturn() = ? (mask now [TERM])
sigreturn() = ? (mask now [])
rt_sigaction(SIGALRM, {0x8065920, [ALRM], SA_RESTART}, {SIG_DFL}, 8) = 0
alarm(60) = 0
wait4(-1, NULL, 0, NULL)= 9514
wait4(-1, NULL, 0, NULL)= 9519
wait4(-1, NULL, 0, NULL)= 9521
wait4(-1, NULL, 0, NULL)= 9522
wait4(-1, NULL, 0, NULL)= 9512
--- SIGCHLD (Child exited) @ 0 (0) ---
sigreturn() = ? (mask now [])
--- SIGCHLD (Child exited) @ 0 (0) ---
sigreturn() = ? (mask now [])
wait4(-1, NULL, 0, NULL)= 9510
wait4(-1, NULL, 0, NULL)= 9516
--- SIGCHLD (Child exited) @ 0 (0) ---
sigreturn() = ? (mask now [])
--- SIGCHLD (Child exited) @ 0 (0) ---
sigreturn() = ? (mask now [])
wait4(-1, NULL, 0, NULL)= 9515
wait4(-1, NULL, 0, NULL)= 9517
wait4(-1, NULL, 0, NULL)= 9524
wait4(-1, NULL, 0, NULL)= 9525
--- SIGCHLD (Child exited) @ 0 (0) ---
sigreturn() = ? (mask now [])
--- SIGCHLD (Child exited) @ 0 (0) ---
sigreturn() = ? (mask now [])
--- SIGCHLD (Child exited) @ 0 (0) ---
sigreturn() = ? (mask now [])
--- SIGCHLD (Child exited) @ 0 (0) ---
sigreturn() = ? (mask now [])
wait4(-1, NULL, 0, NULL)= 9511
wait4(-1, NULL, 0, NULL)= 9513
wait4(-1, NULL, 0, NULL)= 9518
wait4(-1, NULL, 0, NULL)= 9523
wait4(-1, NULL, 0, NULL)= -1 ECHILD (No child processes)
rt_sigaction(SIGALRM, {0x8066080, [ALRM], SA_RESTART}, {0x8065920, [ALRM],
SA_RESTART}, 8) = 0 stat64(/tmp/opensips_fifo, {st_mode=S_IFIFO|0660,
st_size=0, ...}) = 0
unlink(/tmp/opensips_fifo)= 0
munmap(0xaed25000, 134217728) = 0
unlink(/var/run/opensips/opensips.pid) = 0
alarm(0)= 60
rt_sigaction(SIGALRM, {SIG_IGN}, {0x8066080, [ALRM], SA_RESTART}, 8) = 0
exit_group(0) = ?
Process 9509 detached
--
Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2010-01-22 17:35
Message:
Alex, I'm investigating some possibilitiesCould you apply the patch I
just uploaded here? Just to see if my suspicion is right. BTW, what modules
are you loading ?
Thanks and regards,
Bogdan
--
Comment By: Alex Massover (cupotka2008)
Date: 2010-01-22 16:51
Message:
I just discovered 'fifo ps' command :)
read(7, :get_statistics:opensips_receiver..., 4096) = 45
open(/tmp/opensips_receiver_18361, O_WRONLY|O_NONBLOCK) = 10
fstat64(10, {st_mode=S_IFIFO|0666, st_size=0, ...}) = 0
lstat64(/tmp/opensips_receiver_18361, {st_mode=S_IFIFO|0666, st_size=0,
...}) = 0
fcntl64(10, F_GETFL)= 0x801 (flags
O_WRONLY|O_NONBLOCK)
fcntl64(10, F_SETFL, O_WRONLY) = 0
fcntl64(10, F_GETFL)= 0x1 (flags O_WRONLY)
fstat64(10, {st_mode=S_IFIFO|0666, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0xb7252000
_llseek(10, 0, 0xbfd1c5d8, SEEK_CUR)= -1 ESPIPE (Illegal seek)
open(/proc/net/udp, O_RDONLY) = 11
fstat64(11, {st_mode=S_IFREG|0444,
Re: [OpenSIPS-Devel] [ opensips-Bugs-2936343 ] 'opensipsctl fifo get_statistics all' crashes opensips
I have found that taking the snmp module out of the config allows the command
to complete without crashing opensips. This hasn't always been the case but I
don't know what revision the problem started with.
I also don't have the opensips snmp config completely set up on this server.
Everything is in place except the agentXSocket listen parameter being set for
the snmpstats module. I'll try to test this again with that in place before
the end of the day.
Richard
On Jan 22, 2010, at 9:51 AM, SourceForge.net wrote:
Bugs item #2936343, was opened at 2010-01-21 15:51
Message generated for change (Comment added) made by cupotka2008
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=1086410aid=2936343group_id=232389
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.6.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Alex Massover (cupotka2008)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: 'opensipsctl fifo get_statistics all' crashes opensips
Initial Comment:
Hi!
'opensipsctl fifo get_statistics all' always crashes opensips. Core is
somehow not produced.
Always reproducible for me on 1.6.1.
Here's a strace of parent process:
Process 9509 attached - interrupt to quit
pause() = ? ERESTARTNOHAND (To be restarted)
--- SIGUSR2 (User defined signal 2) @ 0 (0) ---
sigreturn() = ? (mask now [])
pause() = ? ERESTARTNOHAND (To be restarted)
--- SIGCHLD (Child exited) @ 0 (0) ---
sigreturn() = ? (mask now [])
waitpid(-1, [{WIFSIGNALED(s) WTERMSIG(s) == SIGUSR2}], WNOHANG) = 9520
waitpid(-1, 0xbf84b4c8, WNOHANG)= 0
kill(0, SIGTERM)= 0
--- SIGTERM (Terminated) @ 0 (0) ---
--- SIGCHLD (Child exited) @ 0 (0) ---
sigreturn() = ? (mask now [TERM])
sigreturn() = ? (mask now [])
rt_sigaction(SIGALRM, {0x8065920, [ALRM], SA_RESTART}, {SIG_DFL}, 8) = 0
alarm(60) = 0
wait4(-1, NULL, 0, NULL)= 9514
wait4(-1, NULL, 0, NULL)= 9519
wait4(-1, NULL, 0, NULL)= 9521
wait4(-1, NULL, 0, NULL)= 9522
wait4(-1, NULL, 0, NULL)= 9512
--- SIGCHLD (Child exited) @ 0 (0) ---
sigreturn() = ? (mask now [])
--- SIGCHLD (Child exited) @ 0 (0) ---
sigreturn() = ? (mask now [])
wait4(-1, NULL, 0, NULL)= 9510
wait4(-1, NULL, 0, NULL)= 9516
--- SIGCHLD (Child exited) @ 0 (0) ---
sigreturn() = ? (mask now [])
--- SIGCHLD (Child exited) @ 0 (0) ---
sigreturn() = ? (mask now [])
wait4(-1, NULL, 0, NULL)= 9515
wait4(-1, NULL, 0, NULL)= 9517
wait4(-1, NULL, 0, NULL)= 9524
wait4(-1, NULL, 0, NULL)= 9525
--- SIGCHLD (Child exited) @ 0 (0) ---
sigreturn() = ? (mask now [])
--- SIGCHLD (Child exited) @ 0 (0) ---
sigreturn() = ? (mask now [])
--- SIGCHLD (Child exited) @ 0 (0) ---
sigreturn() = ? (mask now [])
--- SIGCHLD (Child exited) @ 0 (0) ---
sigreturn() = ? (mask now [])
wait4(-1, NULL, 0, NULL)= 9511
wait4(-1, NULL, 0, NULL)= 9513
wait4(-1, NULL, 0, NULL)= 9518
wait4(-1, NULL, 0, NULL)= 9523
wait4(-1, NULL, 0, NULL)= -1 ECHILD (No child processes)
rt_sigaction(SIGALRM, {0x8066080, [ALRM], SA_RESTART}, {0x8065920, [ALRM],
SA_RESTART}, 8) = 0 stat64(/tmp/opensips_fifo, {st_mode=S_IFIFO|0660,
st_size=0, ...}) = 0
unlink(/tmp/opensips_fifo)= 0
munmap(0xaed25000, 134217728) = 0
unlink(/var/run/opensips/opensips.pid) = 0
alarm(0)= 60
rt_sigaction(SIGALRM, {SIG_IGN}, {0x8066080, [ALRM], SA_RESTART}, 8) = 0
exit_group(0) = ?
Process 9509 detached
--
Comment By: Alex Massover (cupotka2008)
Date: 2010-01-22 16:51
Message:
I just discovered 'fifo ps' command :)
read(7, :get_statistics:opensips_receiver..., 4096) = 45
open(/tmp/opensips_receiver_18361, O_WRONLY|O_NONBLOCK) = 10
fstat64(10, {st_mode=S_IFIFO|0666, st_size=0, ...}) = 0
lstat64(/tmp/opensips_receiver_18361, {st_mode=S_IFIFO|0666, st_size=0,
...}) = 0
fcntl64(10, F_GETFL)= 0x801 (flags
O_WRONLY|O_NONBLOCK)
fcntl64(10, F_SETFL, O_WRONLY) = 0
fcntl64(10, F_GETFL)= 0x1 (flags O_WRONLY)
[OpenSIPS-Devel] [ opensips-Bugs-2934618 ] possible memory leak in serialize.c
Bugs item #2934618, was opened at 2010-01-18 23:27 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=2934618group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: core Group: 1.6.x Status: Open Resolution: Fixed Priority: 5 Private: No Submitted By: Richard Revels (rrevels) Assigned to: Bogdan-Andrei Iancu (bogdan_iancu) Summary: possible memory leak in serialize.c Initial Comment: We have been chasing what appears to be a memory leak in opensips-1.6.1-notls. We believe that in serialize_branches line 154 enc_info is being allocated but is not being freed in all cases. We will continue tracking this but wanted to get it out where other eyes could look into it as well. -- Comment By: Nobody/Anonymous (nobody) Date: 2010-01-22 16:11 Message: The patch has fixed the issue for us. We are no longer able to detect any memory leakage at all. -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2010-01-21 17:34 Message: Hi Richard, Indeed there was a mem leak there - could you test the attached patch? it should fix the problem. If ok, I will upload the patch on SVN. Thanks and regards, Bogdan -- Comment By: Richard Revels (rrevels) Date: 2010-01-19 15:56 Message: To add to this, we think enc_info gets malloc'd. Then contacts[i].enc_info is set to that pointer. Then val.s is also set to that pointer. Next val is used in a call to add_avp for serial_avp. This malloc's and copies the data from val. val is left hanging on exit from serialize_branches and if the pointer is freed from the contacts structure, we haven't found that yet. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=2934618group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] SF.net SVN: opensips:[6524] branches/1.6/serialize.c
Revision: 6524 http://opensips.svn.sourceforge.net/opensips/?rev=6524view=rev Author: bogdan_iancu Date: 2010-01-22 16:35:07 + (Fri, 22 Jan 2010) Log Message: --- backport from trunk (rev 6523): - fixed memory leak in serialize function. Reported by Richard Revels Closes bug 2934618 Revision Links: -- http://opensips.svn.sourceforge.net/opensips/?rev=6523view=rev Modified Paths: -- branches/1.6/serialize.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-2934618 ] possible memory leak in serialize.c
Bugs item #2934618, was opened at 2010-01-19 01:27 Message generated for change (Settings changed) made by bogdan_iancu You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=2934618group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: core Group: 1.6.x Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Richard Revels (rrevels) Assigned to: Bogdan-Andrei Iancu (bogdan_iancu) Summary: possible memory leak in serialize.c Initial Comment: We have been chasing what appears to be a memory leak in opensips-1.6.1-notls. We believe that in serialize_branches line 154 enc_info is being allocated but is not being freed in all cases. We will continue tracking this but wanted to get it out where other eyes could look into it as well. -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2010-01-22 18:35 Message: patch uploaded on SVN -- Comment By: Nobody/Anonymous (nobody) Date: 2010-01-22 18:11 Message: The patch has fixed the issue for us. We are no longer able to detect any memory leakage at all. -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2010-01-21 19:34 Message: Hi Richard, Indeed there was a mem leak there - could you test the attached patch? it should fix the problem. If ok, I will upload the patch on SVN. Thanks and regards, Bogdan -- Comment By: Richard Revels (rrevels) Date: 2010-01-19 17:56 Message: To add to this, we think enc_info gets malloc'd. Then contacts[i].enc_info is set to that pointer. Then val.s is also set to that pointer. Next val is used in a call to add_avp for serial_avp. This malloc's and copies the data from val. val is left hanging on exit from serialize_branches and if the pointer is freed from the contacts structure, we haven't found that yet. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=2934618group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] SF.net SVN: opensips:[6525] trunk/modules/snmpstats/sub_agent.c
Revision: 6525 http://opensips.svn.sourceforge.net/opensips/?rev=6525view=rev Author: bogdan_iancu Date: 2010-01-22 16:46:03 + (Fri, 22 Jan 2010) Log Message: --- - fixed bug in signal handler - the extra proc must use the SIGUSR2 handler from the core, otherwise it will die when core will try to collect pkg mem stats (via SIGUSR2). NOTE the SIGUSR2 terminates the proc if not handled. Reported by Alex Massover. Thanks to Richard Revels for the hints Closes bug 2936343. Modified Paths: -- trunk/modules/snmpstats/sub_agent.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] SF.net SVN: opensips:[6526] branches/1.6/modules/snmpstats/sub_agent.c
Revision: 6526 http://opensips.svn.sourceforge.net/opensips/?rev=6526view=rev Author: bogdan_iancu Date: 2010-01-22 16:47:24 + (Fri, 22 Jan 2010) Log Message: --- backport from trunk (rev #6525): - fixed bug in signal handler - the extra proc must use the SIGUSR2 handler from the core, otherwise it will die when core will try to collect pkg mem stats (via SIGUSR2). NOTE the SIGUSR2 terminates the proc if not handled. Reported by Alex Massover. Thanks to Richard Revels for the hints Closes bug 2936343 Revision Links: -- http://opensips.svn.sourceforge.net/opensips/?rev=6525view=rev Modified Paths: -- branches/1.6/modules/snmpstats/sub_agent.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-2936343 ] 'opensipsctl fifo get_statistics all' crashes opensips
Bugs item #2936343, was opened at 2010-01-21 15:51
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=1086410aid=2936343group_id=232389
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.6.x
Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Alex Massover (cupotka2008)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: 'opensipsctl fifo get_statistics all' crashes opensips
Initial Comment:
Hi!
'opensipsctl fifo get_statistics all' always crashes opensips. Core is somehow
not produced.
Always reproducible for me on 1.6.1.
Here's a strace of parent process:
Process 9509 attached - interrupt to quit
pause() = ? ERESTARTNOHAND (To be restarted)
--- SIGUSR2 (User defined signal 2) @ 0 (0) ---
sigreturn() = ? (mask now [])
pause() = ? ERESTARTNOHAND (To be restarted)
--- SIGCHLD (Child exited) @ 0 (0) ---
sigreturn() = ? (mask now [])
waitpid(-1, [{WIFSIGNALED(s) WTERMSIG(s) == SIGUSR2}], WNOHANG) = 9520
waitpid(-1, 0xbf84b4c8, WNOHANG)= 0
kill(0, SIGTERM)= 0
--- SIGTERM (Terminated) @ 0 (0) ---
--- SIGCHLD (Child exited) @ 0 (0) ---
sigreturn() = ? (mask now [TERM])
sigreturn() = ? (mask now [])
rt_sigaction(SIGALRM, {0x8065920, [ALRM], SA_RESTART}, {SIG_DFL}, 8) = 0
alarm(60) = 0
wait4(-1, NULL, 0, NULL)= 9514
wait4(-1, NULL, 0, NULL)= 9519
wait4(-1, NULL, 0, NULL)= 9521
wait4(-1, NULL, 0, NULL)= 9522
wait4(-1, NULL, 0, NULL)= 9512
--- SIGCHLD (Child exited) @ 0 (0) ---
sigreturn() = ? (mask now [])
--- SIGCHLD (Child exited) @ 0 (0) ---
sigreturn() = ? (mask now [])
wait4(-1, NULL, 0, NULL)= 9510
wait4(-1, NULL, 0, NULL)= 9516
--- SIGCHLD (Child exited) @ 0 (0) ---
sigreturn() = ? (mask now [])
--- SIGCHLD (Child exited) @ 0 (0) ---
sigreturn() = ? (mask now [])
wait4(-1, NULL, 0, NULL)= 9515
wait4(-1, NULL, 0, NULL)= 9517
wait4(-1, NULL, 0, NULL)= 9524
wait4(-1, NULL, 0, NULL)= 9525
--- SIGCHLD (Child exited) @ 0 (0) ---
sigreturn() = ? (mask now [])
--- SIGCHLD (Child exited) @ 0 (0) ---
sigreturn() = ? (mask now [])
--- SIGCHLD (Child exited) @ 0 (0) ---
sigreturn() = ? (mask now [])
--- SIGCHLD (Child exited) @ 0 (0) ---
sigreturn() = ? (mask now [])
wait4(-1, NULL, 0, NULL)= 9511
wait4(-1, NULL, 0, NULL)= 9513
wait4(-1, NULL, 0, NULL)= 9518
wait4(-1, NULL, 0, NULL)= 9523
wait4(-1, NULL, 0, NULL)= -1 ECHILD (No child processes)
rt_sigaction(SIGALRM, {0x8066080, [ALRM], SA_RESTART}, {0x8065920, [ALRM],
SA_RESTART}, 8) = 0 stat64(/tmp/opensips_fifo, {st_mode=S_IFIFO|0660,
st_size=0, ...}) = 0
unlink(/tmp/opensips_fifo)= 0
munmap(0xaed25000, 134217728) = 0
unlink(/var/run/opensips/opensips.pid) = 0
alarm(0)= 60
rt_sigaction(SIGALRM, {SIG_IGN}, {0x8066080, [ALRM], SA_RESTART}, 8) = 0
exit_group(0) = ?
Process 9509 detached
--
Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2010-01-22 18:48
Message:
Thanks to Richard Revels about the hint on snmp module...Indeed, the bug
was in that module as it was overriding the SIGUSR2 handler which was
installed by core.
Fix is on SVN.
Thanks to all,
Bogdan
--
Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2010-01-22 17:35
Message:
Alex, I'm investigating some possibilitiesCould you apply the patch I
just uploaded here? Just to see if my suspicion is right. BTW, what modules
are you loading ?
Thanks and regards,
Bogdan
--
Comment By: Alex Massover (cupotka2008)
Date: 2010-01-22 16:51
Message:
I just discovered 'fifo ps' command :)
read(7, :get_statistics:opensips_receiver..., 4096) = 45
open(/tmp/opensips_receiver_18361, O_WRONLY|O_NONBLOCK) = 10
fstat64(10, {st_mode=S_IFIFO|0666, st_size=0, ...}) = 0
lstat64(/tmp/opensips_receiver_18361, {st_mode=S_IFIFO|0666, st_size=0,
...}) = 0
fcntl64(10, F_GETFL)= 0x801 (flags
O_WRONLY|O_NONBLOCK)
fcntl64(10, F_SETFL, O_WRONLY) =
[OpenSIPS-Devel] [B2B_ENTITIES] Difference between sending CANCEL and BYE
Hi, I would like to break a SIP communication during a call or a proceeding SIP session... If the call is in progress (Caller can speak to Callee), I can send a BYE to caller and callee each with send_request function; Here is my Wireshark trace: BYE sip:s...@1.1.12.3 SIP/2.0 Via: SIP/2.0/UDP 2.2.22.2;branch=z9hG4bKda73.5742b3a7.0 From: sip:1...@2.2.22.2;tag=934c0604001f8a49c065a1707fbb682d-59cf To: sip:2...@1.1.12.3;tag=B2B.333.0.1264181639 CSeq: 4 BYE Call-ID: B2B.269.0.1264181639 Content-Length: 0 User-Agent: OpenSIPS (1.6.1-notls (i386/linux)) Contact: sip:s...@2.2.22.2 If the sip session is proceeding (Caller send INVITE but he hasn't receive 200 OK yet), I send a CANCEL like I sent the BYE (send_request); But here is my Wireshark trace: CANCEL sip:2...@1.1.12.3 SIP/2.0 Via: SIP/2.0/UDP 2.2.22.2;branch=z9hG4bK5161.0ab21263.0 From: sip:1...@2.2.22.2;tag=934c0604001f8a49c065a1707fbb682d-ac1f To: sip:2...@1.1.12.3 CSeq: 2 CANCEL Call-ID: B2B.134.0.1264181129 User-Agent: OpenSIPS (1.6.1-notls (i386/linux)) Contact: sip:s...@2.2.22.2 Why is the Request Line not for sip:s...@1.1.12.3 as for the BYE? Regards, -- Olivier Détour Sent from Paris, Île-de-France, France ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [B2B_ENTITIES] Difference between sending CANCEL and BYE
Hi Oliver, BYE is a sequential request and id built based on the 200 OK from INVITE, while CANCEL is special request that is send before getting the 200 OK - there are different contexts and the 2 requests are build in different ways. I strongly suggest to read the RFC3261 about building CANCEL and sequential request - it the best source. Regards, Bogdan Olivier Détour wrote: Hi, I would like to break a SIP communication during a call or a proceeding SIP session... If the call is in progress (Caller can speak to Callee), I can send a BYE to caller and callee each with send_request function; Here is my Wireshark trace: BYE sip:s...@1.1.12.3 SIP/2.0 Via: SIP/2.0/UDP 2.2.22.2;branch=z9hG4bKda73.5742b3a7.0 From: sip:1...@2.2.22.2;tag=934c0604001f8a49c065a1707fbb682d-59cf To: sip:2...@1.1.12.3;tag=B2B.333.0.1264181639 CSeq: 4 BYE Call-ID: B2B.269.0.1264181639 Content-Length: 0 User-Agent: OpenSIPS (1.6.1-notls (i386/linux)) Contact: sip:s...@2.2.22.2 If the sip session is proceeding (Caller send INVITE but he hasn't receive 200 OK yet), I send a CANCEL like I sent the BYE (send_request); But here is my Wireshark trace: CANCEL sip:2...@1.1.12.3 SIP/2.0 Via: SIP/2.0/UDP 2.2.22.2;branch=z9hG4bK5161.0ab21263.0 From: sip:1...@2.2.22.2;tag=934c0604001f8a49c065a1707fbb682d-ac1f To: sip:2...@1.1.12.3 CSeq: 2 CANCEL Call-ID: B2B.134.0.1264181129 User-Agent: OpenSIPS (1.6.1-notls (i386/linux)) Contact: sip:s...@2.2.22.2 Why is the Request Line not for sip:s...@1.1.12.3 as for the BYE? Regards, -- Bogdan-Andrei Iancu www.voice-system.ro ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [B2B_ENTITIES] Difference between sending CANCEL and BYE
BYEs are sequential (in-dialog) requests that go to the RURI that is the Contact returned in the final 2xx reply. CANCELs are sent to the proximate endpoint - same RURI as initial INVITE request. They are not sequential requests, are not loose- routed, etc. So, the behaviour you are seeing is normal. -- Sent from mobile device On Jan 22, 2010, at 12:55 PM, Olivier Détour chino540off+kamai...@gmail.co m wrote: Hi, I would like to break a SIP communication during a call or a proceeding SIP session... If the call is in progress (Caller can speak to Callee), I can send a BYE to caller and callee each with send_request function; Here is my Wireshark trace: BYE sip:s...@1.1.12.3 SIP/2.0 Via: SIP/2.0/UDP 2.2.22.2;branch=z9hG4bKda73.5742b3a7.0 From: sip:1...@2.2.22.2;tag=934c0604001f8a49c065a1707fbb682d-59cf To: sip:2...@1.1.12.3;tag=B2B.333.0.1264181639 CSeq: 4 BYE Call-ID: B2B.269.0.1264181639 Content-Length: 0 User-Agent: OpenSIPS (1.6.1-notls (i386/linux)) Contact: sip:s...@2.2.22.2 If the sip session is proceeding (Caller send INVITE but he hasn't receive 200 OK yet), I send a CANCEL like I sent the BYE (send_request); But here is my Wireshark trace: CANCEL sip:2...@1.1.12.3 SIP/2.0 Via: SIP/2.0/UDP 2.2.22.2;branch=z9hG4bK5161.0ab21263.0 From: sip:1...@2.2.22.2;tag=934c0604001f8a49c065a1707fbb682d-ac1f To: sip:2...@1.1.12.3 CSeq: 2 CANCEL Call-ID: B2B.134.0.1264181129 User-Agent: OpenSIPS (1.6.1-notls (i386/linux)) Contact: sip:s...@2.2.22.2 Why is the Request Line not for sip:s...@1.1.12.3 as for the BYE? Regards, -- Olivier Détour Sent from Paris, Île-de-France, France ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [B2B_ENTITIES] Difference between sending CANCEL and BYE
Hi, I understand the problem, but I would like to explain you my topology: Broker1 Broker2 | | Tel(10) -- B2BUA1 -- B2BUA2 -- Tel(20) My problem is when 10 calls 20, 20 is ringing (so B2BUAs create their UAS and UAC). I want to be able to brake the current SIP session at this moment. So I send the CANCEL to UAC side on B2BUA1. But B2BUA2 doesn't want to receive it, because It is not send to sip:s...@1.1.12.3. So message could not be transmit to B2BUA2 ... Maybe, I don't understand something here, but b2b_entities API could be able to manage this situation ? Regards, -- Olivier Détour Sent from Paris, Ile-de-France, France ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-2937441 ] opensips crashes on reply recieved to b2bua
Bugs item #2937441, was opened at 2010-01-22 20:06 Message generated for change (Tracker Item Submitted) made by rrevels You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=2937441group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: 1.6.x Status: Open Resolution: None Priority: 5 Private: No Submitted By: Richard Revels (rrevels) Assigned to: Nobody/Anonymous (nobody) Summary: opensips crashes on reply recieved to b2bua Initial Comment: using opensips 1.6 revision 6526 Here are a couple of backtraces from two core files. I am seeing this on every call using top hiding in b2bua. If is simply route the calls without b2bua opensips doesn't crash. Crash with two processing threads. Using media proxy on outbound leg. [New process 29632] #0 __dialog_confirmed (dlg=0x2af97535b6b0, type=value optimized out, _params=0x2af9709346a0) at nat_traversal.c:968 968 snprintf(uri, 64, sip:%s:%d, ip_addr2a(msg-rcv.src_ip), msg-rcv.src_port); (gdb) bt #0 __dialog_confirmed (dlg=0x2af97535b6b0, type=value optimized out, _params=0x2af9709346a0) at nat_traversal.c:968 #1 0x2af970708e44 in run_dlg_callbacks (type=8, dlg=0x2af97535b6b0, msg=value optimized out, dir=1966453448, dlg_data=0x0) at dlg_cb.c:253 #2 0x2af97071683a in dlg_onreply (t=0x2af97535bc78, type=value optimized out, param=value optimized out) at dlg_handlers.c:407 #3 0x2af96e3ea02b in run_trans_callbacks (type=128, trans=0x2af97535bc78, req=0x2af97535d628, rpl=0x, code=value optimized out) at t_hooks.c:208 #4 0x2af96e40333b in _reply_light (trans=0x2af97535bc78, buf=0x862bf8 SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP 10.1.71.226:53239;rport=4609;branch=z9hG4bKPjufub93nobQZJjltsV8VEofSrwBOh3qDb;received=192.168.230.200\r\nFrom: \Richard Revels\ sip:+19195551...@59.229.150.203.sta.inet.co.th;t..., len=824, code=200, to_tag=value optimized out, to_tag_len=value optimized out, lock=1, bm=0x7fff7ccec800) at t_reply.c:384 #5 0x2af96e4035a3 in t_reply_with_body (trans=0x2af97535bc78, code=200, text=0x860e70, body=value optimized out, new_header=value optimized out, to_tag=0x2af9753611d0) at t_reply.c:1607 #6 0x2af97471369e in b2b_send_reply (et=value optimized out, b2b_key=0x2af9753611d0, code=200, text=0x860e70, body=0x7fff7ccecb00, extra_headers=0x7fff7ccecaf0) at dlg.c:803 #7 0x2af974926803 in b2b_logic_notify (src=1, msg=0x860e40, key=0x2af97535f4e8, type=1, param=value optimized out) at logic.c:444 #8 0x2af9747150e0 in b2b_tm_cback (htable=0x2af97533e928, ps=value optimized out) at dlg.c:1515 #9 0x2af96e3ea02b in run_trans_callbacks (type=512, trans=0x2af97535f528, req=0x0, rpl=0x860e40, code=value optimized out) at t_hooks.c:208 #10 0x2af96e4026e9 in local_reply (t=0x2af97535f528, p_msg=0x2af96e626d38, branch=value optimized out, msg_status=value optimized out, cancel_bitmap=0x2af975311f48) at t_reply.c:1339 #11 0x2af96e405009 in reply_received (p_msg=0x860e40) at t_reply.c:1484 #12 0x004213f8 in forward_reply (msg=0x860e40) at forward.c:559 #13 0x00456202 in receive_msg ( buf=0x754f40 SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP 203.150.229.59;branch=z9hG4bK25c3.26e79485.0\r\nRecord-Route: sip:192.168.225.202;lr;ftag=5e133d1dcbcfa06f788b415da1ea9e73-f19a,sip:203.150.229.59;lr;ftag=5e133d1dcbcfa06f788b..., len=1007, rcv_info=0x7fff7cced080) at receive.c:200 #14 0x0049a2d4 in udp_rcv_loop () at udp_server.c:492 #15 0x00429bbd in main (argc=9, argv=value optimized out) at main.c:818 Crash with two processing threads and stun on client - no media proxy. [New process 30101] #0 b2b_send_reply (et=value optimized out, b2b_key=0x2ad29f4fa058, code=183, text=0x860938, body=0x7fffe9fc4fd0, extra_headers=0x7fffe9fc4fc0) at dlg.c:762 762 to_tag = get_to(msg)-tag_value; (gdb) bt #0 b2b_send_reply (et=value optimized out, b2b_key=0x2ad29f4fa058, code=183, text=0x860938, body=0x7fffe9fc4fd0, extra_headers=0x7fffe9fc4fc0) at dlg.c:762 #1 0x2ad29eabf803 in b2b_logic_notify (src=1, msg=0x860908, key=0x2ad29f4f8368, type=1, param=value optimized out) at logic.c:444 #2 0x2ad29e8ae0e0 in b2b_tm_cback (htable=0x2ad29f4d7928, ps=value optimized out) at dlg.c:1515 #3 0x2ad29858302b in run_trans_callbacks (type=1024, trans=0x2ad29f4f83a8, req=0x0, rpl=0x860908, code=value optimized out) at t_hooks.c:208 #4 0x2ad29859b4ee in local_reply (t=0x2ad29f4f83a8, p_msg=0x860908, branch=value optimized out, msg_status=value optimized out, cancel_bitmap=0x7fffe9fc5468) at t_reply.c:1333 #5 0x2ad29859e009 in reply_received (p_msg=0x860908) at t_reply.c:1484 #6 0x004213f8 in forward_reply (msg=0x860908) at forward.c:559 #7 0x00456202 in receive_msg ( buf=0x754f40 SIP/2.0 183 Session Progress\r\nVia:
