no events when monitoring

[royce3]

I've upgraded to the latest 64-bit version ( 2011-4.2.1.4025 ) and I'm still having trouble.

 

The login I'm using ( 5020 ) has * for the following settings "Watch the calls of the following extensions (* for all):", "Watch the presence of the following extensions (* for all):", and "Watch the following accounts on PAC or WAC:"

 

I'm successfully getting a session id ( for example "vgxre0tv373ak6xcfnoq" ) from my StartApplicationSession, and I'm getting crossref id's from MonitorStart ( for example "22442" ).

 

However, I'm never getting any events.

 

I have logging at level 9 and I'm logging all events ( except for SIP REGISTER and SIP SUBSCRIBE/NOTIFY ).

 

Here are some relevant snippets from logging:

 

[8] 2011/07/20 12:25:37: CSTA: StartApplicaitonSession Request from 5020@pbx.localhost, App id=Project1, invoke id=l ve, timeout=180

[8] 2011/07/20 12:25:37: Adding device 73@127.0.0.1 with xref id 48596

[8] 2011/07/20 12:25:37: Adding device 5020@127.0.0.1 with xref id 36339

[8] 2011/07/20 12:25:37: Adding device 5021@127.0.0.1 with xref id 13267

 

Complete Log attached here: snomone-logfile.txt

or in pastebin here: (pastebin)

 

I never get another "CSTA:" in the log, or can see any indication of why it's not sending me events.

 

Here's an example of how I'm forming the StartMonitor packet ( I'm passing the actualProtocolVersion from the StartApplication as the xmlns, though using "ed3" doesn't seem to make a difference ):

 

<?xml version="1.0" encoding="UTF-8"><MonitorStart xmlns="http://www.ecma-international.org/standards/ecma-323/csta/ed4" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><monitorObject><deviceObject>73@127.0.0.1</deviceObject></monitorObject><monitorType>device</monitorType><requestedMonitorMediaClass><voice>true</voice><im>true</im></requestedMonitorMediaClass><requestedMonitorFilter><callcontrol><connectionCleared>true</connectionCleared><delivered>true</delivered><diverted>true</diverted><established>true</established><failed>true</failed><held>true</held><netwReached>true</netwReached><retrieved>true</retrieved><serviceInitiated>true</serviceInitiated><transferred>true</transferred></callcontrol></requestedMonitorFilter></MonitorStart>

 

Is it possible that events are only supported from SNOM devices ( I'm using a 3rd-party soft-phone for testing )?

 

Is it possible that the system is having trouble with 4-digit extensions?

[pbx support]

Are these extensions registered? I could be that without registrations, snomONE may not trigger the notification. We will check that part out.

[royce3]

Are these extensions registered? I could be that without registrations, snomONE may not trigger the notification. We will check that part out.

 

I just did a test call between two registered 3rd-party extensions, 5021 and 5024. The call was answered, we talked for a few seconds and hung up.

 

My CSTA connection registered a monitor for BOTH of those extensions prior to the call, and I'm still not getting any events.

 

As another test I registered a monitor against one extension only ( the receiving party ) and still no joy. The firewall is disabled on both the box running snomone and the box initiating the csta connection.

[pbx support]

Once the devices are added to the monitoring, then you should get the notifications. Only thing I am suspecting is that I saw 5021@127.0.0.1 & 5021@pbx.localhost in the log file. If for some reason, PBX it trying to compare these 2, they will fail and you won't get notification. So, what you can do is to add the device as 5021@pbx.localhost and see if that takes care of the issue.

[royce3]

Once the devices are added to the monitoring, then you should get the notifications. Only thing I am suspecting is that I saw 5021@127.0.0.1 & 5021@pbx.localhost in the log file. If for some reason, PBX it trying to compare these 2, they will fail and you won't get notification. So, what you can do is to add the device as 5021@pbx.localhost and see if that takes care of the issue.

 

Success!

 

I will share here everything else I found in case there's a bug or that it helps someone else struggling with this:

 

So, I made the change to monitor 5021@pbx.localhost instead of 5021@127.0.0.1, and at that point I started getting logging of CSTA events. ( I don't know why it wasn't logging it before, and that change doesn't seem like it would be likely to cause events to start logging )

 

Analyzing the events I was finally getting in the logfile I was found this: "CSTA: Invalid or no session to send event �9999".

 

I did some more playing and testing, and what I found is this:

 

Even though 5020 has the right to monitor everyone else and is a domain admin, that apparently doesn't translate to the ability to monitor other extensions via CSTA.

 

In order to receive events about 5024, I had to initiate my session with 5024's credentials, which probably means I can only expect to receive events about a single extension for each tcp connection.

 

I'm now happily receiving events. I hope these notes help.

 

Thanks!

 

P.S. I think it would be logical to allow a domain login to CSTA-monitor (w/o control) any extension - for something like a real-time status screen that doesn't require constant polling.

[royce3]

I ran into another problem with not getting events. Doing CSTA causes you to bump up hard against the defaults under access control, so your ip gets banned, which invalidates your session and you don't get any events.

 

I had to set my auto-ban settings much higher than the defaults to prevent this from happening frequently.

[pbx support]

P.S. I think it would be logical to allow a domain login to CSTA-monitor (w/o control) any extension - for something like a real-time status screen that doesn't require constant polling.

 

If your application is something that you can share with us for testing purposes, please PM to us. That way, we can ask the engineering group to figure out what the issue is.

[pbx support]

Even though 5020 has the right to monitor everyone else and is a domain admin, that apparently doesn't translate to the ability to monitor other extensions via CSTA.

 

In order to receive events about 5024, I had to initiate my session with 5024's credentials, which probably means I can only expect to receive events about a single extension for each tcp connection.

 

Missed this point in the previous response -

I don't this it is true. If 5020 has permission to monitor other extensions, you can initiate a MonitorStart on every extension on the same session/connection. This should send back all events on that session.

[royce3]

Missed this point in the previous response -

I don't this it is true. If 5020 has permission to monitor other extensions, you can initiate a MonitorStart on every extension on the same session/connection. This should send back all events on that session.

 

I'll do some more testing on that, I might have experienced a conflict with what I'm reporting below, which is solid:

 

In the meantime, I'm having a bit of trouble with the soap trusted ip setting.

 

I tested over and over again, and here is what I've found:

 

this doesn't work: 127.0.0.1

but this does: 127.0.0.1,

 

it appears you require a comma to follow an entry when it should only act as a separator.

 

Also, the following don't work, and I think at least one of them should (I'm thinking one of the ones with asterisks would be more consistent with the rest of your interface):

 

192.168.*,

192.168.*.*,

192.168.0.1-192.168.255.254,

192.168.0.0/16,

 

P.S. just a reminder I'm running 2011-4.2.1.4025 (Win64)

 

edit: P.P.S. can we please get an actual error if the switch is not going to bother sending us events.... please???

 

edit: P.P.P.S.: this doesn't work either: 192.168.0.*,

[Vodia PBX]

These are valid examples for the SOAP trusted IP addresses:

 

127.0.0.1
192.168.10.0/24
192.168.10.0/24 10.0.0.0/8 127.0.0.1

 

You might also want to white-list those addresses, so the PBX does not automatically black-list them if it gets "suspicious".

[royce3]

These are valid examples for the SOAP trusted IP addresses:

 

127.0.0.1
192.168.10.0/24
192.168.10.0/24 10.0.0.0/8 127.0.0.1

 

You might also want to white-list those addresses, so the PBX does not automatically black-list them if it gets "suspicious".

 

I don't know what the problem is, and this is driving me crazy.

 

My access list has the following whitelist:

 

192.168.0.0/16 Allow

127.0.0.1/32 Allow

 

I did a whole bunch more testing this morning, and I don't have a clue what the problem is. Sometimes a setting works, sometimes it doesn't. Sometimes restarting the service works, sometimes it doesn't. Sometimes I see errors about no valid registration in the snom logs, sometimes not.

 

For example, I had "Soap Trusted Ip" set to 192.168.0.99, the ip where snomone and the csta monitor are both currently running and I was getting packets. I changed the setting to 127.0.0.1, changed the csta monitor app to the same (127.0.0.1) and restarted the csta monitor and now I'm getting "ConnectionClearedEvent", but I'm not getting "DeliveredEvent" (those are the only two events I'm listening for right now). I restarted the service and still getting the same.

 

My test app is in vb6 and has some dependencies. I'm going to rewrite it in python with no dependencies so that I can share it with you guys

[Vodia PBX]

If you are using Windows, you should also definitevely check the personal firewall settings and make sure that the OS does not perform any magic. Also, I would recommend that you (if you are developing) install something like Wireshark to get a true picture on what is going on on the network layer.

[royce3]

If you are using Windows, you should also definitevely check the personal firewall settings and make sure that the OS does not perform any magic. Also, I would recommend that you (if you are developing) install something like Wireshark to get a true picture on what is going on on the network layer.

 

snomone is running on 192.168.0.99, firewall is disabled ( I confirmed this )

 

cti app is running from 192.168.0.31 ( can't capture packets on 127.0.0.1 interface )

 

trusted ip setting is "127.0.0.1 192.168.0.31"

access setting is allow "127.0.0.1/32" and "192.168.0.0/16"

domain is "roy-mac" and aliases are "127.0.0.1", "192.168.0.99", "192.168.1.99", and "localhost"

 

cti app sends login, gets positive reply, sends monitor request, gets positive reply. never gets monitor events.

 

wireshark capture reports the same thing. Shows the login and it's reply as well as the monitor request and it's reply. never shows any events being sent.

 

Here is the python code for review ( it wouldn't let me attach a .py file ): http://pastebin.com/zBSnFnZZ

 

here is snom's log:

 

[8] 2011/07/25 14:27:59: CSTA: StartApplicaitonSession Request from 5024@roy-mac, App id=CstaXmlNoSoap_SnomOne, invoke id=l ve, timeout=180

[8] 2011/07/25 14:27:59: Adding device 5024@roy-mac with xref id 15087

[8] 2011/07/25 14:28:09: Could not find a trunk (1 trunks)

[6] 2011/07/25 14:28:09: Sending RTP for lMDFs-PhovQbIDgx4k1Cclg3b3logduX to 192.168.255.4:4006, codec not set yet

[8] 2011/07/25 14:28:09: Call from an user 5020

[8] 2011/07/25 14:28:09: To is <sip:5024@192.168.0.99>, user 1, domain 1

[8] 2011/07/25 14:28:09: To user 5024

[8] 2011/07/25 14:28:09: Call state for call object 13: idle

[8] 2011/07/25 14:28:09: Call state for call object 13: alerting

[8] 2011/07/25 14:28:09: Play audio_moh/noise.wav

[7] 2011/07/25 14:28:09: set_codecs: for lMDFs-PhovQbIDgx4k1Cclg3b3logduX codecs "", codec_preference count 3

[7] 2011/07/25 14:28:09: set_codecs: for 9e4dcab0@pbx codecs "", codec_preference count 3

[8] 2011/07/25 14:28:09: call port 24: state code from 0 to 100

[8] 2011/07/25 14:28:09: call port 23: state code from 0 to 100

[8] 2011/07/25 14:28:18: call port 24: state code from 100 to 486

[8] 2011/07/25 14:28:18: CSTA: leg=25, device=5024@roy-mac, inbound=false, Calling=5020@roy-mac, Called=5024@roy-mac, State=terminated, call id = 9e4dcab0@pbx

[8] 2011/07/25 14:28:59: CSTA: ResetApplicationSessionTimer Request from invoke id=l ve, session id=h2rg0w6hetq0tdtju5xm

 

[pbx support]

First of all you don't need to use the soap trusted ip for CSTA. As long as the IP address is not blocked on the access list you are ok.

StartApplication, monitor device are the 2 key things needed and you seem to have both of them.

 

All the testing we have done here using estos CSTA app worked fine. It is very important make sure the device id monitored is the same as the one represented by the PBX, i.e., 5024@192.168.0.99 is different than 5024@roy-mac. We can add more logging to see if there is some disconnect.

[royce3]

First of all you don't need to use the soap trusted ip for CSTA. As long as the IP address is not blocked on the access list you are ok.

StartApplication, monitor device are the 2 key things needed and you seem to have both of them.

 

All the testing we have done here using estos CSTA app worked fine. It is very important make sure the device id monitored is the same as the one represented by the PBX, i.e., 5024@192.168.0.99 is different than 5024@roy-mac. We can add more logging to see if there is some disconnect.

 

Thank you for your continued assistance. It is really appreciated.

 

I have removed all aliases and named the domain "192.168.0.99". I have changed the CSTA app to use "192.168.0.99" for the both the login and the monitor request.

 

I have made sure both UA's are registering to "192.168.0.99"

 

At the moment I am receiving ConnectionClearedEvent when the caller hangs up, but I'm not getting DeliveredEvent ( not currently testing EstablishedEvent so I'm not sure about that one )

 

Fixed a small bug in the Python code, here's the update: http://pastebin.com/09zH6wXL

[pbx support]

Ok, I looked at the python code. The issue is that the device being monitored does not match the "From" or "To" headers on the PBX. (Well, PBX could reject during the MonitorStart itself. That happens if the 'localhost' is removed from the PBX aliases. That is another topic for another day!)

 

One easy fix is to change the python code to take another argument for the domain parameter (something like, [hostname:]port user password domain). Then change the "cti.connect(...)" to "cti.connect( host, port, username, password, domainname, cb)".

 

With this change, you can basically pass the same domain name as the parameter (ex: pbx.company.com) to your python program.

 

FYI.. I locally modified your script here, but I saw some exception when the DeliveredEvent was received at the scritp.

[royce3]

I removed all aliases, including localhost, but since you say that could be a problem, I put localhost back in as an alias.

 

I made the changes you requested, accepting a domain parameter on the command-line. Since the "Primary Name" of my domain is 192.168.0.99, here's the command-line I'm now using to test:

 

[edit - pastebin didn't take]

 

python CstaXmlNoSoap_SnomOne.py 192.168.0.99:80 5024@192.168.0.99 5024

 

And here's the updated python code: http://pastebin.com/vB0m3s5N

 

I thought maybe I had found the problem. Basically, this whole time I've been running the softphone from the same machine that snomone is running. Even though the softphone was configured to register to the 192.168.0.99 address, snomone is receiving it as coming from localhost. Making this all the more confusing is that the CSTA events in the log did not show 5024@127.0.0.1, but show 5024@192.168.0.99. Only when I noticed the actual phone registration did I see the 127.0.0.1.

 

However, I now have a separate sip device at 192.168.2.24 registering as 5024@192.168.0.99, and I'm still not getting any events

 

I dialed from 5020 which is coming from my iphone (192.168.255.24) to 5024, and I can hear 5024 ringing with the phone call.

 

The only thing I still had running on the snomone machine was the csta app, so I copied the script to 192.168.0.31 and ran it from there. still no joy.

 

[8] 2011/07/26 17:02:08: CSTA: StartApplicaitonSession Request from 5024@192.168.0.99, App id=CstaXmlNoSoap_SnomOne, invoke id=l ve, timeout=180

[8] 2011/07/26 17:02:08: Adding device 5024@192.168.0.99 with xref id 54274

[8] 2011/07/26 17:02:13: Could not find a trunk (1 trunks)

[6] 2011/07/26 17:02:13: Sending RTP for As7uQcl8iqUR7Nr7vdnlZas31aOx72UA to 192.168.255.24:4006, codec not set yet

[8] 2011/07/26 17:02:13: Call from an user 5020

[8] 2011/07/26 17:02:13: To is <sip:5024@192.168.0.99>, user 1, domain 1

[8] 2011/07/26 17:02:13: To user 5024

[8] 2011/07/26 17:02:13: Call state for call object 4: idle

[8] 2011/07/26 17:02:13: Call state for call object 4: alerting

[8] 2011/07/26 17:02:13: Play audio_moh/noise.wav

[7] 2011/07/26 17:02:13: set_codecs: for As7uQcl8iqUR7Nr7vdnlZas31aOx72UA codecs "", codec_preference count 3

[7] 2011/07/26 17:02:13: set_codecs: for d972243c@pbx codecs "", codec_preference count 3

[8] 2011/07/26 17:02:13: call port 7: state code from 0 to 100

[8] 2011/07/26 17:02:13: call port 6: state code from 0 to 100

[8] 2011/07/26 17:02:13: CSTA: leg=8, device=5024@192.168.0.99, inbound=false, Calling=5020@192.168.0.99, Called=5024@192.168.0.99, State=alerting, call id = d972243c@pbx

[5] 2011/07/26 17:02:13: CSTA: Invalid or no session to send event ?9999<?xml version="1.0" encoding="UTF-8" ?><DeliveredEvent xmlns="http://www.ecma-international.org/standards/ecma-323/csta/ed4"><monitorCrossRefID>7796</monitorCrossRefID><connection><callID>d972243c@pbx</callID><deviceID>5024@192.168.0.99</deviceID></connection><alertingDevice><deviceIdentifier>5024@192.168.0.99</deviceIdentifier></alertingDevice><callingDevice><deviceIdentifier>5020@192.168.0.99</deviceIdentifier></callingDevice><calledDevice><deviceIdentifier>5024@192.168.0.99</deviceIdentifier></calledDevice><lastRedirectionDevice><notKnown /></lastRedirectionDevice><localConnectionInfo>alerting</localConnectionInfo><cause>normal</cause></DeliveredEvent>

[8] 2011/07/26 17:02:13: Play audio_en/ringback.wav

[8] 2011/07/26 17:02:13: call port 6: state code from 100 to 183

[6] 2011/07/26 17:02:13: Codec pcmu/8000 is chosen for call id As7uQcl8iqUR7Nr7vdnlZas31aOx72UA

[8] 2011/07/26 17:02:21: call port 7: state code from 100 to 486

[8] 2011/07/26 17:02:21: CSTA: leg=8, device=5024@192.168.0.99, inbound=false, Calling=5020@192.168.0.99, Called=5024@192.168.0.99, State=terminated, call id = d972243c@pbx

[5] 2011/07/26 17:02:21: CSTA: Invalid or no session to send event ?9999<?xml version="1.0" encoding="UTF-8" ?><ConnectionClearedEvent xmlns="http://www.ecma-international.org/standards/ecma-323/csta/ed4"><monitorCrossRefID>7796</monitorCrossRefID><droppedConnection><callID>d972243c@pbx</callID><deviceID>5024@192.168.0.99</deviceID></droppedConnection><releasingDevice><deviceIdentifier>5024@192.168.0.99</deviceIdentifier></releasingDevice><localConnectionInfo>null</localConnectionInfo><cause>normalClearing</cause></ConnectionClearedEvent>

[8] 2011/07/26 17:03:08: CSTA: ResetApplicationSessionTimer Request from invoke id=l ve, session id=iipe02dypirsb9uag3wg

 

P.S. yeah, the script is still work-in-progress, but if I can just get it receiving events again I can fix it.

[pbx support]

Did you restart the PBX after all these changes? Looking at the log I see that there are 2 cross ref ids 7796 & 54274 for the same device.

I was able to see the events delivered to your script when we tested it here.

 

Meanwhile, let us know what OS are you running. Maybe we can send you the latest with some extra logging for you to follow the flow.

[royce3]

Did you restart the PBX after all these changes? Looking at the log I see that there are 2 cross ref ids 7796 & 54274 for the same device.

I was able to see the events delivered to your script when we tested it here.

 

Meanwhile, let us know what OS are you running. Maybe we can send you the latest with some extra logging for you to follow the flow.

 

I restarted the service.

 

I made sure both sip devices were registered

 

I fired up the csta app and noticed I was getting events again.

 

I noticed the exceptions I was getting and found/fixed the bug ( an operator-precedence bug left-over from the conversion to python )

 

Restarted the csta app and I'm not getting events any more (again)

 

So, I restarted the service again.

 

I reregisted the sip devices again

 

I restarted the csta app, and I'm getting events again, noticing another bug in the csta app...

 

This time I was able to restart the csta app about 3 times before I stopped getting events again.

 

I'm not going to post a code update this time because I'm having a definite problem with buffer lengths matching the actual length of xml being sent, but I want to be 100% certain the bug is not in my code.

 

I'm running Windows 7 Home Premium 64-bit. A version with extra logging would be pretty sweet, please.

[pbx support]

http://pbxnsip.com/snomone/beta/win64/pbxctrl-2011-4.3.0.5002.exe is the updated version.

[royce3]

http://pbxnsip.com/snomone/beta/win64/pbxctrl-2011-4.3.0.5002.exe is the updated version.

 

here's the full log file after installing that version and testing: http://pastebin.com/bnKkFGKW

 

I have pasted in a selection from the log file below. I got events until the last restart+phone call listed here. Is there any particular setting I need to apply to see extra logging, because I didn't notice anything extra in this log, sorry.

 

[1] 2011/07/27 13:41:37:	Starting up version 2011-4.3.0.5002
[8] 2011/07/27 13:43:18:	CSTA: StartApplicaitonSession Request from 5020@192.168.0.99, App id=CstaXmlNoSoap_SnomOne, invoke id=l ve, timeout=180
[8] 2011/07/27 13:43:18:	Adding device 5020@192.168.0.99 with xref id 43461

[8] 2011/07/27 13:43:26:	Call from an user 5020
[8] 2011/07/27 13:43:26:	To user 5024
[8] 2011/07/27 13:43:26:	CSTA: leg=3, device=5020@192.168.0.99, inbound=true, Calling=5020@192.168.0.99, Called=5024@192.168.0.99, State=ringback, call id = 2oObJTLk0aEKEgu9ZOfe5Za4ald64vO9
[8] 2011/07/27 13:43:29:	CSTA: leg=3, device=5020@192.168.0.99, inbound=true, Calling=5020@192.168.0.99, Called=5024@192.168.0.99, State=terminated, call id = 2oObJTLk0aEKEgu9ZOfe5Za4ald64vO9

 

^^^ I got these events

 

[8] 2011/07/27 13:44:18:	CSTA: ResetApplicationSessionTimer Request from invoke id=l ve, session id=w4fxk91vtxpgm8pvwhbr

[8] 2011/07/27 13:44:47:	Call from an user 5020
[8] 2011/07/27 13:44:47:	To user 5024
[8] 2011/07/27 13:44:47:	CSTA: leg=5, device=5020@192.168.0.99, inbound=true, Calling=5020@192.168.0.99, Called=5024@192.168.0.99, State=ringback, call id = LA8T0iGpMptNZHX1l.m5ndk8YBdDlm3M
[8] 2011/07/27 13:44:50:	CSTA: leg=5, device=5020@192.168.0.99, inbound=true, Calling=5020@192.168.0.99, Called=5024@192.168.0.99, State=terminated, call id = LA8T0iGpMptNZHX1l.m5ndk8YBdDlm3M

 

^^^ I got these events

 

[8] 2011/07/27 13:45:18:	CSTA: ResetApplicationSessionTimer Request from invoke id=l ve, session id=w4fxk91vtxpgm8pvwhbr

[8] 2011/07/27 13:54:28:	CSTA: StartApplicaitonSession Request from 5020@192.168.0.99, App id=CstaXmlNoSoap_SnomOne, invoke id=l ve, timeout=180
[8] 2011/07/27 13:54:28:	Adding device 5020@192.168.0.99 with xref id 33104
[8] 2011/07/27 13:54:34:	CSTA: notifying the REGISTER=true for 5020@192.168.0.99

[8] 2011/07/27 13:54:43:	Call from an user 5020
[8] 2011/07/27 13:54:43:	To user 5024
[8] 2011/07/27 13:54:43:	CSTA: leg=7, device=5020@192.168.0.99, inbound=true, Calling=5020@192.168.0.99, Called=5024@192.168.0.99, State=ringback, call id = nfKC.CwVNwtvJjgOQo-WWcNVWmg5zk1t
[8] 2011/07/27 13:54:45:	CSTA: leg=7, device=5020@192.168.0.99, inbound=true, Calling=5020@192.168.0.99, Called=5024@192.168.0.99, State=terminated, call id = nfKC.CwVNwtvJjgOQo-WWcNVWmg5zk1t

 

^^^ I got these events

 

[8] 2011/07/27 13:54:59:	CSTA: StartApplicaitonSession Request from 5020@192.168.0.99, App id=CstaXmlNoSoap_SnomOne, invoke id=l ve, timeout=180
[8] 2011/07/27 13:54:59:	Adding device 5020@192.168.0.99 with xref id 2203

[8] 2011/07/27 13:55:04:	Call from an user 5020
[8] 2011/07/27 13:55:04:	To user 5024
[8] 2011/07/27 13:55:04:	CSTA: leg=9, device=5020@192.168.0.99, inbound=true, Calling=5020@192.168.0.99, Called=5024@192.168.0.99, State=ringback, call id = 3CUD70h.S.75eJMMhXnysFvqzKQfuTlh
[8] 2011/07/27 13:55:05:	CSTA: leg=9, device=5020@192.168.0.99, inbound=true, Calling=5020@192.168.0.99, Called=5024@192.168.0.99, State=terminated, call id = 3CUD70h.S.75eJMMhXnysFvqzKQfuTlh

 

^^^ I got these events

 

[8] 2011/07/27 13:55:38:	CSTA: StartApplicaitonSession Request from 5020@192.168.0.99, App id=CstaXmlNoSoap_SnomOne, invoke id=l ve, timeout=180
[8] 2011/07/27 13:55:38:	Adding device 5020@192.168.0.99 with xref id 32149

[8] 2011/07/27 13:55:42:	Call from an user 5020
[8] 2011/07/27 13:55:42:	To user 5024
[8] 2011/07/27 13:55:42:	CSTA: leg=11, device=5020@192.168.0.99, inbound=true, Calling=5020@192.168.0.99, Called=5024@192.168.0.99, State=ringback, call id = WS-mUFANNRZnR8MWwzjcQx.HmH5MiB.T
[8] 2011/07/27 13:55:49:	CSTA: leg=11, device=5020@192.168.0.99, inbound=true, Calling=5020@192.168.0.99, Called=5024@192.168.0.99, State=terminated, call id = WS-mUFANNRZnR8MWwzjcQx.HmH5MiB.T

 

^^^ did NOT get these events

 

This is the wireshark filter I'm using to double-check that the events are or aren't being sent:

 

tcp.port==80 and tcp.len>0 and not tcp contains "ResetApplicationSessionTimer"

 

and it matches what I'm seeing in the csta app

 

I double-checked that I'm not getting auto-blocked. my accesslist rule of 192.168.0.0/16 is preventing me from getting banned.

 

[edit]Updated python code, fixed a buffering bug: http://pastebin.com/FFtvJi6g

[royce3]

bump.

 

In summary, it appears that snomone just quits sending events after about 3 reconnects

 

is there any more information you are waiting on for me?

 

are there additional tests you'd like me to run or settings you'd like me to change.

[pbx support]

As long as the session is active, you should get the events. PBX will keep the session active based on the "requestedSessionDuration". But if this duration is more than the NAT TCP timeout (Admin->Settings: TCP/TLS NAT Refresh), then it will take the NAT TCP timeout (basically the lesser of the 2).

 

If you want to keep this session active you have to send the "ResetApplicationSessionTimer" before the session is expired.