Re: [OpenSIPS-Users] B2BUA, authenticated INVITEs with "ACK for a negative reply"
On 11/29/2016 04:09 AM, Nathan Ward wrote: On 29/11/2016, at 5:25 AM, Răzvan Crainea wrote: Hi, Nathan! Have you tried calling b2b_init_request() with the "a" flag [1]? [1] http://www.opensips.org/html/docs/modules/2.2.x/b2b_logic.html#id294010 Hi, Yes I have. This passes through the authentication challenge headers in the 401/407, and then any subsequent response headers in the new INVITE. b2b_logic/logic.c:1239 calls b2b_mark_todel, after forwarding the message - because it is marked to_del, the ACK that the originator of the INVITE sends in response to the 401/407 deletes the session. I don’t understand how this flag is intended to be used, as there doesn’t seem to be anything in the code to avoid setting to_del if the response is a 401/407 (or anything >=300, actually) with auth challenge headers. All it does is pass through the headers, but as it deletes the session, a new Call-ID is issued by B2BUA when the authenticated invite is generated. Hi, Nathan! Yes, you are right, the flag simply passes the auth headers between the two legs. So you were saying that you were only using b2b for topology hiding? If so, why not using directly the topology_hiding module[1]? [1] http://www.opensips.org/html/docs/modules/2.2.x/topology_hiding.html Best regards, Răzvan Crainea OpenSIPS Solutions www.opensips-solutions.com ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] B2BUA, authenticated INVITEs with "ACK for a negative reply"
> On 29/11/2016, at 9:26 PM, Răzvan Crainea wrote: > > On 11/29/2016 04:09 AM, Nathan Ward wrote: >>> On 29/11/2016, at 5:25 AM, Răzvan Crainea wrote: >>> >>> Hi, Nathan! >>> >>> Have you tried calling b2b_init_request() with the "a" flag [1]? >>> >>> [1] http://www.opensips.org/html/docs/modules/2.2.x/b2b_logic.html#id294010 >> Hi, >> >> Yes I have. This passes through the authentication challenge headers in the >> 401/407, and then any subsequent response headers in the new INVITE. >> >> b2b_logic/logic.c:1239 calls b2b_mark_todel, after forwarding the message - >> because it is marked to_del, the ACK that the originator of the INVITE sends >> in response to the 401/407 deletes the session. >> >> I don’t understand how this flag is intended to be used, as there doesn’t >> seem to be anything in the code to avoid setting to_del if the response is a >> 401/407 (or anything >=300, actually) with auth challenge headers. All it >> does is pass through the headers, but as it deletes the session, a new >> Call-ID is issued by B2BUA when the authenticated invite is generated. >> > Hi, Nathan! > > Yes, you are right, the flag simply passes the auth headers between the two > legs. > So you were saying that you were only using b2b for topology hiding? If so, > why not using directly the topology_hiding module[1]? Sure that’s an option, however I would like to understand the B2BUA module better. What is the use case for passing authentication headers if the B2BUA instance is shut down when a challenge (401/407) passes through? -- Nathan Ward ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] handle_timer_job delay in execution
Hi, Adrian! What version of OpenSIPS are you using? Can you update to the latest version? Can you also run an "opensipsctl ps" and send the output back? Also, can you send the list of the modules you are using? Best regards, Răzvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 11/28/2016 04:42 PM, Adrian Fretwell wrote: Hi Razvan, No other users of the mysql, everything looks idle. The machine is quite powerful a Dell PowerEdge Server with Dual Intel Xeon CPUs (12 cores/24 threads) and 32Gb Memory and a three disk RAID 5 array. Here is the parameters from config: children=4 dns=no rev_dns=no # for customers listen=udp:XX.XX.XX.X1:5060 # for gateways listen=udp:XX.XX.XX.X2:5060 # for internal media etc. listen=udp:XX.XX.XX.X1:8060 From /etc/defaults # Amount of shared memory to allocate for the running OpenSIPS server (in Mb) S_MEMORY=512 # Amount of pkg memory to allocate for the running OpenSIPS server (in Mb) P_MEMORY=16 Kind regards, Adrian. On 28/11/16 13:42, Răzvan Crainea wrote: Are you doing any DB queries that might take a lot of time? Also, how many children are you using? Best regards, Răzvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 11/28/2016 03:33 PM, Adrian Fretwell wrote: Hi Razvan, I don't see the error regularly, I think that's what is making it hard to track down, they just seem to randomly occur. Anyway here is the output of the fifo command, I will check this as soon as I get the next error. tm:received_replies:: 177 tm:relayed_replies:: 111 tm:local_replies:: 6 tm:UAS_transactions:: 59 tm:UAC_transactions:: 3 tm:2xx_transactions:: 56 tm:3xx_transactions:: 0 tm:4xx_transactions:: 6 tm:5xx_transactions:: 0 tm:6xx_transactions:: 0 tm:inuse_transactions:: 0 Kind regards, Adrian Fretwell The Old School house Top Green Sibthorpe Nottinghamshire NG23 5PN. On 28/11/16 13:08, Răzvan Crainea wrote: Hi, Adrian! Are you still seeing those errors, even if there is no traffic? Can you check if you have any hung transactions? Just run: scripts/opensipsctl fifo get_statistics tm: Best regards, Răzvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 11/28/2016 12:57 PM, Adrian Fretwell wrote: Hello, help please. Can anyone give me some direction on how to diagnose what is causing timer job delays in execution? This SIP proxy (2.2.1) has virtually no load, you can see from the timestamps in the log extract and yet there is still a delay. I don't know where to start looking. Nov 28 08:50:37 sip-01 /usr/local/opensips-pxy-2.2.1/sbin/opensips[22176]: main: 185.40.4.47 Relay denied. Nov 28 08:51:14 sip-01 /usr/local/opensips-pxy-2.2.1/sbin/opensips[22193]: WARNING:core:handle_timer_job: timer job has a 7 us delay in execution Nov 28 08:54:22 sip-01 /usr/local/opensips-pxy-2.2.1/sbin/opensips[22178]: main: 185.40.4.198 Relay denied. Kind regards, Adrian Fretwell The Old School house Top Green Sibthorpe Nottinghamshire NG23 5PN. T: 01636 525360 M: 07850 756603 ___ 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 ___ 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 ___ 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
Re: [OpenSIPS-Users] Actions that apply to all branches
Hi, The per-branch data is : * R-URI * DST-URI (outbound proxy) * PATH header * q value (priority) * send_socket * branch flags Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 28.11.2016 14:11, Schoolhouse Filing wrote: Hi Razvan, What I found was then if I appended branches then called force_send_socket() only the current branch went out on that interface, the other branches went out on a different interface. It's not a problem I will re-structure my script, I was simply appending branches to create a ring group. Kind Regards, Adrian. On 28/11/16 09:35, Răzvan Crainea wrote: Hi, Adrian! I don't think you will find such a list. Usually the idea is to do the changes that affect all branches in the main route, and if you want to do per-branch changes, do them in the branch_route. Are you sure that force_send_socket() only applies to the main branch? If you call force_send_socket() in the main route, and then add a second branch, the messages leave on different interfaces? Best regards, Răzvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 11/26/2016 12:19 PM, Adrian Fretwell wrote: Hello, I understand from the documentation that after calling append_branch() any further URI manipulations only apply to the main branch, but I am trying to understand what actions will still apply over all the branches. For example I discovered that rtpproxy_offer() appears to affect all branches, but force_send_socket() only apples to the main branch. Is there a list or rule that will help me work out what I need to apply before branching and what I can leave until later, perhaps until just before t_relay() is called? I hope my question makes sense. Kind regards, Adrian Fretwell The Old School house Top Green Sibthorpe Nottinghamshire NG23 5PN. T: 01636 525360 M: 07850 756603 This electronic message contains information from A-Squared Engineering Services which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email to adrian.fretw...@topgreen.co.uk immediately. ___ 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 ___ 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
Re: [OpenSIPS-Users] B2BUA, authenticated INVITEs with "ACK for a negative reply"
On 11/29/2016 10:36 AM, Nathan Ward wrote: On 29/11/2016, at 9:26 PM, Răzvan Crainea wrote: On 11/29/2016 04:09 AM, Nathan Ward wrote: On 29/11/2016, at 5:25 AM, Răzvan Crainea wrote: Hi, Nathan! Have you tried calling b2b_init_request() with the "a" flag [1]? [1] http://www.opensips.org/html/docs/modules/2.2.x/b2b_logic.html#id294010 Hi, Yes I have. This passes through the authentication challenge headers in the 401/407, and then any subsequent response headers in the new INVITE. b2b_logic/logic.c:1239 calls b2b_mark_todel, after forwarding the message - because it is marked to_del, the ACK that the originator of the INVITE sends in response to the 401/407 deletes the session. I don’t understand how this flag is intended to be used, as there doesn’t seem to be anything in the code to avoid setting to_del if the response is a 401/407 (or anything >=300, actually) with auth challenge headers. All it does is pass through the headers, but as it deletes the session, a new Call-ID is issued by B2BUA when the authenticated invite is generated. Hi, Nathan! Yes, you are right, the flag simply passes the auth headers between the two legs. So you were saying that you were only using b2b for topology hiding? If so, why not using directly the topology_hiding module[1]? Sure that’s an option, however I would like to understand the B2BUA module better. What is the use case for passing authentication headers if the B2BUA instance is shut down when a challenge (401/407) passes through? Hi, Nathan! From SIP perspective, the authentication mechanism is completely independent from the message/call. That's why you can even use the same credentials for different calls, as long as the nonce does not change. So the auth server, does not have to map the credentials with a call-id. Some servers might enforce this requirement - however, unfortunately those will not work with opensips B2B. From OpenSIPS perspective, when it receives the 401/407, the transaction will be terminated, and the B2B will destroy the associated entities. When the new INVITE comes in, it will create a completly new entity, that will contain a different Callid (and will be seen as a new leg). These two entities are not corelated at all in the current code. That's why for now the current B2B implementation does not support your scenario. Best regards, Răzvan Crainea OpenSIPS Solutions www.opensips-solutions.com ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Conflicting information from commands 'opensipsctl ul show' and ' opensipsctl fifo list_tcp_conns '.
Hi. I have peer A and peer B online on my OpenSIPS. After removing peer A from table location and reseting peer A, I have: Connection:: ID=29 Type=tcp State=0 Source=127.0.0.1:52887 Destination=127.0.0.1:5060 Lifetime=1970-01-01 08:44:41 It means that peer A is online on OpenSIPS via TCP socket with port 52887. This is the result of command ' opensipsctl fifo list_tcp_conns '. However, the commad 'opensipsctl ul show' gives me: AOR:: intercomA_5dtUWgwgqzR6 Contact:: sip:intercomA_5dtUWgwgqzR6@127.0.0.1:48694;transport=TCP;ob Q= Expires:: 479 Callid:: 5694778c-6178-4e80-bf2e-7a4dc0deb5d1 Cseq:: 37504 User-agent:: n/a State:: CS_SYNC Flags:: 0 Cflags:: Socket:: tcp:127.0.0.1:5060 Methods:: 8063 Attr:: in_same_network SIP_instance:: It means that peer A is online on OpenSIPS via TCP socket with port 48694. So, I have a kind of conflict here. How can it be possible? So, if peer A calls peer B, when B answers I can see the following log: Jan 1 08:36:14 [435] ERROR:core:tcpconn_async_connect: failed to retrieve SO_ERROR [server=127.0.0.1:48694] (111) Connection refused Why such behavior does exist in OpenSIPS? How to avoid it? And after a while a new TCP connection appered in port 52887. Like this: Contact:: sip:intercomA_5dtUWgwgqzR6@127.0.0.1:52887;transport=TCP;ob Q= Expires:: 236 Callid:: 96672dc5-a98c-468e-a07a-aca27748791a Cseq:: 25094 User-agent:: n/a State:: CS_SYNC Flags:: 0 Cflags:: Socket:: tcp:127.0.0.1:5060 Methods:: 8063 Attr:: in_same_network SIP_instance:: Could it be a problem in OpenSIPS? Any hint will be very helpful! Best regards. RODRIGO PIMENTA CARVALHO Inatel Competence Center Software Ph: +55 35 3471 9200 RAMAL 979 ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
