Re: [OpenSIPS-Users] trying to understand the E_DLG_STATE_CHANGED

2017-09-19 Thread Khalil Khamlichi
Hi Robert,

Thanks for your idea, the only issue is that it involves polling the server
and I don't want to go that path. actually with my solution the results
were quite good and precise, the reason is that a 200 OK is always an
established call and an E_ACC_CDR is always an end to a successful call and
never to another status of a call, and on both places we have access to all
dialog variables and/or acc_extra variables.

Again, Thanks for your idea.

On Tue, Sep 19, 2017 at 3:26 PM, Mundkowsky, Robert 
wrote:

> Using E_DLG_STATE_CHANGED to keep a count of active dialogs seems
> reasonable.  If you want the callerID, you would use the “hash_id of
> dialog” and the “b= hash_entry of dialog” to look up the dialog in the
> table and get more info like the callerid.  You use the dlg_list command to
> look up data in the table. I don’t know if you could do this in the
> openSIPS config file alone, you likely have to have a script that is called
> to query the table, parse the data you want, ….
>
>
>
> Looks like the key is of the form:
>
>
>
> :< hash_entry> like “1527:459551172” below
>
>
>
> Example of details from dlg_list:
>
>
>
> rmundkowsky: ~$ /export/Apps/opensips/sbin/opensipsctl fifo dlg_list
>
> database engine 'MYSQL' loaded
>
> Control engine 'FIFO' loaded
>
> entering fifo_cmd dlg_list
>
> dialog::  hash=1527:459551172 dialog_id=6558874612164
>
> state:: 3
>
> user_flags:: 0
>
> timestart:: 1505826879
>
> datestart:: 2017-09-19 09:14:39
>
> timeout:: 1505848479
>
> dateout:: 2017-09-19 15:14:39
>
> callid:: 28456fb41ba510f57257de424e73e...@xx.xx.xx.xx:5060
>
> from_uri:: sip:opens...@xx.xxx.xx.xx
>
> to_uri:: sip:7...@xx.xx.xx.xx:5060
>
> caller_tag:: as7e7bed90
>
> caller_contact:: sip:ZZZ@ XX.XX.XX.XX:5060
>
> callee_cseq:: 0
>
> caller_route_set::
>
> caller_bind_addr:: udp:XX.XX.XX.XX:5060
>
> caller_sdp::
>
> CALLEES::
>
> callee::
>
> callee_tag:: 255851520
>
> callee_contact:: sip:YYY@
> XX.XX.XX.XX:5090;transport=udp
>
> caller_cseq:: 102
>
> callee_route_set::
>
> callee_bind_addr:: udp: XX.XX.XX.XX:5060
>
> callee_sdp::
>
> FIFO command was:
>
> :dlg_list:osips_rply_e7e14d04
>
>
>
> Robert
>
>
>
> *From:* Users [mailto:users-boun...@lists.opensips.org] *On Behalf Of *Khalil
> Khamlichi
> *Sent:* Tuesday, September 19, 2017 8:54 AM
> *To:* OpenSIPS users mailling list 
> *Subject:* Re: [OpenSIPS-Users] trying to understand the
> E_DLG_STATE_CHANGED
>
>
>
> Hi Răzvan,
>
>
>
> Thanks for your answer.
>
>
>
> I ended up using onreply_route and checking if ($rs == "200") to increment
> connect_calls and then event_route[E_ACC_CDR]  to decrement
> connected_calls.
>
>
>
> multiple local tests are giving expected behavior, will need to test on
> production to confirm though.
>
>
>
> Thanks a lot for your help.
>
>
>
> On Mon, Sep 18, 2017 at 9:47 AM, Răzvan Crainea 
> wrote:
>
> Hi, Khalil!
>
> To be honest, I think this event was initially made to be used with the MI
> dlg_end_dlg command, which only terminates a dialog. However, you could run
> 'opensipsctl fifo dlg_list' and match the hash_id and hash_entry against
> the returned values, and then identify the callid.
>
> If you would also like to receive the callid in the event, please open a
> feature request[1].
>
> [1] https://github.com/OpenSIPS/opensips/issues
> 
>
> Best regards,
>
> Răzvan Crainea
>
> OpenSIPS Developer
>
> www.opensips-solutions.com 
> 
>
> On 09/15/2017 10:46 PM, Khalil Khamlichi wrote:
>
> Hi everyone,
>
>
>
> I am trying to understand dialog module eventing system.
>
>
>
> I have added this route :
>
>
>
>
>
> event_route[E_DLG_STATE_CHANGED] {
>
>
>
> fetch_event_params("$avp(a);$avp(b);$avp(c);$avp(d);$avp(e);$avp(f)");
>
>
>
> cache_raw_query("redis:0", "PUBLISH serv1 fetch_event_params=$avp(a),$
> avp(b),$avp(c),$avp(d),$avp(e),$avp(f)", "$avp(res)");
>
>
>
> }
>
>
>
>
>
> so for each event I can watch an entry
>
>
>
> 1505503997.413642 [0 127.0.0.1:39734
> 

Re: [OpenSIPS-Users] Weird freeze/crash

2017-09-19 Thread Daniel Zanutti
Hi Razvan

Version in use is 1.11.9. The problem is that it freezes, so there's no
automatic crash dump being generated.

I'll try to take a look when it happens again.

Thanks

On Tue, Sep 19, 2017 at 10:20 AM, Răzvan Crainea 
wrote:

> Hi, Daniel!
>
> Looks like a crash.
> What version of OpenSIPS are you using? If you could extract a coredump,
> it would be really helpful.
>
> Best regards,
>
> Răzvan Crainea
> OpenSIPS Core Developer
> http://www.opensips-solutions.com
>
>
> On 09/19/2017 04:07 PM, Daniel Zanutti wrote:
>
>> Hi
>>
>> Do you guys have an idea of what happened?
>>
>> Sep 10 09:35:13 /sbin/opensips[13579]: NOTICE:core:io_wait_loop_epoll:
>> EPOLLIN(read) event: epoll_wait() set event EPOLLHUP - connection closed by
>> the remote peer!
>> Sep 10 09:35:13 /sbin/opensips[13579]: CRITICAL:core:receive_fd: EOF on 42
>> Sep 10 09:35:14 /sbin/opensips[13439]: NOTICE:presence:destroy: destroy
>> module ...
>> Sep 10 09:35:14 /sbin/opensips[13439]: 
>> ERROR:nat_traversal:save_keepalive_state:
>> failed to open keepalive state file for writing: Permission denied
>>
>> At this point, opensips froze and no calls were being processed. I had to
>> kill it to restart. Unfortunatelly had no time to gdb on it.
>>
>> Thanks
>>
>>
>>
>>
>> ___
>> 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] trying to understand the E_DLG_STATE_CHANGED

2017-09-19 Thread Mundkowsky, Robert
Using E_DLG_STATE_CHANGED to keep a count of active dialogs seems reasonable.  
If you want the callerID, you would use the “hash_id of dialog” and the “b= 
hash_entry of dialog” to look up the dialog in the table and get more info like 
the callerid.  You use the dlg_list command to look up data in the table. I 
don’t know if you could do this in the openSIPS config file alone, you likely 
have to have a script that is called to query the table, parse the data you 
want, ….

Looks like the key is of the form:

:< hash_entry> like “1527:459551172” below

Example of details from dlg_list:

rmundkowsky: ~$ /export/Apps/opensips/sbin/opensipsctl fifo dlg_list
database engine 'MYSQL' loaded
Control engine 'FIFO' loaded
entering fifo_cmd dlg_list
dialog::  hash=1527:459551172 dialog_id=6558874612164
state:: 3
user_flags:: 0
timestart:: 1505826879
datestart:: 2017-09-19 09:14:39
timeout:: 1505848479
dateout:: 2017-09-19 15:14:39
callid:: 28456fb41ba510f57257de424e73e...@xx.xx.xx.xx:5060
from_uri:: sip:opens...@xx.xxx.xx.xx
to_uri:: sip:7...@xx.xx.xx.xx:5060
caller_tag:: as7e7bed90
caller_contact:: sip:ZZZ@ XX.XX.XX.XX:5060
callee_cseq:: 0
caller_route_set::
caller_bind_addr:: udp:XX.XX.XX.XX:5060
caller_sdp::
CALLEES::
callee::
callee_tag:: 255851520
callee_contact:: sip:YYY@ XX.XX.XX.XX:5090;transport=udp
caller_cseq:: 102
callee_route_set::
callee_bind_addr:: udp: XX.XX.XX.XX:5060
callee_sdp::
FIFO command was:
:dlg_list:osips_rply_e7e14d04

Robert

From: Users [mailto:users-boun...@lists.opensips.org] On Behalf Of Khalil 
Khamlichi
Sent: Tuesday, September 19, 2017 8:54 AM
To: OpenSIPS users mailling list 
Subject: Re: [OpenSIPS-Users] trying to understand the E_DLG_STATE_CHANGED

Hi Răzvan,

Thanks for your answer.

I ended up using onreply_route and checking if ($rs == "200") to increment 
connect_calls and then event_route[E_ACC_CDR]  to decrement connected_calls.

multiple local tests are giving expected behavior, will need to test on 
production to confirm though.

Thanks a lot for your help.

On Mon, Sep 18, 2017 at 9:47 AM, Răzvan Crainea 
> wrote:
Hi, Khalil!

To be honest, I think this event was initially made to be used with the MI 
dlg_end_dlg command, which only terminates a dialog. However, you could run 
'opensipsctl fifo dlg_list' and match the hash_id and hash_entry against the 
returned values, and then identify the callid.

If you would also like to receive the callid in the event, please open a 
feature request[1].

[1] 
https://github.com/OpenSIPS/opensips/issues

Best regards,


Răzvan Crainea

OpenSIPS Developer

www.opensips-solutions.com
On 09/15/2017 10:46 PM, Khalil Khamlichi wrote:
Hi everyone,

I am trying to understand dialog module eventing system.

I have added this route :


event_route[E_DLG_STATE_CHANGED] {

fetch_event_params("$avp(a);$avp(b);$avp(c);$avp(d);$avp(e);$avp(f)");

cache_raw_query("redis:0", "PUBLISH serv1 
fetch_event_params=$avp(a),$avp(b),$avp(c),$avp(d),$avp(e),$avp(f)", 
"$avp(res)");

}


so for each event I can watch an entry

1505503997.413642 [0 
127.0.0.1:39734]
 "PUBLISH" "serv1" "fetch_event_params=3917,339471624,1,3,,"
1505503997.524535 [0 
127.0.0.1:39762]
 "PUBLISH" "serv1" "fetch_event_params=3917,339471624,3,4,,"
1505504018.809746 [0 

Re: [OpenSIPS-Users] Weird freeze/crash

2017-09-19 Thread Răzvan Crainea

Hi, Daniel!

Looks like a crash.
What version of OpenSIPS are you using? If you could extract a coredump, 
it would be really helpful.


Best regards,

Răzvan Crainea
OpenSIPS Core Developer
http://www.opensips-solutions.com

On 09/19/2017 04:07 PM, Daniel Zanutti wrote:

Hi

Do you guys have an idea of what happened?

Sep 10 09:35:13 /sbin/opensips[13579]: NOTICE:core:io_wait_loop_epoll: 
EPOLLIN(read) event: epoll_wait() set event EPOLLHUP - connection closed 
by the remote peer!

Sep 10 09:35:13 /sbin/opensips[13579]: CRITICAL:core:receive_fd: EOF on 42
Sep 10 09:35:14 /sbin/opensips[13439]: NOTICE:presence:destroy: destroy 
module ...
Sep 10 09:35:14 /sbin/opensips[13439]: 
ERROR:nat_traversal:save_keepalive_state: failed to open keepalive state 
file for writing: Permission denied


At this point, opensips froze and no calls were being processed. I had 
to kill it to restart. Unfortunatelly had no time to gdb on it.


Thanks




___
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] RV: Very Strange Case

2017-09-19 Thread Ben Newlin
Do you have handling in error_route to capture parsing errors? You only 
provided a picture of a trace display, not the actual messages, so it is not 
possible to tell if the message is legit. If it is the exact same message being 
dropped every time, it is likely the message is misformatted.

Ben Newlin

From: Users  on behalf of Jorge Luis Ortea 

Reply-To: OpenSIPS users mailling list 
Date: Tuesday, September 19, 2017 at 8:14 AM
To: "users@lists.opensips.org" 
Subject: Re: [OpenSIPS-Users] RV: Very Strange Case




Hi Razvan,



I know this is like a fantastic story, these points have already been proven;

1.- source and destination over 5060 port for all SIP traffic
2.- I don't use Pike
3.- No firewall rules
4.- Selinux is disabled

I am not tracing with Debug but I set xlog just below route{ and onreply_route{
The truth is that I am baffled...

Could it be that Opensips does not detect these messages as SIP type?  Or 
something like that?

Thank you very much.
Regards.


De: Users  en nombre de Răzvan Crainea 

Enviado: martes, 19 de septiembre de 2017 12:35
Para: users@lists.opensips.org
Asunto: Re: [OpenSIPS-Users] RV: Very Strange Case

Hi, Jorge!

If you are saying the 200 OK is not even logged (are you tracing with Debug), 
it means OpenSIPS doesn't see it. I would check:
1. the 200 OK is sent to the proper port
2. Pike is not blocking the reply
3. local firewall does not block the 200 OK
4. selinux is disabled

Best regards,


Răzvan Crainea

OpenSIPS Developer

www.opensips-solutions.com
Home — OpenSIPS Solutions
www.opensips-solutions.com
OpenSIPS is a mature Open Source implementation of a SIP server. OpenSIPS is 
more than a SIP proxy/router as it includes application-level functionalities.


On 09/19/2017 12:14 PM, Jorge Luis Ortea wrote:


Hi all,

I've been using OpenSIPS for a long time and I have never seen anything like it.

The schema is very simple, OpenSIPS exchanges SIP traffic between SBC and 
Asterisk PBX, during a fax call in response a REINVITE packet a 200 Ok is 
ignore by OpenSIPS, not even writes in log, as if this packet did not exist. 
OpenSIPS always ignores the same SIP packet and its retries.

The sniffer on the Opensips interfaces shows that the packets are arriving 
correctly.

Network diagram:
http://picpaste.com/Schema_OpenSIPS_201709191048-0byZJrw9.jpg

Traffic capture:
http://picpaste.com/Missing_200_OK_201709191101-Vy9ir5tT.jpg
Does anyone think it might be happening?

Very Thanks.
Regards.






___

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] disable_tcp in OpenSIPS 2.3

2017-09-19 Thread Sumit Birla
That did the trick.   Thanks.


> On Sep 18, 2017, at 10:16 PM, Сергей Щеглов  wrote:
> 
> Hi. Try add "tcp_children=0".
> 
> 18.09.2017 19:21, Sumit Birla пишет:
>> “disable_tcp=yes” in the config script gives a syntax error message.   Is 
>> there any way to disable tcp listener in OpenSIPS 2.3 to prevent the 
>> following processes from starting up?
>> 
>> Process::  ID=8 PID=26510 Type=TCP receiver
>> Process::  ID=9 PID=26511 Type=TCP receiver
>> Process::  ID=10 PID=26512 Type=TCP receiver
>> Process::  ID=11 PID=26513 Type=TCP receiver
>> Process::  ID=12 PID=26514 Type=TCP receiver
>> Process::  ID=13 PID=26515 Type=TCP receiver
>> Process::  ID=14 PID=26516 Type=TCP receiver
>> Process::  ID=15 PID=26517 Type=TCP receiver
>> Process::  ID=17 PID=26519 Type=TCP main
>> ___
>> Users mailing list
>> Users@lists.opensips.org 
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users 
>> 
> 
> -- 
> Scheglov Sergey
> ___
> 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] Weird freeze/crash

2017-09-19 Thread Daniel Zanutti
Hi

Do you guys have an idea of what happened?

Sep 10 09:35:13 /sbin/opensips[13579]: NOTICE:core:io_wait_loop_epoll:
EPOLLIN(read) event: epoll_wait() set event EPOLLHUP - connection closed by
the remote peer!
Sep 10 09:35:13 /sbin/opensips[13579]: CRITICAL:core:receive_fd: EOF on 42
Sep 10 09:35:14 /sbin/opensips[13439]: NOTICE:presence:destroy: destroy
module ...
Sep 10 09:35:14 /sbin/opensips[13439]:
ERROR:nat_traversal:save_keepalive_state: failed to open keepalive state
file for writing: Permission denied

At this point, opensips froze and no calls were being processed. I had to
kill it to restart. Unfortunatelly had no time to gdb on it.

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


Re: [OpenSIPS-Users] trying to understand the E_DLG_STATE_CHANGED

2017-09-19 Thread Khalil Khamlichi
Hi Răzvan,

Thanks for your answer.

I ended up using onreply_route and checking if ($rs == "200") to increment
connect_calls and then event_route[E_ACC_CDR]  to decrement
connected_calls.

multiple local tests are giving expected behavior, will need to test on
production to confirm though.

Thanks a lot for your help.

On Mon, Sep 18, 2017 at 9:47 AM, Răzvan Crainea  wrote:

> Hi, Khalil!
>
> To be honest, I think this event was initially made to be used with the MI
> dlg_end_dlg command, which only terminates a dialog. However, you could run
> 'opensipsctl fifo dlg_list' and match the hash_id and hash_entry against
> the returned values, and then identify the callid.
>
> If you would also like to receive the callid in the event, please open a
> feature request[1].
>
> [1] https://github.com/OpenSIPS/opensips/issues
>
> Best regards,
>
> Răzvan Crainea
> OpenSIPS Developerwww.opensips-solutions.com
>
> On 09/15/2017 10:46 PM, Khalil Khamlichi wrote:
>
> Hi everyone,
>
> I am trying to understand dialog module eventing system.
>
> I have added this route :
>
>
> event_route[E_DLG_STATE_CHANGED] {
>
> fetch_event_params("$avp(a);$avp(b);$avp(c);$avp(d);$avp(e);$avp(f)");
>
> cache_raw_query("redis:0", "PUBLISH serv1 fetch_event_params=$avp(a),$
> avp(b),$avp(c),$avp(d),$avp(e),$avp(f)", "$avp(res)");
>
> }
>
>
> so for each event I can watch an entry
>
> 1505503997.413642 [0 127.0.0.1:39734] "PUBLISH" "serv1"
> "fetch_event_params=3917,339471624,1,3,,"
> 1505503997.524535 [0 127.0.0.1:39762] "PUBLISH" "serv1"
> "fetch_event_params=3917,339471624,3,4,,"
> 1505504018.809746 [0 127.0.0.1:39840] "PUBLISH" "serv1"
> "fetch_event_params=3917,339471624,4,5,,"
>
>
> I understand that
>
> a = hash_id of dialog
> b= hash_entry of dialog
> c = old_state
> d = new_state
> e & f = do not exist and here just to prove that they do not exist.
>
> but I don't understand how to use the information of a & b to track
> dialogs ? if there a function that when fed those parameters gives us
> callid for example ?
>
> Thanks in advance.
>
> Kkh
>
>
>
> ___
> Users mailing 
> listUsers@lists.opensips.orghttp://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] RV: Very Strange Case

2017-09-19 Thread Jorge Luis Ortea

Hi Razvan,


I know this is like a fantastic story, these points have already been proven;

1.- source and destination over 5060 port for all SIP traffic
2.- I don't use Pike
3.- No firewall rules
4.- Selinux is disabled

I am not tracing with Debug but I set xlog just below route{ and onreply_route{
The truth is that I am baffled...

Could it be that Opensips does not detect these messages as SIP type?  Or 
something like that?

Thank you very much.
Regards.



De: Users  en nombre de Răzvan Crainea 

Enviado: martes, 19 de septiembre de 2017 12:35
Para: users@lists.opensips.org
Asunto: Re: [OpenSIPS-Users] RV: Very Strange Case

Hi, Jorge!

If you are saying the 200 OK is not even logged (are you tracing with Debug), 
it means OpenSIPS doesn't see it. I would check:
1. the 200 OK is sent to the proper port
2. Pike is not blocking the reply
3. local firewall does not block the 200 OK
4. selinux is disabled

Best regards,

Răzvan Crainea
OpenSIPS Developer
www.opensips-solutions.com

Home — OpenSIPS Solutions
www.opensips-solutions.com
OpenSIPS is a mature Open Source implementation of a SIP server. OpenSIPS is 
more than a SIP proxy/router as it includes application-level functionalities.


On 09/19/2017 12:14 PM, Jorge Luis Ortea wrote:



Hi all,

I've been using OpenSIPS for a long time and I have never seen anything like it.

The schema is very simple, OpenSIPS exchanges SIP traffic between SBC and 
Asterisk PBX, during a fax call in response a REINVITE packet a 200 Ok is 
ignore by OpenSIPS, not even writes in log, as if this packet did not exist. 
OpenSIPS always ignores the same SIP packet and its retries.

The sniffer on the Opensips interfaces shows that the packets are arriving 
correctly.

Network diagram:
http://picpaste.com/Schema_OpenSIPS_201709191048-0byZJrw9.jpg

Traffic capture:
http://picpaste.com/Missing_200_OK_201709191101-Vy9ir5tT.jpg

Does anyone think it might be happening?

Very Thanks.
Regards.





___
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] RV: Very Strange Case

2017-09-19 Thread Răzvan Crainea

Hi, Jorge!

If you are saying the 200 OK is not even logged (are you tracing with 
Debug), it means OpenSIPS doesn't see it. I would check:

1. the 200 OK is sent to the proper port
2. Pike is not blocking the reply
3. local firewall does not block the 200 OK
4. selinux is disabled

Best regards,

Răzvan Crainea
OpenSIPS Developer
www.opensips-solutions.com

On 09/19/2017 12:14 PM, Jorge Luis Ortea wrote:



Hi all,

I've been using OpenSIPS for a long time and I have never seen 
anything like it.


The schema is very simple, OpenSIPS exchanges SIP traffic between SBC 
and Asterisk PBX, during a fax call in response a REINVITE packet a 
200 Ok is ignore by OpenSIPS, not even writes in log, as if this 
packet did not exist. OpenSIPS always ignores the same SIP packet and 
its retries.


The sniffer on the Opensips interfaces shows that the packets are 
arriving correctly.


Network diagram:
http://picpaste.com/Schema_OpenSIPS_201709191048-0byZJrw9.jpg

Traffic capture:
http://picpaste.com/Missing_200_OK_201709191101-Vy9ir5tT.jpg

Does anyone think it might be happening?

Very Thanks.
Regards.




___
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] RV: Very Strange Case

2017-09-19 Thread Jorge Luis Ortea


Hi all,

I've been using OpenSIPS for a long time and I have never seen anything like it.

The schema is very simple, OpenSIPS exchanges SIP traffic between SBC and 
Asterisk PBX, during a fax call in response a REINVITE packet a 200 Ok is 
ignore by OpenSIPS, not even writes in log, as if this packet did not exist. 
OpenSIPS always ignores the same SIP packet and its retries.

The sniffer on the Opensips interfaces shows that the packets are arriving 
correctly.

Network diagram:
http://picpaste.com/Schema_OpenSIPS_201709191048-0byZJrw9.jpg

Traffic capture:
http://picpaste.com/Missing_200_OK_201709191101-Vy9ir5tT.jpg


Does anyone think it might be happening?

Very Thanks.
Regards.


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