Hi Marcello,
That means sequential requests (event 8) in early state (state 2) - the
dialog support in 1.6.2 does not support that. Anyhow, the log is
harmless - it is a notice, not doing anything.
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
Hi to all,
i have a lot of Dialog Module and Bogus Event 8 in state 2 in opensips logs.
I have opensips 1.6.4 and i see from the sip traces that the request causing
the problem is an UPDATE made from the client (Cisco) during the early state of
the call (it is still ringing).
Can I ignore them or
Sven,
thanks for the feedback - I uploaded the patch on SVN.
Best regards,
Bogdan
Sven Schulz wrote:
Thanks Bogden,
The patch did work. No more bogus events from the same type of call. Im
using 1.6.3 SVN 7291.
Sven
On 1/18/11 9:33 AM, "Bogdan-Andrei Iancu" wrote:
Hi Sven,
The messag
Thanks Bogden,
The patch did work. No more bogus events from the same type of call. Im
using 1.6.3 SVN 7291.
Sven
On 1/18/11 9:33 AM, "Bogdan-Andrei Iancu" wrote:
> Hi Sven,
>
> The message generating the log is:
>
> NOTIFY sip:10.1.2.52:5060 SIP/2.0
> Via: SIP/2.0/UDP 10.1.
Hi Sven,
The message generating the log is:
NOTIFY sip:10.1.2.52:5060 SIP/2.0
Via: SIP/2.0/UDP 10.1.1.60:5060;branch=z9hG4bKFD1B90
From:
;tag=3890-C16
To:
;tag=d5edda48-9c10-424c-b200-8ec1eb8e532c-42505206
Call-ID: f39a000-d30152a9-59-3402010a@10.1.2.52
Bogdan, I hope this capture gets formatted correctly when I paste it in.
Apparently Cisco uses NOTIFY to negotiate DTMF-relay. Inside the initial
INVITE is a "Allow-Events: kpml" which the receiving gateway interprets this
as an out-of-band dtmf capability. Then immediately after the 183, you can
Hi Sven,
Interesting, never saw a NOTIFY in early state of a dialog...can you
post a SIP capture for such a dialog ?
Going back to your question, the message said that the notify event does
not fit to the current dialog state, but this has no effect on the
dialog state, neither on the routin
Directly after the 183 Ringing is a NOTIFY message coming from the
destination (which is a Cisco Sip gateway). The source sends a corresponding
200 OK to this NOTIFY (also a cisco PBX).
So is the "bogus event" something I should be concerned with or is it more
of an informational error message?
0
Hi Sven,
"Bogus Event 8 in state 2" is translated to receiving an indialog
request (non ACK, non BYE) while dialog in early state.maybe it is a
PRACK to the 183can you check that ?
Regards,
Bogdan
Sven Schulz wrote:
Running opensips 1.6.3, dialog module seems to function correctly
h
Running opensips 1.6.3, dialog module seems to function correctly however I
keep getting these messages:
CRITICAL:dialog:log_next_state_dlg: bogus event 8 in state 2 for dlg
0x2b33956052c0 [2284:61359203] with clid
'11a0bd80-d2c160b0-1a-34020...@10.1.2.52' and tags
'd5edda48-9c10-424c-b200-8ec1eb8
10 matches
Mail list logo
