Re: [OpenSIPS-Users] Truncated Branch in Via

[Gupta, Rahul]

Hi Bogdan, thanks for the prompt response and providing the fix. We have tested 
it and it works fine. Are you going to put this in any build ?


Thanks
Rahul Gupta
Systems Architect
T +1 732-690-3845  *   E rahul.gu...@ipc.com<mailto:rahul.gu...@ipc.com>

[cid:image006.jpg@01D1940F.3E021840]


From: Bogdan-Andrei Iancu [mailto:bog...@opensips.org]
Sent: Monday, July 11, 2016 12:42 PM
To: OpenSIPS users mailling list; Gupta, Rahul
Subject: Re: [OpenSIPS-Users] Truncated Branch in Via

Hi Rahul,

There is a fix available for extra testing - see :

https://github.com/OpenSIPS/opensips/commit/482e643469b351d12418ff54c96beee7b27dca94

please give it a try and let me know if it is solving the problem for you too.

Regards,


Bogdan-Andrei Iancu

OpenSIPS Founder and Developer

http://www.opensips-solutions.com
On 08.07.2016 17:30, Bogdan-Andrei Iancu wrote:
Hi Rahul,

Indeed, that is a good point here, thanks for bring it up. Let me investigate 
the code a bit and I will update you.

Regards,


Bogdan-Andrei Iancu

OpenSIPS Founder and Developer

http://www.opensips-solutions.com
On 07.07.2016 22:01, Gupta, Rahul wrote:
Hi Bogdan, so the problem we are facing is the endpoint has a new branch 
however the difference in the branch value is AFTER the MAX_BRANCH_PARAM_LEN, 
the highlighted text. Since opensips is copying the partial branch which is 
same as the previous Via and thus our SIP stack (OCCAS) is sending back 401 
Unauthorized for both thinking it's a retransmit.

This is also in line with RFC3261. Shouldn't it copy the entire Via to make 
sure it's different from previous Message ?

REGISTER 1
Via: SIP/2.0/UDP 
10.204.70.156:5060;branch=z9hG4bK1c68e33e-848e-412a-9137-4fb065a7b7eb_0efbfc5e_11391
Via: SIP/2.0/UDP 
10.205.236.44:5060;branch=z9hG4bK1c68e33e-848e-412a-9137-4fb065a7b7eb_0efbfc5e_113915620064228_MTAuMTIuMy4xMQ

REGISTER 2
Via: SIP/2.0/UDP 
10.204.70.156:5060;branch=z9hG4bK1c68e33e-848e-412a-9137-4fb065a7b7eb_0efbfc5e_11391
Via: SIP/2.0/UDP 
10.205.236.44:5060;branch=z9hG4bK1c68e33e-848e-412a-9137-4fb065a7b7eb_0efbfc5e_113915656050004_MTAuMTIuMy4xMQ


Thanks
Rahul Gupta
Systems Architect
T +1 732-690-3845  *   E rahul.gu...@ipc.com<mailto:rahul.gu...@ipc.com>

[cid:image006.jpg@01D1940F.3E021840]



From: Bogdan-Andrei Iancu [mailto:bog...@opensips.org]
Sent: Thursday, July 07, 2016 4:43 AM
To: Gupta, Rahul
Cc: Elliott, Ray; users@lists.opensips.org<mailto:users@lists.opensips.org>
Subject: Re: [OpenSIPS-Users] Truncated Branch in Via

Hi Rahul,

The received VIA hdr (with the .44 IP) is properly preserved when forwarding 
(in the outbound message).

The VIA hdr added by OpenSIPS ( .156 IP) is a completely new VIA and its branch 
value is completely independent from the branch of other VIA hdrs.

Why do they look the same ? The RFC3261 says that for stateless fwd (when 
basically there is no transaction, so no branch value), to avoid populating its 
VIA with ";branch=0" , the proxy may "copy" and use a branch value from an 
older VIA (a received VIA) - keep in mind it does not say to copy it entirely 
or part. So, OpenSIPS copies a MAX_BRANCH_PARAM_LEN length string from the 
previous branch param.

Everything is correct and legal (from RFC perspective).

PS: if you would use t_relay() instead of forward() - doing statefull proxy -, 
you will see that the branch in the VIA added by OpenSIPS will be completly 
different from the value in the previous VIA.

Best regards,



Bogdan-Andrei Iancu

OpenSIPS Founder and Developer

http://www.opensips-solutions.com
On 07.07.2016 03:42, Gupta, Rahul wrote:
Hi Bogdan,

Here is a Ethernet trace (pcap) file that has a successful and an unsuccessful 
registration.

Frames 1-8 illustrate the successful case with Frames 2 and 6 show how opensips 
adds an extra VIA header that has a full VIA;branch
Frame:2
Via: SIP/2.0/UDP 
10.204.70.156:5060;branch=z9hG4bK-c45d6-2ff0ce63-4583dc45-6bd144f8
Via: SIP/2.0/UDP 
10.204.45.122:5060;branch=z9hG4bK-c45d6-2ff0ce63-4583dc45-6bd144f8

Frames 9-16 illustrate the unsuccessful case where Frames 10 and 14 show how 
opensips adds an extra VIA header that has a truncated branch.
Frame 10:
Via: SIP/2.0/UDP 
10.204.70.156:5060;branch=z9hG4bK1c68e33e-848e-412a-9137-4fb065a7b7eb_0efbfc5e_11391
Via: SIP/2.0/UDP 
10.205.236.44:5060;branch=z9hG4bK1c68e33e-848e-412a-9137-4fb065a7b7eb_0efbfc5e_113915620064228_MTAuMTIuMy4xMQ

Thanks
Rahul Gupta
Systems Architect
T +1 732-690-3845  *   E rahul.gu...@ipc.com<mailto:rahul.gu...@ipc.com>

[cid:image006.jpg@01D1940F.3E021840]



From: Bogdan-Andrei Iancu [mailto:bog...@opensips.org]
Sent: Wednesday, July 06, 2016 5:38 AM
To: OpenSIPS users mailling list
Cc: Elliott, Ray; Gupta, Rahul
Subject: Re: [OpenSIPS-Users] Truncated Branch in Via

Hi Rahul,

That define is used to calculate the the max VIA len when OpenSIPS is 
generating its own VIA headers. That max len does not impact the VIA headers 
which were received.

I do not understa

Re: [OpenSIPS-Users] Truncated Branch in Via

[Gupta, Rahul]

Hi Bogdan, thanks for the prompt response and providing the fix. We have tested 
it and it works fine. Are you going to put this in any build ?


Thanks
Rahul Gupta
Systems Architect
T +1 732-690-3845  *   E rahul.gu...@ipc.com<mailto:rahul.gu...@ipc.com>

[cid:image006.jpg@01D1940F.3E021840]


From: Bogdan-Andrei Iancu [mailto:bog...@opensips.org]
Sent: Monday, July 11, 2016 12:42 PM
To: OpenSIPS users mailling list; Gupta, Rahul
Subject: Re: [OpenSIPS-Users] Truncated Branch in Via

Hi Rahul,

There is a fix available for extra testing - see :

https://github.com/OpenSIPS/opensips/commit/482e643469b351d12418ff54c96beee7b27dca94

please give it a try and let me know if it is solving the problem for you too.

Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer

http://www.opensips-solutions.com
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Truncated Branch in Via

[Gupta, Rahul]

Hi Bogdan, so the problem we are facing is the endpoint has a new branch 
however the difference in the branch value is AFTER the MAX_BRANCH_PARAM_LEN, 
the highlighted text. Since opensips is copying the partial branch which is 
same as the previous Via and thus our SIP stack (OCCAS) is sending back 401 
Unauthorized for both thinking it's a retransmit.

This is also in line with RFC3261. Shouldn't it copy the entire Via to make 
sure it's different from previous Message ?

REGISTER 1
Via: SIP/2.0/UDP 
10.204.70.156:5060;branch=z9hG4bK1c68e33e-848e-412a-9137-4fb065a7b7eb_0efbfc5e_11391
Via: SIP/2.0/UDP 
10.205.236.44:5060;branch=z9hG4bK1c68e33e-848e-412a-9137-4fb065a7b7eb_0efbfc5e_113915620064228_MTAuMTIuMy4xMQ

REGISTER 2
Via: SIP/2.0/UDP 
10.204.70.156:5060;branch=z9hG4bK1c68e33e-848e-412a-9137-4fb065a7b7eb_0efbfc5e_11391
Via: SIP/2.0/UDP 
10.205.236.44:5060;branch=z9hG4bK1c68e33e-848e-412a-9137-4fb065a7b7eb_0efbfc5e_113915656050004_MTAuMTIuMy4xMQ


Thanks
Rahul Gupta
Systems Architect
T +1 732-690-3845  *   E rahul.gu...@ipc.com<mailto:rahul.gu...@ipc.com>

[cid:image006.jpg@01D1940F.3E021840]



From: Bogdan-Andrei Iancu [mailto:bog...@opensips.org]
Sent: Thursday, July 07, 2016 4:43 AM
To: Gupta, Rahul
Cc: Elliott, Ray; users@lists.opensips.org
Subject: Re: [OpenSIPS-Users] Truncated Branch in Via

Hi Rahul,

The received VIA hdr (with the .44 IP) is properly preserved when forwarding 
(in the outbound message).

The VIA hdr added by OpenSIPS ( .156 IP) is a completely new VIA and its branch 
value is completely independent from the branch of other VIA hdrs.

Why do they look the same ? The RFC3261 says that for stateless fwd (when 
basically there is no transaction, so no branch value), to avoid populating its 
VIA with ";branch=0" , the proxy may "copy" and use a branch value from an 
older VIA (a received VIA) - keep in mind it does not say to copy it entirely 
or part. So, OpenSIPS copies a MAX_BRANCH_PARAM_LEN length string from the 
previous branch param.

Everything is correct and legal (from RFC perspective).

PS: if you would use t_relay() instead of forward() - doing statefull proxy -, 
you will see that the branch in the VIA added by OpenSIPS will be completly 
different from the value in the previous VIA.

Best regards,


Bogdan-Andrei Iancu

OpenSIPS Founder and Developer

http://www.opensips-solutions.com
On 07.07.2016 03:42, Gupta, Rahul wrote:
Hi Bogdan,

Here is a Ethernet trace (pcap) file that has a successful and an unsuccessful 
registration.

Frames 1-8 illustrate the successful case with Frames 2 and 6 show how opensips 
adds an extra VIA header that has a full VIA;branch
Frame:2
Via: SIP/2.0/UDP 
10.204.70.156:5060;branch=z9hG4bK-c45d6-2ff0ce63-4583dc45-6bd144f8
Via: SIP/2.0/UDP 
10.204.45.122:5060;branch=z9hG4bK-c45d6-2ff0ce63-4583dc45-6bd144f8

Frames 9-16 illustrate the unsuccessful case where Frames 10 and 14 show how 
opensips adds an extra VIA header that has a truncated branch.
Frame 10:
Via: SIP/2.0/UDP 
10.204.70.156:5060;branch=z9hG4bK1c68e33e-848e-412a-9137-4fb065a7b7eb_0efbfc5e_11391
Via: SIP/2.0/UDP 
10.205.236.44:5060;branch=z9hG4bK1c68e33e-848e-412a-9137-4fb065a7b7eb_0efbfc5e_113915620064228_MTAuMTIuMy4xMQ

Thanks
Rahul Gupta
Systems Architect
T +1 732-690-3845  *   E rahul.gu...@ipc.com<mailto:rahul.gu...@ipc.com>

[cid:image006.jpg@01D1940F.3E021840]



From: Bogdan-Andrei Iancu [mailto:bog...@opensips.org]
Sent: Wednesday, July 06, 2016 5:38 AM
To: OpenSIPS users mailling list
Cc: Elliott, Ray; Gupta, Rahul
Subject: Re: [OpenSIPS-Users] Truncated Branch in Via

Hi Rahul,

That define is used to calculate the the max VIA len when OpenSIPS is 
generating its own VIA headers. That max len does not impact the VIA headers 
which were received.

I do not understand exactly (in your example) what's the flow of that VIA 
header. If you want, send me off-list the pcap/ngrep showing the SIP package 
(before and after OpenSIPS) and how it is affected.

Regards,



Bogdan-Andrei Iancu

OpenSIPS Founder and Developer

http://www.opensips-solutions.com
On 05.07.2016 20:57, Gupta, Rahul wrote:
We are using opensips 1.11.5 as a stateless proxy and seeing a truncated Branch 
in Via for my REGISTER message. After some code digging, the MAX length is 
calculated using the following formula and seems like its truncating the branch 
after 55 characters. This is causing the REGISTER to fail in our case. Is there 
a config level solution to this ?

#define MAX_BRANCH_PARAM_LEN  (MCOOKIE_LEN+8 /*!<int2hex*/ + 1 /*sep*/ + \
MD5_LEN + 1 /*!<sep*/ + 8 /*int2hex*/ + \
1 /*extra space, needed by t_calc_branch*/)


truncated from opensips -->   Via: SIP/2.0/UDP 
XX.XX.XX.XX:5060;branch=z9hG4bK0fddbbc9-1487-4755-a0b3-0c319155b8c3_0efbfc5e_11160
Via from EndPoint-->   Via: SIP/2.0/UDP 
XX.XX.XX.XX:5060;branch=z9hG4bK0fddbbc9-1487-4755-a0b3-0c319155b8c3_0efbf

[OpenSIPS-Users] Truncated Branch in Via

[Gupta, Rahul]

We are using opensips 1.11.5 as a stateless proxy and seeing a truncated Branch 
in Via for my REGISTER message. After some code digging, the MAX length is 
calculated using the following formula and seems like its truncating the branch 
after 55 characters. This is causing the REGISTER to fail in our case. Is there 
a config level solution to this ?

#define MAX_BRANCH_PARAM_LEN  (MCOOKIE_LEN+8 /*! Via: SIP/2.0/UDP 
XX.XX.XX.XX:5060;branch=z9hG4bK0fddbbc9-1487-4755-a0b3-0c319155b8c3_0efbfc5e_11160
Via from EndPoint-->Via: SIP/2.0/UDP 
XX.XX.XX.XX:5060;branch=z9hG4bK0fddbbc9-1487-4755-a0b3-0c319155b8c3_0efbfc5e_1116078308924346_MTAuMTIuMy4xMQ


Thanks
Rahul Gupta


DISCLAIMER: This e-mail may contain information that is confidential, 
privileged or otherwise protected from disclosure. If you are not an intended 
recipient of this e-mail, do not duplicate or redistribute it by any means. 
Please delete it and any attachments and notify the sender that you have 
received it in error. Unintended recipients are prohibited from taking action 
on the basis of information in this e-mail. E-mail messages may contain 
computer viruses or other defects, may not be accurately replicated on other 
systems, or may be intercepted, deleted or interfered with without the 
knowledge of the sender or the intended recipient. If you are not comfortable 
with the risks associated with e-mail messages, you may decide not to use 
e-mail to communicate with IPC. IPC reserves the right, to the extent and under 
circumstances permitted by applicable law, to retain, monitor and intercept 
e-mail messages to and from its systems.
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] Length Branch in Via header

[Gupta, Rahul]

The branch in Via header is getting truncated in REGISTER. From the code seems 
like the calculation is made using the following


DISCLAIMER: This e-mail may contain information that is confidential, 
privileged or otherwise protected from disclosure. If you are not an intended 
recipient of this e-mail, do not duplicate or redistribute it by any means. 
Please delete it and any attachments and notify the sender that you have 
received it in error. Unintended recipients are prohibited from taking action 
on the basis of information in this e-mail. E-mail messages may contain 
computer viruses or other defects, may not be accurately replicated on other 
systems, or may be intercepted, deleted or interfered with without the 
knowledge of the sender or the intended recipient. If you are not comfortable 
with the risks associated with e-mail messages, you may decide not to use 
e-mail to communicate with IPC. IPC reserves the right, to the extent and under 
circumstances permitted by applicable law, to retain, monitor and intercept 
e-mail messages to and from its systems.
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Method Name from 200OK

[Gupta, Rahul]

Nevermind, I can just use is_method(). If there is another easy way to get the 
method name directly in a variable then please share.

Thanks
Rahul Gupta

From: users-boun...@lists.opensips.org 
[mailto:users-boun...@lists.opensips.org] On Behalf Of Gupta, Rahul
Sent: Thursday, June 16, 2016 11:55 AM
To: users@lists.opensips.org
Subject: [OpenSIPS-Users] Method Name from 200OK

Hi, I am using opensips as stateless proxy. What can I use to find a Reply (200 
OK) is from which Request Method in onreply_route ? I just need Method Name of 
the reply ?

Thanks
Rahul Gupta

--

DISCLAIMER: This e-mail may contain information that is confidential, 
privileged or otherwise protected from disclosure. If you are not an intended 
recipient of this e-mail, do not duplicate or redistribute it by any means. 
Please delete it and any attachments and notify the sender that you have 
received it in error. Unintended recipients are prohibited from taking action 
on the basis of information in this e-mail.E-mail messages may contain computer 
viruses or other defects, may not be accurately replicated on other systems, or 
may be intercepted, deleted or interfered with without the knowledge of the 
sender or the intended recipient. If you are not comfortable with the risks 
associated with e-mail messages, you may decide not to use e-mail to 
communicate with IPC. IPC reserves the right, to the extent and under 
circumstances permitted by applicable law, to retain, monitor and intercept 
e-mail messages to and from its systems.
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] Method Name from 200OK

[Gupta, Rahul]

Hi, I am using opensips as stateless proxy. What can I use to find a Reply (200 
OK) is from which Request Method in onreply_route ? I just need Method Name of 
the reply ?

Thanks
Rahul Gupta

--

DISCLAIMER: This e-mail may contain information that is confidential, 
privileged or otherwise protected from disclosure. If you are not an intended 
recipient of this e-mail, do not duplicate or redistribute it by any means. 
Please delete it and any attachments and notify the sender that you have 
received it in error. Unintended recipients are prohibited from taking action 
on the basis of information in this e-mail.E-mail messages may contain computer 
viruses or other defects, may not be accurately replicated on other systems, or 
may be intercepted, deleted or interfered with without the knowledge of the 
sender or the intended recipient. If you are not comfortable with the risks 
associated with e-mail messages, you may decide not to use e-mail to 
communicate with IPC. IPC reserves the right, to the extent and under 
circumstances permitted by applicable law, to retain, monitor and intercept 
e-mail messages to and from its systems.
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] contact after fix_nated_contact()

[Gupta, Rahul]

Hi Alex, thanks for the quick reply. I don't see if msg_apply_changes() is 
available in opensips. When I use it, I get the bad config file error. I did 
add loadmodule textops.so


Thanks
Rahul Gupta


---

Vote for IPC in the 2016 Waters Technology Awards. Winners are decided by 
people who are most important to us - our customers! Please vote for us (#27, 
#29) by "https://www.surveymonkey.com/r/R6Y27GJ;.



-Original Message-
From: users-boun...@lists.opensips.org 
[mailto:users-boun...@lists.opensips.org] On Behalf Of Alex Balashov
Sent: Monday, May 23, 2016 12:00 PM
To: users@lists.opensips.org
Subject: Re: [OpenSIPS-Users] contact after fix_nated_contact()

On 05/23/2016 11:55 AM, Gupta, Rahul wrote:
> How do I get the updated contact after fix_nated_contact(), for
> example in the log statement  $ct prints the old Contact.
>
> xlog("Contact before fix_nated_contact: $ct");
>
> fix_nated_contact();
>
> xlog("Contact after fix_nated_contact: $ct");

You can run msg_apply_changes() after calling fix_nated_contact(), assuming it 
doesn't have any effects harmful to your cause:

http://kamailio.org/docs/modules/4.4.x/modules/textopsx.html#textopsx.f.msg_apply_changes

-- Alex

--
Alex Balashov | Principal | Evariste Systems LLC
1447 Peachtree Street NE, Suite 700
Atlanta, GA 30309
United States

Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] contact after fix_nated_contact()

[Gupta, Rahul]

How do I get the updated contact after fix_nated_contact(), for example in the 
log statement  $ct prints the old Contact.

xlog("Contact before fix_nated_contact: $ct");
fix_nated_contact();
xlog("Contact after fix_nated_contact: $ct");


Thanks
Rahul Gupta

---

Vote for IPC in the 2016 Waters Technology Awards. Winners are decided by 
people who are most important to us - our customers! Please vote for us (#27, 
#29) by clicking here.

--

DISCLAIMER: This e-mail may contain information that is confidential, 
privileged or otherwise protected from disclosure. If you are not an intended 
recipient of this e-mail, do not duplicate or redistribute it by any means. 
Please delete it and any attachments and notify the sender that you have 
received it in error. Unintended recipients are prohibited from taking action 
on the basis of information in this e-mail.E-mail messages may contain computer 
viruses or other defects, may not be accurately replicated on other systems, or 
may be intercepted, deleted or interfered with without the knowledge of the 
sender or the intended recipient. If you are not comfortable with the risks 
associated with e-mail messages, you may decide not to use e-mail to 
communicate with IPC. IPC reserves the right, to the extent and under 
circumstances permitted by applicable law, to retain, monitor and intercept 
e-mail messages to and from its systems.
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] core generated by opensips

[Gupta, Rahul]

Hi Vlad, thanks for debugging the issue on our server, I appreciate your 
valuable time. I have enabled memory debugging and waiting for the issue to 
happen.

Meanwhile I have uploaded the gdb traces for the deadlock issue which caused 
100% cps you have looked at another server. The link to github issue is github: 
 https://github.com/OpenSIPS/opensips/issues/630


Thanks
Rahul Gupta

From: users-boun...@lists.opensips.org 
[mailto:users-boun...@lists.opensips.org] On Behalf Of Vlad Paiu
Sent: Friday, September 04, 2015 11:59 AM
To: users@lists.opensips.org
Subject: Re: [OpenSIPS-Users] core generated by opensips

Hello,

As per our meeting today, please enable memory debugging on your server, and 
let me know when another crash happens, so I can take a look at the newly 
generated core file.

Regards,


Vlad Paiu

OpenSIPS Developer

http://www.opensips-solutions.com
On 03.09.2015 17:02, Vlad Paiu wrote:
Hello,

Can you replicate the crash on demand, or does it happen randomly ?
Would you be able to provide access to a server containing the core file and 
the OpenSIPS binary, in order to speed-up the debugging process ( avoid the 
ping pong on the mailing list ) ?

Regards,


Vlad Paiu

OpenSIPS Developer

http://www.opensips-solutions.com
On 02.09.2015 18:47, Gupta, Rahul wrote:
Hi Bogdan, any update on this ?

From: Gupta, Rahul
Sent: Monday, August 31, 2015 4:42 PM
To: 'Bogdan-Andrei Iancu'; OpenSIPS users mailling list
Subject: RE: [OpenSIPS-Users] core generated by opensips

Hi Bogdan, following is the info you requested.

#0  0x7f2095572e2c in vfprintf () from /lib64/libc.so.6
#1  0x7f209560fed0 in __vsyslog_chk () from /lib64/libc.so.6
#2  0x7f2095610100 in syslog () from /lib64/libc.so.6
#3  0x004c4202 in tcp_read_req (con=0x7f2081a933c0, 
bytes_read=0x7ffc6bc97f0c) at tcp_read.c:597
#4  0x004c5908 in handle_io (fm=, idx=-1, 
event_type=) at tcp_read.c:1033
#5  0x004c8083 in io_wait_loop_epoll (unix_sock=) 
at io_wait.h:845
#6  tcp_receive_loop (unix_sock=) at tcp_read.c:1141
#7  0x004b12e9 in tcp_init_children (chd_rank=, 
startup_done=0x0) at tcp_main.c:2389
#8  0x0043aebf in main_loop (argc=, argv=) at main.c:1011
#9  main (argc=, argv=) at main.c:1612
(gdb) f 3
#3  0x004c4202 in tcp_read_req (con=0x7f2081a933c0, 
bytes_read=0x7ffc6bc97f0c) at tcp_read.c:597
597 tcp_read.c: No such file or directory.
in tcp_read.c
(gdb) p con->con_req
$1 = (struct tcp_req *) 0x7f20931a97e0
(gdb) p _req
$2 = (struct tcp_req *) 0x82d720
(gdb) p req
$3 = (struct tcp_req *) 0x7f20931a97e0
(gdb) p *con
$4 = {s = 30, fd = 21, write_lock = 0, id = 19, rcv = {src_ip = {af = 2, len = 
4, u = {addrl = {2621885450, 0}, addr32 = {2621885450, 0, 0, 0}, addr16 = 
{52234, 40006, 0, 0, 0, 0, 0, 0},
addr = "\n\314F\234", '\000' }}, dst_ip = {af = 2, 
len = 4, u = {addrl = {2588331018, 0}, addr32 = {2588331018, 0, 0, 0}, addr16 = 
{52234, 39494, 0, 0, 0, 0, 0, 0},
addr = "\n\314F\232", '\000' }}, src_port = 5060, 
dst_port = 5070, proto = 2, proto_reserved1 = 19, proto_reserved2 = 0, src_su = 
{s = {sa_family = 2,
sa_data = "\023\304\n\314F\234\000\000\000\000\000\000\000"}, sin = 
{sin_family = 2, sin_port = 50195, sin_addr = {s_addr = 2621885450}, sin_zero = 
"\000\000\000\000\000\000\000"}},
bind_address = 0x7f2093171398}, refcnt = 2, type = PROTO_TCP, flags = 2, 
state = S_CONN_CONNECT, extra_data = 0x0, timeout = 50039, lifetime = 0, 
id_hash = 19, id_next = 0x0, id_prev = 0x0, c_next = 0x0,
  c_prev = 0x0, con_aliases = {{parent = 0x7f2081a933c0, next = 0x0, prev = 
0x0, port = 5060, hash = 974}, {parent = 0x0, next = 0x0, prev = 0x0, port = 0, 
hash = 0}, {parent = 0x0, next = 0x0, prev = 0x0,
  port = 0, hash = 0}, {parent = 0x0, next = 0x0, prev = 0x0, port = 0, 
hash = 0}}, aliases = 1, con_req = 0x7f20931a97e0, msg_attempts = 1, 
async_chunks = 0x7f2081a93530, async_chunks_no = 0,
  oldest_chunk = 0}
(gdb)

From: Bogdan-Andrei Iancu [mailto:bog...@opensips.org]
Sent: Monday, August 31, 2015 4:39 PM
To: Gupta, Rahul; OpenSIPS users mailling list
Subject: Re: [OpenSIPS-Users] core generated by opensips

And printing :
*con

Thanks,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer

http://www.opensips-solutions.com
On 31.08.2015 22:50, Gupta, Rahul wrote:
Hi Bogdan, following is the info you requested. This is not the first tcp read, 
this server is been running for a while and taking calls.

(gdb) bt
#0  0x7f2095572e2c in vfprintf () from /lib64/libc.so.6
#1  0x7f209560fed0 in __vsyslog_chk () from /lib64/libc.so.6
#2  0x7f2095610100 in syslog () from /lib64/libc.so.6
#3  0x004c4202 in tcp_read_req (con=0x7f2081a933c0, 
bytes_read=0x7ffc6bc97f0c) at tcp_read.c:597
#4  0x004c5908 in handle_io (fm=, idx=-1, 
event_type=) at tcp_read.c:1033
#5  0x004c8083 in io_wait_loop_epoll (unix_sock=) 
at io_wait.h:845
#6  tcp_rece

Re: [OpenSIPS-Users] core generated by opensips

[Gupta, Rahul]

Hi Bogdan, any update on this ?

From: Gupta, Rahul
Sent: Monday, August 31, 2015 4:42 PM
To: 'Bogdan-Andrei Iancu'; OpenSIPS users mailling list
Subject: RE: [OpenSIPS-Users] core generated by opensips

Hi Bogdan, following is the info you requested.

#0  0x7f2095572e2c in vfprintf () from /lib64/libc.so.6
#1  0x7f209560fed0 in __vsyslog_chk () from /lib64/libc.so.6
#2  0x7f2095610100 in syslog () from /lib64/libc.so.6
#3  0x004c4202 in tcp_read_req (con=0x7f2081a933c0, 
bytes_read=0x7ffc6bc97f0c) at tcp_read.c:597
#4  0x004c5908 in handle_io (fm=, idx=-1, 
event_type=) at tcp_read.c:1033
#5  0x004c8083 in io_wait_loop_epoll (unix_sock=) 
at io_wait.h:845
#6  tcp_receive_loop (unix_sock=) at tcp_read.c:1141
#7  0x004b12e9 in tcp_init_children (chd_rank=, 
startup_done=0x0) at tcp_main.c:2389
#8  0x0043aebf in main_loop (argc=, argv=) at main.c:1011
#9  main (argc=, argv=) at main.c:1612
(gdb) f 3
#3  0x004c4202 in tcp_read_req (con=0x7f2081a933c0, 
bytes_read=0x7ffc6bc97f0c) at tcp_read.c:597
597 tcp_read.c: No such file or directory.
in tcp_read.c
(gdb) p con->con_req
$1 = (struct tcp_req *) 0x7f20931a97e0
(gdb) p _req
$2 = (struct tcp_req *) 0x82d720
(gdb) p req
$3 = (struct tcp_req *) 0x7f20931a97e0
(gdb) p *con
$4 = {s = 30, fd = 21, write_lock = 0, id = 19, rcv = {src_ip = {af = 2, len = 
4, u = {addrl = {2621885450, 0}, addr32 = {2621885450, 0, 0, 0}, addr16 = 
{52234, 40006, 0, 0, 0, 0, 0, 0},
addr = "\n\314F\234", '\000' }}, dst_ip = {af = 2, 
len = 4, u = {addrl = {2588331018, 0}, addr32 = {2588331018, 0, 0, 0}, addr16 = 
{52234, 39494, 0, 0, 0, 0, 0, 0},
addr = "\n\314F\232", '\000' }}, src_port = 5060, 
dst_port = 5070, proto = 2, proto_reserved1 = 19, proto_reserved2 = 0, src_su = 
{s = {sa_family = 2,
sa_data = "\023\304\n\314F\234\000\000\000\000\000\000\000"}, sin = 
{sin_family = 2, sin_port = 50195, sin_addr = {s_addr = 2621885450}, sin_zero = 
"\000\000\000\000\000\000\000"}},
bind_address = 0x7f2093171398}, refcnt = 2, type = PROTO_TCP, flags = 2, 
state = S_CONN_CONNECT, extra_data = 0x0, timeout = 50039, lifetime = 0, 
id_hash = 19, id_next = 0x0, id_prev = 0x0, c_next = 0x0,
  c_prev = 0x0, con_aliases = {{parent = 0x7f2081a933c0, next = 0x0, prev = 
0x0, port = 5060, hash = 974}, {parent = 0x0, next = 0x0, prev = 0x0, port = 0, 
hash = 0}, {parent = 0x0, next = 0x0, prev = 0x0,
  port = 0, hash = 0}, {parent = 0x0, next = 0x0, prev = 0x0, port = 0, 
hash = 0}}, aliases = 1, con_req = 0x7f20931a97e0, msg_attempts = 1, 
async_chunks = 0x7f2081a93530, async_chunks_no = 0,
  oldest_chunk = 0}
(gdb)

From: Bogdan-Andrei Iancu [mailto:bog...@opensips.org]
Sent: Monday, August 31, 2015 4:39 PM
To: Gupta, Rahul; OpenSIPS users mailling list
Subject: Re: [OpenSIPS-Users] core generated by opensips

And printing :
*con

Thanks,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer

http://www.opensips-solutions.com
On 31.08.2015 22:50, Gupta, Rahul wrote:
Hi Bogdan, following is the info you requested. This is not the first tcp read, 
this server is been running for a while and taking calls.

(gdb) bt
#0  0x7f2095572e2c in vfprintf () from /lib64/libc.so.6
#1  0x7f209560fed0 in __vsyslog_chk () from /lib64/libc.so.6
#2  0x7f2095610100 in syslog () from /lib64/libc.so.6
#3  0x004c4202 in tcp_read_req (con=0x7f2081a933c0, 
bytes_read=0x7ffc6bc97f0c) at tcp_read.c:597
#4  0x004c5908 in handle_io (fm=, idx=-1, 
event_type=) at tcp_read.c:1033
#5  0x004c8083 in io_wait_loop_epoll (unix_sock=) 
at io_wait.h:845
#6  tcp_receive_loop (unix_sock=) at tcp_read.c:1141
#7  0x004b12e9 in tcp_init_children (chd_rank=, 
startup_done=0x0) at tcp_main.c:2389
#8  0x0043aebf in main_loop (argc=, argv=) at main.c:1011
#9  main (argc=, argv=) at main.c:1612
(gdb) f 3
#3  0x004c4202 in tcp_read_req (con=0x7f2081a933c0, 
bytes_read=0x7ffc6bc97f0c) at tcp_read.c:597
597 tcp_read.c: No such file or directory.
in tcp_read.c
(gdb) p con->con_req
$1 = (struct tcp_req *) 0x7f20931a97e0
(gdb) p _req
$2 = (struct tcp_req *) 0x82d720
(gdb) p req
$3 = (struct tcp_req *) 0x7f20931a97e0
(gdb)

From: Bogdan-Andrei Iancu [mailto:bog...@opensips.org]
Sent: Monday, August 31, 2015 3:45 PM
To: Gupta, Rahul; OpenSIPS users mailling list
Subject: Re: [OpenSIPS-Users] core generated by opensips




--

DISCLAIMER: This e-mail may contain information that is confidential, 
privileged or otherwise protected from disclosure. If you are not an intended 
recipient of this e-mail, do not duplicate or redistribute it by any means. 
Please delete it and any attachments and notify the sender that you have 
received it in error. Unintende

[OpenSIPS-Users] Question regarding TLS

[Gupta, Rahul]

Hi, I am using opensips-1.11.5-tls and trying to figure out which TLS versions 
are supported

>From the documentation I see that either 1.0 or 1.2 are supported. Is it 
>possible to have all the tls version support (1.0, 1.1 and 1.2) within the 
>same instance of opensips ?

*TLSv1_2 - means OpenSIPS will accept only TLSv1.2 connections (rfc3261 
conformant).

*TLSv1 - means OpenSIPS will accept only TLSv1 connections (rfc3261 
conformant).
Thanks
Rahul Gupta

--

DISCLAIMER: This e-mail may contain information that is confidential, 
privileged or otherwise protected from disclosure. If you are not an intended 
recipient of this e-mail, do not duplicate or redistribute it by any means. 
Please delete it and any attachments and notify the sender that you have 
received it in error. Unintended recipients are prohibited from taking action 
on the basis of information in this e-mail.E-mail messages may contain computer 
viruses or other defects, may not be accurately replicated on other systems, or 
may be intercepted, deleted or interfered with without the knowledge of the 
sender or the intended recipient. If you are not comfortable with the risks 
associated with e-mail messages, you may decide not to use e-mail to 
communicate with IPC. IPC reserves the right, to the extent and under 
circumstances permitted by applicable law, to retain, monitor and intercept 
e-mail messages to and from its systems.
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] core generated by opensips

[Gupta, Rahul]

Hi Bogdan, following is the info you requested. This is not the first tcp read, 
this server is been running for a while and taking calls.

(gdb) bt
#0  0x7f2095572e2c in vfprintf () from /lib64/libc.so.6
#1  0x7f209560fed0 in __vsyslog_chk () from /lib64/libc.so.6
#2  0x7f2095610100 in syslog () from /lib64/libc.so.6
#3  0x004c4202 in tcp_read_req (con=0x7f2081a933c0, 
bytes_read=0x7ffc6bc97f0c) at tcp_read.c:597
#4  0x004c5908 in handle_io (fm=, idx=-1, 
event_type=) at tcp_read.c:1033
#5  0x004c8083 in io_wait_loop_epoll (unix_sock=) 
at io_wait.h:845
#6  tcp_receive_loop (unix_sock=) at tcp_read.c:1141
#7  0x004b12e9 in tcp_init_children (chd_rank=, 
startup_done=0x0) at tcp_main.c:2389
#8  0x0043aebf in main_loop (argc=, argv=) at main.c:1011
#9  main (argc=, argv=) at main.c:1612
(gdb) f 3
#3  0x004c4202 in tcp_read_req (con=0x7f2081a933c0, 
bytes_read=0x7ffc6bc97f0c) at tcp_read.c:597
597 tcp_read.c: No such file or directory.
in tcp_read.c
(gdb) p con->con_req
$1 = (struct tcp_req *) 0x7f20931a97e0
(gdb) p _req
$2 = (struct tcp_req *) 0x82d720
(gdb) p req
$3 = (struct tcp_req *) 0x7f20931a97e0
(gdb)

From: Bogdan-Andrei Iancu [mailto:bog...@opensips.org]
Sent: Monday, August 31, 2015 3:45 PM
To: Gupta, Rahul; OpenSIPS users mailling list
Subject: Re: [OpenSIPS-Users] core generated by opensips

Thank you Rahul,

the whole req variable seems to be garbage :(.

Could you additionally print in gdb:
con->con_req
_req
req

Also, does this crash happens on the first TCP read ? or after a while, after 
several read ops ?

Regards,


Bogdan-Andrei Iancu

OpenSIPS Founder and Developer

http://www.opensips-solutions.com
On 31.08.2015 15:26, Gupta, Rahul wrote:
Hi Bogdan, here are the details you requested

(gdb) bt
#0  0x7f2095572e2c in vfprintf () from /lib64/libc.so.6
#1  0x7f209560fed0 in __vsyslog_chk () from /lib64/libc.so.6
#2  0x7f2095610100 in syslog () from /lib64/libc.so.6
#3  0x004c4202 in tcp_read_req (con=0x7f2081a933c0, 
bytes_read=0x7ffc6bc97f0c) at tcp_read.c:597
#4  0x004c5908 in handle_io (fm=, idx=-1, 
event_type=) at tcp_read.c:1033
#5  0x004c8083 in io_wait_loop_epoll (unix_sock=) 
at io_wait.h:845
#6  tcp_receive_loop (unix_sock=) at tcp_read.c:1141
#7  0x004b12e9 in tcp_init_children (chd_rank=, 
startup_done=0x0) at tcp_main.c:2389
#8  0x0043aebf in main_loop (argc=, argv=) at main.c:1011
#9  main (argc=, argv=) at main.c:1612
(gdb) f 3
#3  0x004c4202 in tcp_read_req (con=0x7f2081a933c0, 
bytes_read=0x7ffc6bc97f0c) at tcp_read.c:597
597 tcp_read.c: No such file or directory.
in tcp_read.c
(gdb) p *req
$1 = {next = 0x3,
  buf = "\022Ø\000\000\000\000\000M\000\000\000\000\000\000\000T", '\000' 
, "p\227\032\223 \177\000\000p\227\032\223 
\177\000\000H\000\000\000\000\000\000\000\250\203\032\223 
\177\000\000\300\227\032\223 
\177\000\000\001\000\000\000\000\000\000\000\264×\000\000\000\000\000\003\000\000\000\000\000\000\000\271×\000\000\000\000\000R\000\000\000\000\000\000\000Y",
 '\000' , "Ð\032\223 \177\000\000Ð\032\223 \177\000\000\200", 
'\000' , "P\221\026\223 \177\000\000Via: SIP/2.0/TCP 
10.204.70.154:5070;branch=z9hG4bK+540c4cc39bb7b8e44a"...,
  start = 0x6d782b6c6d736d2f , pos = 
0x462d78614d0a0d6c ,
  parsed = 0x3a7364726177726f , body 
= 0x3c0a0d0a0d303720 , content_len = 
1819113535, has_content_len = 30240,
  complete = 29285, bytes_to_go = 1852795251, error = 774971965, state = 
1696604720}
(gdb)

From: Bogdan-Andrei Iancu [mailto:bog...@opensips.org]
Sent: Monday, August 31, 2015 5:25 AM
To: OpenSIPS users mailling list; Gupta, Rahul
Subject: Re: [OpenSIPS-Users] core generated by opensips

Hi Rahul,

Could you do in gdb:

p *req

to see all the field of the request structure.

Thanks,



Bogdan-Andrei Iancu

OpenSIPS Founder and Developer

http://www.opensips-solutions.com
On 30.08.2015 23:31, Gupta, Rahul wrote:
Hi, I am using opensips-1.11.5-tls and the opensips crashed with the following 
gdb trace. Seems like it crashed while printing error message. Is this 
something already fixed

LM_ERR("bad request, state=%d, error=%d "
  "buf:\n%.*s\nparsed:\n%.*s\n", req->state, 
req->error,
  (int)(req->pos-req->buf), req->buf,
  (int)(req->parsed-req->start), req->start);

(gdb) bt
#0  0x7f2095572e2c in vfprintf () from /lib64/libc.so.6
#1  0x7f209560fed0 in __vsyslog_chk () from /lib64/libc.so.6
#2  0x7f2095610100 in syslog () from /lib64/libc.so.6
#3  0x004c4202 in tcp_read_req (con=0x7f2081a933c0, 
bytes_read=0x7ffc6bc97f0c) at tcp_read.c:597
#4  0x004c5908 in handle_io (fm=, idx=-1, 
event_type=) at tcp_read.c:1033
#5  0x004c8083 in io_wait_loop_epoll (unix_sock=) 
at io_wait.h:845
#6  tc

Re: [OpenSIPS-Users] core generated by opensips

[Gupta, Rahul]

Hi Bogdan, following is the info you requested.

#0  0x7f2095572e2c in vfprintf () from /lib64/libc.so.6
#1  0x7f209560fed0 in __vsyslog_chk () from /lib64/libc.so.6
#2  0x7f2095610100 in syslog () from /lib64/libc.so.6
#3  0x004c4202 in tcp_read_req (con=0x7f2081a933c0, 
bytes_read=0x7ffc6bc97f0c) at tcp_read.c:597
#4  0x004c5908 in handle_io (fm=, idx=-1, 
event_type=) at tcp_read.c:1033
#5  0x004c8083 in io_wait_loop_epoll (unix_sock=) 
at io_wait.h:845
#6  tcp_receive_loop (unix_sock=) at tcp_read.c:1141
#7  0x004b12e9 in tcp_init_children (chd_rank=, 
startup_done=0x0) at tcp_main.c:2389
#8  0x0043aebf in main_loop (argc=, argv=) at main.c:1011
#9  main (argc=, argv=) at main.c:1612
(gdb) f 3
#3  0x004c4202 in tcp_read_req (con=0x7f2081a933c0, 
bytes_read=0x7ffc6bc97f0c) at tcp_read.c:597
597 tcp_read.c: No such file or directory.
in tcp_read.c
(gdb) p con->con_req
$1 = (struct tcp_req *) 0x7f20931a97e0
(gdb) p _req
$2 = (struct tcp_req *) 0x82d720
(gdb) p req
$3 = (struct tcp_req *) 0x7f20931a97e0
(gdb) p *con
$4 = {s = 30, fd = 21, write_lock = 0, id = 19, rcv = {src_ip = {af = 2, len = 
4, u = {addrl = {2621885450, 0}, addr32 = {2621885450, 0, 0, 0}, addr16 = 
{52234, 40006, 0, 0, 0, 0, 0, 0},
addr = "\n\314F\234", '\000' }}, dst_ip = {af = 2, 
len = 4, u = {addrl = {2588331018, 0}, addr32 = {2588331018, 0, 0, 0}, addr16 = 
{52234, 39494, 0, 0, 0, 0, 0, 0},
addr = "\n\314F\232", '\000' }}, src_port = 5060, 
dst_port = 5070, proto = 2, proto_reserved1 = 19, proto_reserved2 = 0, src_su = 
{s = {sa_family = 2,
sa_data = "\023\304\n\314F\234\000\000\000\000\000\000\000"}, sin = 
{sin_family = 2, sin_port = 50195, sin_addr = {s_addr = 2621885450}, sin_zero = 
"\000\000\000\000\000\000\000"}},
bind_address = 0x7f2093171398}, refcnt = 2, type = PROTO_TCP, flags = 2, 
state = S_CONN_CONNECT, extra_data = 0x0, timeout = 50039, lifetime = 0, 
id_hash = 19, id_next = 0x0, id_prev = 0x0, c_next = 0x0,
  c_prev = 0x0, con_aliases = {{parent = 0x7f2081a933c0, next = 0x0, prev = 
0x0, port = 5060, hash = 974}, {parent = 0x0, next = 0x0, prev = 0x0, port = 0, 
hash = 0}, {parent = 0x0, next = 0x0, prev = 0x0,
  port = 0, hash = 0}, {parent = 0x0, next = 0x0, prev = 0x0, port = 0, 
hash = 0}}, aliases = 1, con_req = 0x7f20931a97e0, msg_attempts = 1, 
async_chunks = 0x7f2081a93530, async_chunks_no = 0,
  oldest_chunk = 0}
(gdb)

From: Bogdan-Andrei Iancu [mailto:bog...@opensips.org]
Sent: Monday, August 31, 2015 4:39 PM
To: Gupta, Rahul; OpenSIPS users mailling list
Subject: Re: [OpenSIPS-Users] core generated by opensips

And printing :
*con

Thanks,


Bogdan-Andrei Iancu

OpenSIPS Founder and Developer

http://www.opensips-solutions.com
On 31.08.2015 22:50, Gupta, Rahul wrote:
Hi Bogdan, following is the info you requested. This is not the first tcp read, 
this server is been running for a while and taking calls.

(gdb) bt
#0  0x7f2095572e2c in vfprintf () from /lib64/libc.so.6
#1  0x7f209560fed0 in __vsyslog_chk () from /lib64/libc.so.6
#2  0x7f2095610100 in syslog () from /lib64/libc.so.6
#3  0x004c4202 in tcp_read_req (con=0x7f2081a933c0, 
bytes_read=0x7ffc6bc97f0c) at tcp_read.c:597
#4  0x004c5908 in handle_io (fm=, idx=-1, 
event_type=) at tcp_read.c:1033
#5  0x004c8083 in io_wait_loop_epoll (unix_sock=) 
at io_wait.h:845
#6  tcp_receive_loop (unix_sock=) at tcp_read.c:1141
#7  0x004b12e9 in tcp_init_children (chd_rank=, 
startup_done=0x0) at tcp_main.c:2389
#8  0x0043aebf in main_loop (argc=, argv=) at main.c:1011
#9  main (argc=, argv=) at main.c:1612
(gdb) f 3
#3  0x004c4202 in tcp_read_req (con=0x7f2081a933c0, 
bytes_read=0x7ffc6bc97f0c) at tcp_read.c:597
597 tcp_read.c: No such file or directory.
in tcp_read.c
(gdb) p con->con_req
$1 = (struct tcp_req *) 0x7f20931a97e0
(gdb) p _req
$2 = (struct tcp_req *) 0x82d720
(gdb) p req
$3 = (struct tcp_req *) 0x7f20931a97e0
(gdb)

From: Bogdan-Andrei Iancu [mailto:bog...@opensips.org]
Sent: Monday, August 31, 2015 3:45 PM
To: Gupta, Rahul; OpenSIPS users mailling list
Subject: Re: [OpenSIPS-Users] core generated by opensips




--

DISCLAIMER: This e-mail may contain information that is confidential, 
privileged or otherwise protected from disclosure. If you are not an intended 
recipient of this e-mail, do not duplicate or redistribute it by any means. 
Please delete it and any attachments and notify the sender that you have 
received it in error. Unintended recipients are prohibited from taking action 
on the basis of information in this e-mail.E-mail messages may contain computer 
viruses or other defects, may not be accurately replicated on other systems,

Re: [OpenSIPS-Users] core generated by opensips

[Gupta, Rahul]

Hi Bogdan, here are the details you requested

(gdb) bt
#0  0x7f2095572e2c in vfprintf () from /lib64/libc.so.6
#1  0x7f209560fed0 in __vsyslog_chk () from /lib64/libc.so.6
#2  0x7f2095610100 in syslog () from /lib64/libc.so.6
#3  0x004c4202 in tcp_read_req (con=0x7f2081a933c0, 
bytes_read=0x7ffc6bc97f0c) at tcp_read.c:597
#4  0x004c5908 in handle_io (fm=, idx=-1, 
event_type=) at tcp_read.c:1033
#5  0x004c8083 in io_wait_loop_epoll (unix_sock=) 
at io_wait.h:845
#6  tcp_receive_loop (unix_sock=) at tcp_read.c:1141
#7  0x004b12e9 in tcp_init_children (chd_rank=, 
startup_done=0x0) at tcp_main.c:2389
#8  0x0043aebf in main_loop (argc=, argv=) at main.c:1011
#9  main (argc=, argv=) at main.c:1612
(gdb) f 3
#3  0x004c4202 in tcp_read_req (con=0x7f2081a933c0, 
bytes_read=0x7ffc6bc97f0c) at tcp_read.c:597
597 tcp_read.c: No such file or directory.
in tcp_read.c
(gdb) p *req
$1 = {next = 0x3,
  buf = "\022Ø\000\000\000\000\000M\000\000\000\000\000\000\000T", '\000' 
, "p\227\032\223 \177\000\000p\227\032\223 
\177\000\000H\000\000\000\000\000\000\000\250\203\032\223 
\177\000\000\300\227\032\223 
\177\000\000\001\000\000\000\000\000\000\000\264×\000\000\000\000\000\003\000\000\000\000\000\000\000\271×\000\000\000\000\000R\000\000\000\000\000\000\000Y",
 '\000' , "Ð\032\223 \177\000\000Ð\032\223 \177\000\000\200", 
'\000' , "P\221\026\223 \177\000\000Via: SIP/2.0/TCP 
10.204.70.154:5070;branch=z9hG4bK+540c4cc39bb7b8e44a"...,
  start = 0x6d782b6c6d736d2f , pos = 
0x462d78614d0a0d6c ,
  parsed = 0x3a7364726177726f , body 
= 0x3c0a0d0a0d303720 , content_len = 
1819113535, has_content_len = 30240,
  complete = 29285, bytes_to_go = 1852795251, error = 774971965, state = 
1696604720}
(gdb)

From: Bogdan-Andrei Iancu [mailto:bog...@opensips.org]
Sent: Monday, August 31, 2015 5:25 AM
To: OpenSIPS users mailling list; Gupta, Rahul
Subject: Re: [OpenSIPS-Users] core generated by opensips

Hi Rahul,

Could you do in gdb:

p *req

to see all the field of the request structure.

Thanks,


Bogdan-Andrei Iancu

OpenSIPS Founder and Developer

http://www.opensips-solutions.com
On 30.08.2015 23:31, Gupta, Rahul wrote:
Hi, I am using opensips-1.11.5-tls and the opensips crashed with the following 
gdb trace. Seems like it crashed while printing error message. Is this 
something already fixed

LM_ERR("bad request, state=%d, error=%d "
  "buf:\n%.*s\nparsed:\n%.*s\n", req->state, 
req->error,
  (int)(req->pos-req->buf), req->buf,
  (int)(req->parsed-req->start), req->start);

(gdb) bt
#0  0x7f2095572e2c in vfprintf () from /lib64/libc.so.6
#1  0x7f209560fed0 in __vsyslog_chk () from /lib64/libc.so.6
#2  0x7f2095610100 in syslog () from /lib64/libc.so.6
#3  0x004c4202 in tcp_read_req (con=0x7f2081a933c0, 
bytes_read=0x7ffc6bc97f0c) at tcp_read.c:597
#4  0x004c5908 in handle_io (fm=, idx=-1, 
event_type=) at tcp_read.c:1033
#5  0x004c8083 in io_wait_loop_epoll (unix_sock=) 
at io_wait.h:845
#6  tcp_receive_loop (unix_sock=) at tcp_read.c:1141
#7  0x004b12e9 in tcp_init_children (chd_rank=, 
startup_done=0x0) at tcp_main.c:2389
#8  0x0043aebf in main_loop (argc=, argv=) at main.c:1011
#9  main (argc=, argv=) at main.c:1612
(gdb) f 3
#3  0x004c4202 in tcp_read_req (con=0x7f2081a933c0, 
bytes_read=0x7ffc6bc97f0c) at tcp_read.c:597
597 tcp_read.c: No such file or directory.
in tcp_read.c
(gdb) info 3
Undefined info command: "3".  Try "help info".
(gdb) print buf
$1 = 0
(gdb) print req
$2 = (struct tcp_req *) 0x7f20931a97e0
(gdb) print req->state
$3 = 1696604720
(gdb) print req->error
$4 = 774971965
(gdb) print req->buf
$5 = "\022Ø\000\000\000\000\000M\000\000\000\000\000\000\000T", '\000' , "p\227\032\223 \177\000\000p\227\032\223 
\177\000\000H\000\000\000\000\000\000\000\250\203\032\223 
\177\000\000\300\227\032\223 
\177\000\000\001\000\000\000\000\000\000\000\264×\000\000\000\000\000\003\000\000\000\000\000\000\000\271×\000\000\000\000\000R\000\000\000\000\000\000\000Y",
 '\000' , "Ð\032\223 \177\000\000Ð\032\223 \177\000\000\200", 
'\000' , "P\221\026\223 \177\000\000Via: SIP/2.0/TCP 
10.204.70.154:5070;branch=z9hG4bK+540c4cc39bb7b8e44a"...
(gdb) print req->start
$6 = 0x6d782b6c6d736d2f 
(gdb) print req->parsed-req->start
$7 = -3676281973086354112
(gdb) print req->pos-req->buf
$8 = 5056690538022925700
(gdb) print (int)(req->pos-req->buf)
$9 = -1175489148
(gdb) print (int)(req->pos-req->buf)
$10 = -1175489148
(gdb) print (int)(req->parsed-req->start)
$11 = -201063104
(gdb)

--

[OpenSIPS-Users] core generated by opensips

[Gupta, Rahul]

Hi, I am using opensips-1.11.5-tls and the opensips crashed with the following 
gdb trace. Seems like it crashed while printing error message. Is this 
something already fixed

LM_ERR(bad request, state=%d, error=%d 
  buf:\n%.*s\nparsed:\n%.*s\n, req-state, 
req-error,
  (int)(req-pos-req-buf), req-buf,
  (int)(req-parsed-req-start), req-start);

(gdb) bt
#0  0x7f2095572e2c in vfprintf () from /lib64/libc.so.6
#1  0x7f209560fed0 in __vsyslog_chk () from /lib64/libc.so.6
#2  0x7f2095610100 in syslog () from /lib64/libc.so.6
#3  0x004c4202 in tcp_read_req (con=0x7f2081a933c0, 
bytes_read=0x7ffc6bc97f0c) at tcp_read.c:597
#4  0x004c5908 in handle_io (fm=value optimized out, idx=-1, 
event_type=value optimized out) at tcp_read.c:1033
#5  0x004c8083 in io_wait_loop_epoll (unix_sock=value optimized out) 
at io_wait.h:845
#6  tcp_receive_loop (unix_sock=value optimized out) at tcp_read.c:1141
#7  0x004b12e9 in tcp_init_children (chd_rank=value optimized out, 
startup_done=0x0) at tcp_main.c:2389
#8  0x0043aebf in main_loop (argc=value optimized out, argv=value 
optimized out) at main.c:1011
#9  main (argc=value optimized out, argv=value optimized out) at main.c:1612
(gdb) f 3
#3  0x004c4202 in tcp_read_req (con=0x7f2081a933c0, 
bytes_read=0x7ffc6bc97f0c) at tcp_read.c:597
597 tcp_read.c: No such file or directory.
in tcp_read.c
(gdb) info 3
Undefined info command: 3.  Try help info.
(gdb) print buf
$1 = 0
(gdb) print req
$2 = (struct tcp_req *) 0x7f20931a97e0
(gdb) print req-state
$3 = 1696604720
(gdb) print req-error
$4 = 774971965
(gdb) print req-buf
$5 = \022Ø\000\000\000\000\000M\000\000\000\000\000\000\000T, '\000' repeats 
15 times, p\227\032\223 \177\000\000p\227\032\223 
\177\000\000H\000\000\000\000\000\000\000\250\203\032\223 
\177\000\000\300\227\032\223 
\177\000\000\001\000\000\000\000\000\000\000\264×\000\000\000\000\000\003\000\000\000\000\000\000\000\271×\000\000\000\000\000R\000\000\000\000\000\000\000Y,
 '\000' repeats 15 times, Ð\032\223 \177\000\000Ð\032\223 \177\000\000\200, 
'\000' repeats 15 times, P\221\026\223 \177\000\000Via: SIP/2.0/TCP 
10.204.70.154:5070;branch=z9hG4bK+540c4cc39bb7b8e44a...
(gdb) print req-start
$6 = 0x6d782b6c6d736d2f Address 0x6d782b6c6d736d2f out of bounds
(gdb) print req-parsed-req-start
$7 = -3676281973086354112
(gdb) print req-pos-req-buf
$8 = 5056690538022925700
(gdb) print (int)(req-pos-req-buf)
$9 = -1175489148
(gdb) print (int)(req-pos-req-buf)
$10 = -1175489148
(gdb) print (int)(req-parsed-req-start)
$11 = -201063104
(gdb)

--

DISCLAIMER: This e-mail may contain information that is confidential, 
privileged or otherwise protected from disclosure. If you are not an intended 
recipient of this e-mail, do not duplicate or redistribute it by any means. 
Please delete it and any attachments and notify the sender that you have 
received it in error. Unintended recipients are prohibited from taking action 
on the basis of information in this e-mail.E-mail messages may contain computer 
viruses or other defects, may not be accurately replicated on other systems, or 
may be intercepted, deleted or interfered with without the knowledge of the 
sender or the intended recipient. If you are not comfortable with the risks 
associated with e-mail messages, you may decide not to use e-mail to 
communicate with IPC. IPC reserves the right, to the extent and under 
circumstances permitted by applicable law, to retain, monitor and intercept 
e-mail messages to and from its systems.
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] ERROR:core:io_watch_del: BUG - trying to del fd 38 with flags 2 1

[Gupta, Rahul]

Hi Bogdan, I have created an issue with opensips github

https://github.com/OpenSIPS/opensips/issues/591

And uploaded the logs specified in the link with the description along with 
timestamps.

Thanks
Rahul Gupta

From: Bogdan-Andrei Iancu [mailto:bog...@opensips.org]
Sent: Tuesday, August 04, 2015 10:51 AM
To: Gupta, Rahul; users@lists.opensips.org
Subject: Re: ERROR:core:io_watch_del: BUG - trying to del fd 38 with flags 2 1

Hi Rahul,

Any logs will be  useful (use some pastebin or file transfer to upload).

On your observations : when a connection timeout does expire (via 
__tcpconn_lifetime()), reactor_del_all() removes the fd with both IO_WATCH_READ 
and IO_WATCH_WRITE flags. While in the logs it shows 1, removing with READ 
only.

Going back


Bogdan-Andrei Iancu

OpenSIPS Founder and Developer

http://www.opensips-solutions.com
On 04.08.2015 16:29, Gupta, Rahul wrote:
Hi Bogdan,

I tried the scenario with 1.11.3 as well as 1.11.5 latest code and could 
reproduce it consistently. I can turn on the higher debug level logging and 
provide you the log file. Let me know where can I upload these logs ?

Thanks
Rahul

From: Bogdan-Andrei Iancu [mailto:bog...@opensips.org]
Sent: Tuesday, August 04, 2015 8:18 AM
To: Gupta, Rahul; users@lists.opensips.orgmailto:users@lists.opensips.org
Subject: Re: ERROR:core:io_watch_del: BUG - trying to del fd 38 with flags 2 1

Hi Rahul,

I tried to reproduce your scenario during the last 2 days. Thanks to the 
detailed instructions and stepping, I mananged to get (as described) to the 
last step. But instead of getting the error you mentioned, the tcp conn timeout 
event was properly handled:

[23203] DBG:core:__tcpconn_lifetime: timeout for hash=3 - 0x7f94f298fea0 (322  
317)
[23203] DBG:core:io_watch_del: [TCP_main] io_watch_del op on index -1 29 
(0x8828a0, 29, -1, 0x10,0x3) fd_no=22 called

Are you sure you are using the latest GIT code (I tested both 2.1 and 1.11).

Regards,




Bogdan-Andrei Iancu

OpenSIPS Founder and Developer

http://www.opensips-solutions.com
On 31.07.2015 17:40, Gupta, Rahul wrote:
Hi Bogdan, thanks for looking into this issue. Let me know if anyway I can help 
to get to the bottom of this issue, like providing logs etc

Thanks
Rahul

From: Bogdan-Andrei Iancu [mailto:bog...@opensips.org]
Sent: Tuesday, July 28, 2015 1:13 PM
To: Gupta, Rahul; users@lists.opensips.orgmailto:users@lists.opensips.org
Subject: Re: ERROR:core:io_watch_del: BUG - trying to del fd 38 with flags 2 1

Hi Rahul,

These are great news - that you find a way to reproduce it. Let me do it and 
start debugging.

I really do appreciate your effort in dealing with this error.

Regards,




Bogdan-Andrei Iancu

OpenSIPS Founder and Developer

http://www.opensips-solutions.com
On 24.07.2015 00:19, Gupta, Rahul wrote:
Hi Bogdan,

Almost a month ago, I have raised the issue regarding the opensips log file 
filling up with the following message

ERROR:core:io_watch_del: BUG - trying to del fd 38 with flags 2 1

Now I can reproduce it every time with the following scenario:


1)  UAC and UAS are connected to opensips proxy with TCP transport

2)  Connections looks good

3)  Netstat shows the connection to UAC in ESTABLISHED state and the 
tcp_conn_lists of opensips also looks fine for that UAC

4)  Now unplug the Ethernet cable on UAC

5)  After tcp connection timeout (set to 5 mins in opensips.cfg), the tcp 
connection goes away from netstat as well as from tcp_conn_lists

6)  UAS tries another tcp call to the UAC which is still unplugged

7)  tcp_conn_lists shows the tcp connection to the UAC and netstat shows 
the connection in SYN_SENT state

8)  After the tcp connection timeout (set to 5 mins in opensips.cfg), the 
connection goes away from netstat however it remains there in tcp_conn_lists 
and at that moment the BUG - trying to del fd 38 with flags 2 1 starts 
printing in infinite loop.


I looked at the source code and observed the following


1)  When the network cable is plugged in

The io_watch_add happens with flag IO_WATCH_READ in tcp_main.c  when the 
command is CONN_NEW

2)  When the network cable is unplugged

The io_watch_add happens with flag IO_WATCH_WRITE in tcp_main.c  when the 
command is ASYNC_CONNECT


3)  While doing io_watch_del after timeout, from handle_tcpconn_ev method, 
io_watch_del always uses IO_WATCH_READ to delete the fd, which gives this error 
in case of unplugged cable.

Please look into this and suggest how can I fix this issue ?

Thanks
Rahul Gupta






--

DISCLAIMER: This e-mail may contain information that is confidential, 
privileged or otherwise protected from disclosure. If you are not an intended 
recipient of this e-mail, do not duplicate or redistribute it by any means. 
Please delete it and any attachments

Re: [OpenSIPS-Users] ERROR:core:io_watch_del: BUG - trying to del fd 38 with flags 2 1

[Gupta, Rahul]

Hi Bogdan,

I tried the scenario with 1.11.3 as well as 1.11.5 latest code and could 
reproduce it consistently. I can turn on the higher debug level logging and 
provide you the log file. Let me know where can I upload these logs ?

Thanks
Rahul

From: Bogdan-Andrei Iancu [mailto:bog...@opensips.org]
Sent: Tuesday, August 04, 2015 8:18 AM
To: Gupta, Rahul; users@lists.opensips.org
Subject: Re: ERROR:core:io_watch_del: BUG - trying to del fd 38 with flags 2 1

Hi Rahul,

I tried to reproduce your scenario during the last 2 days. Thanks to the 
detailed instructions and stepping, I mananged to get (as described) to the 
last step. But instead of getting the error you mentioned, the tcp conn timeout 
event was properly handled:

[23203] DBG:core:__tcpconn_lifetime: timeout for hash=3 - 0x7f94f298fea0 (322  
317)
[23203] DBG:core:io_watch_del: [TCP_main] io_watch_del op on index -1 29 
(0x8828a0, 29, -1, 0x10,0x3) fd_no=22 called

Are you sure you are using the latest GIT code (I tested both 2.1 and 1.11).

Regards,



Bogdan-Andrei Iancu

OpenSIPS Founder and Developer

http://www.opensips-solutions.com
On 31.07.2015 17:40, Gupta, Rahul wrote:
Hi Bogdan, thanks for looking into this issue. Let me know if anyway I can help 
to get to the bottom of this issue, like providing logs etc

Thanks
Rahul

From: Bogdan-Andrei Iancu [mailto:bog...@opensips.org]
Sent: Tuesday, July 28, 2015 1:13 PM
To: Gupta, Rahul; users@lists.opensips.orgmailto:users@lists.opensips.org
Subject: Re: ERROR:core:io_watch_del: BUG - trying to del fd 38 with flags 2 1

Hi Rahul,

These are great news - that you find a way to reproduce it. Let me do it and 
start debugging.

I really do appreciate your effort in dealing with this error.

Regards,



Bogdan-Andrei Iancu

OpenSIPS Founder and Developer

http://www.opensips-solutions.com
On 24.07.2015 00:19, Gupta, Rahul wrote:
Hi Bogdan,

Almost a month ago, I have raised the issue regarding the opensips log file 
filling up with the following message

ERROR:core:io_watch_del: BUG - trying to del fd 38 with flags 2 1

Now I can reproduce it every time with the following scenario:


1)  UAC and UAS are connected to opensips proxy with TCP transport

2)  Connections looks good

3)  Netstat shows the connection to UAC in ESTABLISHED state and the 
tcp_conn_lists of opensips also looks fine for that UAC

4)  Now unplug the Ethernet cable on UAC

5)  After tcp connection timeout (set to 5 mins in opensips.cfg), the tcp 
connection goes away from netstat as well as from tcp_conn_lists

6)  UAS tries another tcp call to the UAC which is still unplugged

7)  tcp_conn_lists shows the tcp connection to the UAC and netstat shows 
the connection in SYN_SENT state

8)  After the tcp connection timeout (set to 5 mins in opensips.cfg), the 
connection goes away from netstat however it remains there in tcp_conn_lists 
and at that moment the BUG - trying to del fd 38 with flags 2 1 starts 
printing in infinite loop.


I looked at the source code and observed the following


1)  When the network cable is plugged in

The io_watch_add happens with flag IO_WATCH_READ in tcp_main.c  when the 
command is CONN_NEW

2)  When the network cable is unplugged

The io_watch_add happens with flag IO_WATCH_WRITE in tcp_main.c  when the 
command is ASYNC_CONNECT


3)  While doing io_watch_del after timeout, from handle_tcpconn_ev method, 
io_watch_del always uses IO_WATCH_READ to delete the fd, which gives this error 
in case of unplugged cable.

Please look into this and suggest how can I fix this issue ?

Thanks
Rahul Gupta






--

DISCLAIMER: This e-mail may contain information that is confidential, 
privileged or otherwise protected from disclosure. If you are not an intended 
recipient of this e-mail, do not duplicate or redistribute it by any means. 
Please delete it and any attachments and notify the sender that you have 
received it in error. Unintended recipients are prohibited from taking action 
on the basis of information in this e-mail.E-mail messages may contain computer 
viruses or other defects, may not be accurately replicated on other systems, or 
may be intercepted, deleted or interfered with without the knowledge of the 
sender or the intended recipient. If you are not comfortable with the risks 
associated with e-mail messages, you may decide not to use e-mail to 
communicate with IPC. IPC reserves the right, to the extent and under 
circumstances permitted by applicable law, to retain, monitor and intercept 
e-mail messages to and from its systems.


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] ERROR:core:io_watch_del: BUG - trying to del fd 38 with flags 2 1

[Gupta, Rahul]

Hi Bogdan, thanks for looking into this issue. Let me know if anyway I can help 
to get to the bottom of this issue, like providing logs etc

Thanks
Rahul

From: Bogdan-Andrei Iancu [mailto:bog...@opensips.org]
Sent: Tuesday, July 28, 2015 1:13 PM
To: Gupta, Rahul; users@lists.opensips.org
Subject: Re: ERROR:core:io_watch_del: BUG - trying to del fd 38 with flags 2 1

Hi Rahul,

These are great news - that you find a way to reproduce it. Let me do it and 
start debugging.

I really do appreciate your effort in dealing with this error.

Regards,


Bogdan-Andrei Iancu

OpenSIPS Founder and Developer

http://www.opensips-solutions.com
On 24.07.2015 00:19, Gupta, Rahul wrote:
Hi Bogdan,

Almost a month ago, I have raised the issue regarding the opensips log file 
filling up with the following message

ERROR:core:io_watch_del: BUG - trying to del fd 38 with flags 2 1

Now I can reproduce it every time with the following scenario:


1)  UAC and UAS are connected to opensips proxy with TCP transport

2)  Connections looks good

3)  Netstat shows the connection to UAC in ESTABLISHED state and the 
tcp_conn_lists of opensips also looks fine for that UAC

4)  Now unplug the Ethernet cable on UAC

5)  After tcp connection timeout (set to 5 mins in opensips.cfg), the tcp 
connection goes away from netstat as well as from tcp_conn_lists

6)  UAS tries another tcp call to the UAC which is still unplugged

7)  tcp_conn_lists shows the tcp connection to the UAC and netstat shows 
the connection in SYN_SENT state

8)  After the tcp connection timeout (set to 5 mins in opensips.cfg), the 
connection goes away from netstat however it remains there in tcp_conn_lists 
and at that moment the BUG - trying to del fd 38 with flags 2 1 starts 
printing in infinite loop.


I looked at the source code and observed the following


1)  When the network cable is plugged in

The io_watch_add happens with flag IO_WATCH_READ in tcp_main.c  when the 
command is CONN_NEW

2)  When the network cable is unplugged

The io_watch_add happens with flag IO_WATCH_WRITE in tcp_main.c  when the 
command is ASYNC_CONNECT


3)  While doing io_watch_del after timeout, from handle_tcpconn_ev method, 
io_watch_del always uses IO_WATCH_READ to delete the fd, which gives this error 
in case of unplugged cable.

Please look into this and suggest how can I fix this issue ?

Thanks
Rahul Gupta






--

DISCLAIMER: This e-mail may contain information that is confidential, 
privileged or otherwise protected from disclosure. If you are not an intended 
recipient of this e-mail, do not duplicate or redistribute it by any means. 
Please delete it and any attachments and notify the sender that you have 
received it in error. Unintended recipients are prohibited from taking action 
on the basis of information in this e-mail.E-mail messages may contain computer 
viruses or other defects, may not be accurately replicated on other systems, or 
may be intercepted, deleted or interfered with without the knowledge of the 
sender or the intended recipient. If you are not comfortable with the risks 
associated with e-mail messages, you may decide not to use e-mail to 
communicate with IPC. IPC reserves the right, to the extent and under 
circumstances permitted by applicable law, to retain, monitor and intercept 
e-mail messages to and from its systems.

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] ERROR:core:io_watch_del: BUG - trying to del fd 38 with flags 2 1

[Gupta, Rahul]

Hi Bogdan,

Almost a month ago, I have raised the issue regarding the opensips log file 
filling up with the following message

ERROR:core:io_watch_del: BUG - trying to del fd 38 with flags 2 1

Now I can reproduce it every time with the following scenario:


1)  UAC and UAS are connected to opensips proxy with TCP transport

2)  Connections looks good

3)  Netstat shows the connection to UAC in ESTABLISHED state and the 
tcp_conn_lists of opensips also looks fine for that UAC

4)  Now unplug the Ethernet cable on UAC

5)  After tcp connection timeout (set to 5 mins in opensips.cfg), the tcp 
connection goes away from netstat as well as from tcp_conn_lists

6)  UAS tries another tcp call to the UAC which is still unplugged

7)  tcp_conn_lists shows the tcp connection to the UAC and netstat shows 
the connection in SYN_SENT state

8)  After the tcp connection timeout (set to 5 mins in opensips.cfg), the 
connection goes away from netstat however it remains there in tcp_conn_lists 
and at that moment the BUG - trying to del fd 38 with flags 2 1 starts 
printing in infinite loop.


I looked at the source code and observed the following


1)  When the network cable is plugged in

The io_watch_add happens with flag IO_WATCH_READ in tcp_main.c  when the 
command is CONN_NEW

2)  When the network cable is unplugged

The io_watch_add happens with flag IO_WATCH_WRITE in tcp_main.c  when the 
command is ASYNC_CONNECT


3)  While doing io_watch_del after timeout, from handle_tcpconn_ev method, 
io_watch_del always uses IO_WATCH_READ to delete the fd, which gives this error 
in case of unplugged cable.

Please look into this and suggest how can I fix this issue ?

Thanks
Rahul Gupta






--

DISCLAIMER: This e-mail may contain information that is confidential, 
privileged or otherwise protected from disclosure. If you are not an intended 
recipient of this e-mail, do not duplicate or redistribute it by any means. 
Please delete it and any attachments and notify the sender that you have 
received it in error. Unintended recipients are prohibited from taking action 
on the basis of information in this e-mail.E-mail messages may contain computer 
viruses or other defects, may not be accurately replicated on other systems, or 
may be intercepted, deleted or interfered with without the knowledge of the 
sender or the intended recipient. If you are not comfortable with the risks 
associated with e-mail messages, you may decide not to use e-mail to 
communicate with IPC. IPC reserves the right, to the extent and under 
circumstances permitted by applicable law, to retain, monitor and intercept 
e-mail messages to and from its systems.
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] opensips taking 100% cpu

[Gupta, Rahul]

Hi Bogdan,

I only looked at 3 PIDs and all three showed the same bt.

Thanks
Rahul


--

DISCLAIMER: This e-mail may contain information that is confidential, 
privileged or otherwise protected from disclosure. If you are not an intended 
recipient of this e-mail, do not duplicate or redistribute it by any means. 
Please delete it and any attachments and notify the sender that you have 
received it in error. Unintended recipients are prohibited from taking action 
on the basis of information in this e-mail.E-mail messages may contain computer 
viruses or other defects, may not be accurately replicated on other systems, or 
may be intercepted, deleted or interfered with without the knowledge of the 
sender or the intended recipient. If you are not comfortable with the risks 
associated with e-mail messages, you may decide not to use e-mail to 
communicate with IPC. IPC reserves the right, to the extent and under 
circumstances permitted by applicable law, to retain, monitor and intercept 
e-mail messages to and from its systems.
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] opensips taking 100% cpu

[Gupta, Rahul]

Hi Bogdan,

Performance testing is really getting hit because of this issue. I will 
appreciate any feedback on this issue.

Thanks
Rahul

From: Gupta, Rahul
Sent: Friday, July 17, 2015 2:36 PM
To: users@lists.opensips.org
Subject: opensips taking 100% cpu

Hi,

I am using 1.11.3-tls version and opensips processes are taking 100% CPU.
PID  USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
12635 root  20   0  335m 1876 1068 R 100.0  0.0 335:02.96 opensips
12636 root  20   0  335m 1944 1140 R 100.0  0.0 335:03.71 opensips
12641 root  20   0  335m  88m  87m R 100.0  0.1 333:26.96 opensips
12645 root  20   0  335m  63m  62m R 100.0  0.1 333:23.76 opensips
12632 root  20   0  335m 1196  408 R 99.8  0.0  38:22.68 opensips
12647 root  20   0  335m  19m  18m R 99.8  0.0 561:16.07 opensips
12634 root  20   0  335m 1876 1068 R 99.5  0.0 333:22.10 opensips


None of the commands from opensipsctl are working, so I can't use opensipsctl 
trap to generate gbd info. I ran the gdb on couple of the PID and got the 
following back trace. Seems like opensips is stuck in some lock.

[root@sa-z2-ccm1 ~]# gdb /usr/sbin/opensips 12633
GNU gdb (GDB) Red Hat Enterprise Linux (7.2-60.el6_4.1)
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are 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 was configured as x86_64-redhat-linux-gnu.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from /usr/sbin/opensips...done.
Attaching to program: /usr/sbin/opensips, process 12633
Reading symbols from /lib64/snoopy.so...done.
Loaded symbols for /lib64/snoopy.so
Reading symbols from /lib64/libdl.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib64/libdl.so.2
Reading symbols from /lib64/libresolv.so.2...(no debugging symbols 
found)...done.
Loaded symbols for /lib64/libresolv.so.2
Reading symbols from /usr/lib64/libssl.so.10...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib64/libssl.so.10
Reading symbols from /usr/lib64/libcrypto.so.10...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib64/libcrypto.so.10
Reading symbols from /lib64/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib64/libc.so.6
Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols 
found)...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
Reading symbols from /lib64/libgssapi_krb5.so.2...(no debugging symbols 
found)...done.
Loaded symbols for /lib64/libgssapi_krb5.so.2
Reading symbols from /lib64/libkrb5.so.3...(no debugging symbols found)...done.
Loaded symbols for /lib64/libkrb5.so.3
Reading symbols from /lib64/libcom_err.so.2...(no debugging symbols 
found)...done.
Loaded symbols for /lib64/libcom_err.so.2
Reading symbols from /lib64/libk5crypto.so.3...(no debugging symbols 
found)...done.
Loaded symbols for /lib64/libk5crypto.so.3
Reading symbols from /lib64/libz.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib64/libz.so.1
Reading symbols from /lib64/libkrb5support.so.0...(no debugging symbols 
found)...done.
Loaded symbols for /lib64/libkrb5support.so.0
Reading symbols from /lib64/libkeyutils.so.1...(no debugging symbols 
found)...done.
Loaded symbols for /lib64/libkeyutils.so.1
Reading symbols from /lib64/libpthread.so.0...(no debugging symbols 
found)...done.
[Thread debugging using libthread_db enabled]
Loaded symbols for /lib64/libpthread.so.0
Reading symbols from /lib64/libselinux.so.1...(no debugging symbols 
found)...done.
Loaded symbols for /lib64/libselinux.so.1
Reading symbols from /usr/lib64/opensips/modules/signaling.so...done.
Loaded symbols for /usr/lib64/opensips/modules/signaling.so
Reading symbols from /usr/lib64/opensips/modules/sl.so...done.
Loaded symbols for /usr/lib64/opensips/modules/sl.so
Reading symbols from /usr/lib64/opensips/modules/tm.so...done.
Loaded symbols for /usr/lib64/opensips/modules/tm.so
Reading symbols from /usr/lib64/opensips/modules/rr.so...done.
Loaded symbols for /usr/lib64/opensips/modules/rr.so
Reading symbols from /usr/lib64/opensips/modules/maxfwd.so...done.
Loaded symbols for /usr/lib64/opensips/modules/maxfwd.so
Reading symbols from /usr/lib64/opensips/modules/sipmsgops.so...done.
Loaded symbols for /usr/lib64/opensips/modules/sipmsgops.so
Reading symbols from /usr/lib64/opensips/modules/mi_fifo.so...done.
Loaded symbols for /usr/lib64/opensips/modules/mi_fifo.so
Reading symbols from /usr/lib64/opensips/modules/uri.so...done.
Loaded symbols for /usr/lib64/opensips/modules/uri.so
Reading symbols from /usr/lib64/opensips/modules/usrloc.so...done.
Loaded symbols for /usr/lib64/opensips/modules/usrloc.so
Reading symbols from /usr/lib64/opensips/modules/registrar.so...done.
Loaded symbols for /usr/lib64/opensips/modules

[OpenSIPS-Users] opensips taking 100% cpu

[Gupta, Rahul]

Hi,

I am using 1.11.3-tls version and opensips processes are taking 100% CPU.
PID  USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
12635 root  20   0  335m 1876 1068 R 100.0  0.0 335:02.96 opensips
12636 root  20   0  335m 1944 1140 R 100.0  0.0 335:03.71 opensips
12641 root  20   0  335m  88m  87m R 100.0  0.1 333:26.96 opensips
12645 root  20   0  335m  63m  62m R 100.0  0.1 333:23.76 opensips
12632 root  20   0  335m 1196  408 R 99.8  0.0  38:22.68 opensips
12647 root  20   0  335m  19m  18m R 99.8  0.0 561:16.07 opensips
12634 root  20   0  335m 1876 1068 R 99.5  0.0 333:22.10 opensips


None of the commands from opensipsctl are working, so I can't use opensipsctl 
trap to generate gbd info. I ran the gdb on couple of the PID and got the 
following back trace. Seems like opensips is stuck in some lock.

[root@sa-z2-ccm1 ~]# gdb /usr/sbin/opensips 12633
GNU gdb (GDB) Red Hat Enterprise Linux (7.2-60.el6_4.1)
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are 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 was configured as x86_64-redhat-linux-gnu.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from /usr/sbin/opensips...done.
Attaching to program: /usr/sbin/opensips, process 12633
Reading symbols from /lib64/snoopy.so...done.
Loaded symbols for /lib64/snoopy.so
Reading symbols from /lib64/libdl.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib64/libdl.so.2
Reading symbols from /lib64/libresolv.so.2...(no debugging symbols 
found)...done.
Loaded symbols for /lib64/libresolv.so.2
Reading symbols from /usr/lib64/libssl.so.10...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib64/libssl.so.10
Reading symbols from /usr/lib64/libcrypto.so.10...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib64/libcrypto.so.10
Reading symbols from /lib64/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib64/libc.so.6
Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols 
found)...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
Reading symbols from /lib64/libgssapi_krb5.so.2...(no debugging symbols 
found)...done.
Loaded symbols for /lib64/libgssapi_krb5.so.2
Reading symbols from /lib64/libkrb5.so.3...(no debugging symbols found)...done.
Loaded symbols for /lib64/libkrb5.so.3
Reading symbols from /lib64/libcom_err.so.2...(no debugging symbols 
found)...done.
Loaded symbols for /lib64/libcom_err.so.2
Reading symbols from /lib64/libk5crypto.so.3...(no debugging symbols 
found)...done.
Loaded symbols for /lib64/libk5crypto.so.3
Reading symbols from /lib64/libz.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib64/libz.so.1
Reading symbols from /lib64/libkrb5support.so.0...(no debugging symbols 
found)...done.
Loaded symbols for /lib64/libkrb5support.so.0
Reading symbols from /lib64/libkeyutils.so.1...(no debugging symbols 
found)...done.
Loaded symbols for /lib64/libkeyutils.so.1
Reading symbols from /lib64/libpthread.so.0...(no debugging symbols 
found)...done.
[Thread debugging using libthread_db enabled]
Loaded symbols for /lib64/libpthread.so.0
Reading symbols from /lib64/libselinux.so.1...(no debugging symbols 
found)...done.
Loaded symbols for /lib64/libselinux.so.1
Reading symbols from /usr/lib64/opensips/modules/signaling.so...done.
Loaded symbols for /usr/lib64/opensips/modules/signaling.so
Reading symbols from /usr/lib64/opensips/modules/sl.so...done.
Loaded symbols for /usr/lib64/opensips/modules/sl.so
Reading symbols from /usr/lib64/opensips/modules/tm.so...done.
Loaded symbols for /usr/lib64/opensips/modules/tm.so
Reading symbols from /usr/lib64/opensips/modules/rr.so...done.
Loaded symbols for /usr/lib64/opensips/modules/rr.so
Reading symbols from /usr/lib64/opensips/modules/maxfwd.so...done.
Loaded symbols for /usr/lib64/opensips/modules/maxfwd.so
Reading symbols from /usr/lib64/opensips/modules/sipmsgops.so...done.
Loaded symbols for /usr/lib64/opensips/modules/sipmsgops.so
Reading symbols from /usr/lib64/opensips/modules/mi_fifo.so...done.
Loaded symbols for /usr/lib64/opensips/modules/mi_fifo.so
Reading symbols from /usr/lib64/opensips/modules/uri.so...done.
Loaded symbols for /usr/lib64/opensips/modules/uri.so
Reading symbols from /usr/lib64/opensips/modules/usrloc.so...done.
Loaded symbols for /usr/lib64/opensips/modules/usrloc.so
Reading symbols from /usr/lib64/opensips/modules/registrar.so...done.
Loaded symbols for /usr/lib64/opensips/modules/registrar.so
Reading symbols from /usr/lib64/opensips/modules/acc.so...done.
Loaded symbols for /usr/lib64/opensips/modules/acc.so
Reading symbols from /lib64/libnss_files.so.2...(no debugging symbols 
found)...done.
Loaded symbols for 

Re: [OpenSIPS-Users] io_watch_del: trying to delete already erased entry

[Gupta, Rahul]

Any ideas on this ? This is happening pretty regularly on our servers. Is there 
any specific logs I can capture to help debug this issue ?

-Original Message-
From: users-boun...@lists.opensips.org 
[mailto:users-boun...@lists.opensips.org] On Behalf Of seanchann
Sent: Wednesday, May 27, 2015 1:07 AM
To: users@lists.opensips.org
Subject: Re: [OpenSIPS-Users] io_watch_del: trying to delete already erased 
entry

yeah， I have  same error  in 1.10.1：
May 27 11:39:41 voip_lion /usr/sbin/opensips[39760]:
ERROR:core:tcp_read_req: bad request, state=0, error=2
buf:#012#012parsed:#012
May 27 11:39:41 voip_lion /usr/sbin/opensips[39760]:
ERROR:core:io_watch_del: trying to delete already erased entry 534 in the 
hash(0, 0, (nil)) ) May 27 11:39:41 voip_lion /usr/sbin/opensips[39760]:
ERROR:core:tcp_read_req: bad request, state=0, error=2
buf:#012#012parsed:#012



--
View this message in context: 
http://opensips-open-sip-server.1449251.n2.nabble.com/io-watch-del-trying-to-delete-already-erased-entry-tp7597269p7597275.html
Sent from the OpenSIPS - Users mailing list archive at Nabble.com.

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] io_watch_del: trying to delete already erased entry

[Gupta, Rahul]

Hi,

I am using opensips 1.11.3-tls (x86_64/linux)

The following error is flooding my log file, any ideas what should I look for ?

DBG:core:tcp_read_req: - received from: port 5070
DBG:core:print_ip: - received from: ip 10.204.177.37
DBG:core:io_watch_del: io_watch_del op on index -1 17 (0x7e60a0, 17, -1, 
0x10,0x3) fd_no=2 called
ERROR:core:io_watch_del: trying to delete already erased entry 17 in the 
hash(0, 0, (nil)) )
DBG:core:release_tcpconn:  releasing con 0x7faec0ad9d50, state -2, fd=17, id=257
DBG:core:release_tcpconn:  extra_data (nil)
DBG:core:tcp_read_req: Using the global ( per process ) buff


I also see a lot of following error from earlier log files.

ERROR:core:io_watch_del: BUG - trying to del fd 45 with flags 2 1
ERROR:core:tcp_read_req: bad request, state=0, error=2 buf:
CRITICAL:core:io_watch_del: invalid fd -1, not in [0, 2)



Thanks
Rahul Gupta


Waters voting is open for 2015...help IPC win Best Trading Floor Communication 
System Provider and Best Network Provider.  Your vote matters!  CLICK 
HEREhttps://www.surveymonkey.com/s/WatersRankings2015 to answer Questions 27 
and 29.


--

DISCLAIMER: This e-mail may contain information that is confidential, 
privileged or otherwise protected from disclosure. If you are not an intended 
recipient of this e-mail, do not duplicate or redistribute it by any means. 
Please delete it and any attachments and notify the sender that you have 
received it in error. Unintended recipients are prohibited from taking action 
on the basis of information in this e-mail.E-mail messages may contain computer 
viruses or other defects, may not be accurately replicated on other systems, or 
may be intercepted, deleted or interfered with without the knowledge of the 
sender or the intended recipient. If you are not comfortable with the risks 
associated with e-mail messages, you may decide not to use e-mail to 
communicate with IPC. IPC reserves the right, to the extent and under 
circumstances permitted by applicable law, to retain, monitor and intercept 
e-mail messages to and from its systems.

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] CANCEL in t_relay() not forwarding user defined Headers

[Gupta, Rahul]

Hi Bogdan, thanks for clarifying the behavior. In our implementation, we need 
those user defined headers to make it through the proxy, is there any way to 
populate the stateful CANCEL with the incoming user-defined headers ?

Thanks
Rahul

From: Bogdan-Andrei Iancu [mailto:bog...@opensips.org]
Sent: Thursday, May 07, 2015 1:17 PM
To: Gupta, Rahul; OpenSIPS users mailling list
Subject: Re: [OpenSIPS-Users] CANCEL in t_relay() not forwarding user defined 
Headers

Rahul,

As per RFC, in stateless mode there is no branch (for the newly added VIA) - as 
branch is transaction oriented. And the RFC3261 recommends to reuse the 
previous VIA hdr (if exists).

Regards,



Bogdan-Andrei Iancu

OpenSIPS Founder and Developer

http://www.opensips-solutions.com
On 07.05.2015 20:01, Gupta, Rahul wrote:
Hi Bogdan,

I want to use opensips as stateless proxy that's why I tried forward() which is 
causing the branch  issue as shown below, the branch in both the Via headers 
are same.

CANCEL sip:@IP:PORT SIP/2.0
From: Alan 
Altman[3004]sip:@IP:PORT;tag=389cc678-0-13c4-65014-16288-3d1c9b70-16288
To: sip:@IP:PORT
Call-ID: 10589b68-0-13c4-65014-16288-156334b2-16288
CSeq: 1 CANCEL
Via: SIP/2.0/UDP IP:PORT;branch=z9hG4bK-16288-568e507-60d8e02-38903830
Via: SIP/2.0/UDP IP:PORT;branch=z9hG4bK-16288-568e507-60d8e02-38903830
Reason: SIP;cause=200;text=User Release
Max-Forwards: 69
Supported: 
timer,replaces,from-change,histinfo,answermode,eventlist,recipient-list-subscribe
User-Agent: test user agent
Content-Length: 0
X-testHeader: RAHUL


If we use t_relay(), I want to forward X-testHeader to the endpoint.



From: Bogdan-Andrei Iancu [mailto:bog...@opensips.org]
Sent: Thursday, May 07, 2015 12:39 PM
To: OpenSIPS users mailling list; Gupta, Rahul
Subject: Re: [OpenSIPS-Users] CANCEL in t_relay() not forwarding user defined 
Headers

Hi Rahul,

As per RFC3261, the stateful CANCELs are hop-by-hop - which means each hop 
consumes the incoming CANCEL and generates a new one for the next hop.
This is why the headers do not propagate.

What kind of headers are looking to be passed further ?

Regards,



Bogdan-Andrei Iancu

OpenSIPS Founder and Developer

http://www.opensips-solutions.com
On 06.05.2015 20:45, Gupta, Rahul wrote:
I am using opensips as a proxy, when a CANCEL to an INVITE comes in, its 
processed as follows

# CANCEL processing
if (is_method(CANCEL))
{
if (t_check_trans())
t_relay();
exit;
}

in t_relay() seems like its creating new transaction for CANCEL and forwarding 
to the destination. However its not copying user-defined Headers which comes as 
a part of CANCEL. Is there a way to forward the other Headers ?

I also tried using forward(). In this case, all the headers are getting 
forwarded, however, the branch in Via header is getting duplicated from the 
incoming VIA header which is causing issues with the endpoint.

Question 1) If I use t_realy() for CANCEL, then how do I forward user defined 
Headers ?
Question 2) If I use forward() for CANCEL, then how do I get the Via Header 
with proper branch as created in INVITE ?

--

DISCLAIMER: This e-mail may contain information that is confidential, 
privileged or otherwise protected from disclosure. If you are not an intended 
recipient of this e-mail, do not duplicate or redistribute it by any means. 
Please delete it and any attachments and notify the sender that you have 
received it in error. Unintended recipients are prohibited from taking action 
on the basis of information in this e-mail.E-mail messages may contain computer 
viruses or other defects, may not be accurately replicated on other systems, or 
may be intercepted, deleted or interfered with without the knowledge of the 
sender or the intended recipient. If you are not comfortable with the risks 
associated with e-mail messages, you may decide not to use e-mail to 
communicate with IPC. IPC reserves the right, to the extent and under 
circumstances permitted by applicable law, to retain, monitor and intercept 
e-mail messages to and from its systems.






___

Users mailing list

Users@lists.opensips.orgmailto:Users@lists.opensips.org

http://lists.opensips.org/cgi-bin/mailman/listinfo/users


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] tcp_blocking_connect for same ip but different listen port

[Gupta, Rahul]

One of the UAC changed its listen port from 5060 to 5070 and sent a new 
subscription however before the subscription made it to UAS, UAS sent a NOTIFY 
to UAC to port 5060 and then immediately another NOTIFY to UAC to port 5070

Old setup:
UAC (5060) --- opensips(proxy) (5060) --- UAS (5059)
New Setup:
UAC (5070) --- opensips(proxy) (5060) --- UAS (5059)

Opensips attempted to forward the first NOTIFY to UAC at port 5060 which 
obviously timed out with tcp connect failed as expected
First NOTIFY :
NOTIFY sip:user1@IPADDRESS:5060;transport=tcp SIP/2.0

Opensips sent the 2nd NOTIFY after 10 seconds to UAC at port 5070. If the port 
specified in SIP URI is different then why the second request is put into the 
queue and had to wait for 10 sec blocking timeout ?
Seconf NOTIFY:
NOTIFY sip:user1@IP_ADDRESS:5070;transport=tcp SIP/2.0



Is there any flag/param I can specify in my opensips.cfg file to fix this ?

--

DISCLAIMER: This e-mail may contain information that is confidential, 
privileged or otherwise protected from disclosure. If you are not an intended 
recipient of this e-mail, do not duplicate or redistribute it by any means. 
Please delete it and any attachments and notify the sender that you have 
received it in error. Unintended recipients are prohibited from taking action 
on the basis of information in this e-mail.E-mail messages may contain computer 
viruses or other defects, may not be accurately replicated on other systems, or 
may be intercepted, deleted or interfered with without the knowledge of the 
sender or the intended recipient. If you are not comfortable with the risks 
associated with e-mail messages, you may decide not to use e-mail to 
communicate with IPC. IPC reserves the right, to the extent and under 
circumstances permitted by applicable law, to retain, monitor and intercept 
e-mail messages to and from its systems.

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] CANCEL in t_relay() not forwarding user defined Headers

[Gupta, Rahul]

Hi Bogdan,

I want to use opensips as stateless proxy that's why I tried forward() which is 
causing the branch  issue as shown below, the branch in both the Via headers 
are same.

CANCEL sip:@IP:PORT SIP/2.0
From: Alan 
Altman[3004]sip:@IP:PORT;tag=389cc678-0-13c4-65014-16288-3d1c9b70-16288
To: sip:@IP:PORT
Call-ID: 10589b68-0-13c4-65014-16288-156334b2-16288
CSeq: 1 CANCEL
Via: SIP/2.0/UDP IP:PORT;branch=z9hG4bK-16288-568e507-60d8e02-38903830
Via: SIP/2.0/UDP IP:PORT;branch=z9hG4bK-16288-568e507-60d8e02-38903830
Reason: SIP;cause=200;text=User Release
Max-Forwards: 69
Supported: 
timer,replaces,from-change,histinfo,answermode,eventlist,recipient-list-subscribe
User-Agent: test user agent
Content-Length: 0
X-testHeader: RAHUL


If we use t_relay(), I want to forward X-testHeader to the endpoint.



From: Bogdan-Andrei Iancu [mailto:bog...@opensips.org]
Sent: Thursday, May 07, 2015 12:39 PM
To: OpenSIPS users mailling list; Gupta, Rahul
Subject: Re: [OpenSIPS-Users] CANCEL in t_relay() not forwarding user defined 
Headers

Hi Rahul,

As per RFC3261, the stateful CANCELs are hop-by-hop - which means each hop 
consumes the incoming CANCEL and generates a new one for the next hop.
This is why the headers do not propagate.

What kind of headers are looking to be passed further ?

Regards,


Bogdan-Andrei Iancu

OpenSIPS Founder and Developer

http://www.opensips-solutions.com
On 06.05.2015 20:45, Gupta, Rahul wrote:
I am using opensips as a proxy, when a CANCEL to an INVITE comes in, its 
processed as follows

# CANCEL processing
if (is_method(CANCEL))
{
if (t_check_trans())
t_relay();
exit;
}

in t_relay() seems like its creating new transaction for CANCEL and forwarding 
to the destination. However its not copying user-defined Headers which comes as 
a part of CANCEL. Is there a way to forward the other Headers ?

I also tried using forward(). In this case, all the headers are getting 
forwarded, however, the branch in Via header is getting duplicated from the 
incoming VIA header which is causing issues with the endpoint.

Question 1) If I use t_realy() for CANCEL, then how do I forward user defined 
Headers ?
Question 2) If I use forward() for CANCEL, then how do I get the Via Header 
with proper branch as created in INVITE ?

--

DISCLAIMER: This e-mail may contain information that is confidential, 
privileged or otherwise protected from disclosure. If you are not an intended 
recipient of this e-mail, do not duplicate or redistribute it by any means. 
Please delete it and any attachments and notify the sender that you have 
received it in error. Unintended recipients are prohibited from taking action 
on the basis of information in this e-mail.E-mail messages may contain computer 
viruses or other defects, may not be accurately replicated on other systems, or 
may be intercepted, deleted or interfered with without the knowledge of the 
sender or the intended recipient. If you are not comfortable with the risks 
associated with e-mail messages, you may decide not to use e-mail to 
communicate with IPC. IPC reserves the right, to the extent and under 
circumstances permitted by applicable law, to retain, monitor and intercept 
e-mail messages to and from its systems.





___

Users mailing list

Users@lists.opensips.orgmailto:Users@lists.opensips.org

http://lists.opensips.org/cgi-bin/mailman/listinfo/users

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] CANCEL in t_relay() not forwarding user defined Headers

[Gupta, Rahul]

I am using opensips as a proxy, when a CANCEL to an INVITE comes in, its 
processed as follows

# CANCEL processing
if (is_method(CANCEL))
{
if (t_check_trans())
t_relay();
exit;
}

in t_relay() seems like its creating new transaction for CANCEL and forwarding 
to the destination. However its not copying user-defined Headers which comes as 
a part of CANCEL. Is there a way to forward the other Headers ?

I also tried using forward(). In this case, all the headers are getting 
forwarded, however, the branch in Via header is getting duplicated from the 
incoming VIA header which is causing issues with the endpoint.

Question 1) If I use t_realy() for CANCEL, then how do I forward user defined 
Headers ?
Question 2) If I use forward() for CANCEL, then how do I get the Via Header 
with proper branch as created in INVITE ?

--

DISCLAIMER: This e-mail may contain information that is confidential, 
privileged or otherwise protected from disclosure. If you are not an intended 
recipient of this e-mail, do not duplicate or redistribute it by any means. 
Please delete it and any attachments and notify the sender that you have 
received it in error. Unintended recipients are prohibited from taking action 
on the basis of information in this e-mail.E-mail messages may contain computer 
viruses or other defects, may not be accurately replicated on other systems, or 
may be intercepted, deleted or interfered with without the knowledge of the 
sender or the intended recipient. If you are not comfortable with the risks 
associated with e-mail messages, you may decide not to use e-mail to 
communicate with IPC. IPC reserves the right, to the extent and under 
circumstances permitted by applicable law, to retain, monitor and intercept 
e-mail messages to and from its systems.

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users