Re: [OpenSIPS-Users] log_next_state_dlg: bogus event 8 in state 5

[Alain Bieuzent]

Thanks Liviu,

 

See you in valencia !

 

De : Liviu Chircu 
Date : lundi 8 avril 2024 à 12:23
À : OpenSIPS users mailling list , Alain Bieuzent 

Objet : Re: [OpenSIPS-Users] log_next_state_dlg: bogus event 8 in state 5

 

Hi Alain,

Event 8 stands for DLG_EVENT_REQ in the C code, which means: "mid-dialog 
request".

I would recommend you don't turn off that warning message, because there may be 
several other events (5? 7? etc.) which could reach the same codepath and could 
be useful hints for troubleshooting.  Rather, try to make a monitoring 
exception for the specific "event 8 state 5" warning message in order to avoid 
unwanted alerts.

PS: as far as the function itself goes, there is no way of turning the message 
off, only by raising the log_level -- again, not recommended (warnings are 
useful).

Best regards,
Liviu Chircu
www.twitter.com/liviuchircu | www.opensips-solutions.com
OpenSIPS Summit 2024 Valencia, May 14-17 | www.opensips.org/events
On 05.04.2024 12:46, Alain Bieuzent wrote:

WARNING:dialog:log_next_state_dlg: bogus event 8 in state 5 for dlg

The code works, but I continue to receive these error messages in the logs, how 
can I delete them (without changing the log level)?

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

Re: [OpenSIPS-Users] Packet analysis using wireshark

[Prathibha B]

Thank you.

On Mon, 8 Apr 2024 at 15:44, Liviu Chircu  wrote:

> If you are not able to decode the WebRTC TLS connection in Wireshark, it's
> possible you are dealing with a TLS 1.3 connection.
>
> In TLS 1.3, there is an extra "secrets" file which must be plugged into
> Wireshark before it can decode the communication, which contains transient
> data (per connection!).  It is no longer sufficient to go to Edit ->
> Preferences -> Protocols -> TLS / SSL -> *RSA keys list* and plug in your
> private key.  In that same dialog box, the field *(Pre)-Master-Secret log
> filename* also becomes mandatory.
>
> Now, how to obtain the Master-Secret file?  In Chrome/Firefox as well as
> in cURL, you should find support for the *SSLKEYLOGFILE=* environment
> variable.  Just make sure to set this variable to the desired filepath
> before running the WebRTC client and it *should* dump the secrets there.
> Which will ultimately get picked up by Wireshark and the traffic will
> decode.
>
> Good luck! :)
>
> Liviu Chircuwww.twitter.com/liviuchircu | www.opensips-solutions.com
> OpenSIPS Summit 2024 Valencia, May 14-17 | www.opensips.org/events
>
> On 06.04.2024 17:39, Prathibha B wrote:
>
> I am unable to see the Voip calls in wireshark. For signaling opensips is
> used. The calls are encrypted and it is webrtc communication.
>
>

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

Re: [OpenSIPS-Users] log_next_state_dlg: bogus event 8 in state 5

[Liviu Chircu]

Hi Alain,

Event 8 stands for DLG_EVENT_REQ in the C code, which means: "mid-dialog 
request".


I would recommend you don't turn off that warning message, because there 
may be several other events (5? 7? etc.) which could reach the same 
codepath and could be useful hints for troubleshooting.  Rather, try to 
make a /monitoring exception/ for the specific "event 8 state 5" warning 
message in order to avoid unwanted alerts.


PS: as far as the function itself goes, there is no way of turning the 
message off, only by raising the /log_level/ -- again, not recommended 
(warnings are useful).


Best regards,

Liviu Chircu
www.twitter.com/liviuchircu  |www.opensips-solutions.com
OpenSIPS Summit 2024 Valencia, May 14-17 |www.opensips.org/events

On 05.04.2024 12:46, Alain Bieuzent wrote:


WARNING:dialog:log_next_state_dlg: bogus event 8 in state 5 for dlg

The code works, but I continue to receive these error messages in the 
logs, how can I delete them (without changing the log level)?
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Packet analysis using wireshark

[Liviu Chircu]

If you are not able to decode the WebRTC TLS connection in Wireshark, 
it's possible you are dealing with a TLS 1.3 connection.


In TLS 1.3, there is an extra "secrets" file which must be plugged into 
Wireshark before it can decode the communication, which contains 
transient data (per connection!).  It is no longer sufficient to go to 
Edit -> Preferences -> Protocols -> TLS / SSL -> *RSA keys list* and 
plug in your private key.  In that same dialog box, the field 
*(Pre)-Master-Secret log filename* also becomes mandatory.


Now, how to obtain the Master-Secret file?  In Chrome/Firefox as well as 
in cURL, you should find support for the *SSLKEYLOGFILE=* environment 
variable. Just make sure to set this variable to the desired filepath 
before running the WebRTC client and it /should/ dump the secrets 
there.  Which will ultimately get picked up by Wireshark and the traffic 
will decode.


Good luck! :)

Liviu Chircu
www.twitter.com/liviuchircu  |www.opensips-solutions.com
OpenSIPS Summit 2024 Valencia, May 14-17 |www.opensips.org/events

On 06.04.2024 17:39, Prathibha B wrote:
I am unable to see the Voip calls in wireshark. For signaling opensips 
is used. The calls are encrypted and it is webrtc communication.___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Continously ringing

[Liviu Chircu]

Make a SIP trace with *sngrep *program and check the routing of the 486 
Busy / 603 Decline message sent by phone B.  If A is still in ringing, 
it most likely means the reply isn't reaching it.


It is possible phone A is behind a NAT and its /Via/ SIP header needs a 
small adjustment for the replies to be properly routed back, using this 
useful /opensips.cfg/ function call:


force_rport() 



Liviu Chircu
www.twitter.com/liviuchircu  |www.opensips-solutions.com
OpenSIPS Summit 2024 Valencia, May 14-17 |www.opensips.org/events

On 06.04.2024 17:35, Prathibha B wrote:
User A makes a call to user B. User B didn't accept the call. User B 
stopped ringing after 1 minute. But User A continues to be in the 
ringing state until it is manually canceled.___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users