royce3

I actually need 5 different but related features. I have at least two customers who are looking at buying either SnomOne Blue or SnomOne plus, and might be willing to pay extra to get these features implemented, so I'd like to get an idea if there's a certain amount that could get these features implemented sooner. Feature #1) hot standby mode: A new star code would be created to support this feature. I originally thought of overloading *64, but I think a new star code would be better. This mode of operation REQUIRES a cti controller, because you need a 3rd party source toggling the agent's state. When dialing this new star code, instead of just hanging up the agent's call (like *64 does), the switch keeps the agent connected to a whitenoise source awaiting cti initialization. The agent is now in a state to be able to take logon to an acd device or group, but is not actually joined to any acd, yet. The cti app now logs the agent into a specific acd, or a combination (acd group) as described in ecma-269 6.1.1.6 When the agent is ready to take a call, the cti controller sends csta SetAgentState with a requestedAgentState of requestedAgentStateReady. When the switch assigns a call to an agent, the switch plays a courtesy tone ( or optional whisper ) and connects the call to the agent's already open talk path. If that agent/queue is configured to record the call, then recording begins at that moment. Also a cti event is sent to indicate the agent is connected to a call. It is up to the cti app to reset the agent state back to requestedAgentStateReady to receive each call. When the agent wishes to terminate the call, a normal cti packet is sent that will terminate the call ( or transfer, park, etc ). The server will reconnect the agent to the white noise source. The switch now sends a csta AgentWorkingAfterCallEvent. Feature #2) This is already mentioned above, but I wanted to draw separate attention to it: agents should be able to log into multiple acds simultaneously. Preferrably the cti app should be able to notify the switch what priority each acd has for that agent. For example, the cti app may give acd 70 a high priority and acd 71 a low priority, meaning that if the agent comes available and there are calls in both queues, the high priority queue takes precedence over the low priority one. If priorities are equal, then the caller's waiting time is used to pick the next call. Feature #3) The ability to toggle recording status via cti. (being able to do it via a button on the phone would be nice, too). If the agent is taking credit card information, we don't want to record that. Feature #4) I need call-handling logic separated out of the acd queue. Here's a scenario why that would be important: in the simple example of an answering service, I may have 500 DIDs all ringing into the same queue. I may want to have a customized delay announcement on each DID that says the name of the company while apologizing for the delay. The way snomone is designed, once you hand the call to the queue, all DID-specific customization appears to be lost. So, basically, what I'm asking for with this feature is to basically rename a "queue" to an "incoming route" and add a parameter that indicates which "queue" the call is being put into. That way I can have incoming routes "70" and "71" that both put the call into queue 1, but have different call-handling behavior until the agent picks up the call. Feature #5) This depends on Feature 4 above, the ability to specify an artificial initial "time in queue" to give that a bump in the order the call will be answered. For example, say I answer for several doctor's offices and an emergency room. The emergency room calls should get answered with a higher priority, so I give them a 3 minute artificial initial in-queue time. Say a call comes in to a doctors office and has already been in queue for 2 minutes. Then a call comes into the emergency room. Since the first call is only 2 minutes ahead of the emergency room call, the emergency room call will be the first to be answered. However, if the doctors office call was already in queue for more than 3 minutes, then it still gets answered first.

Okay, I figured out how to do it by putting this in the "To-based routing match list" !.*!73 The question I have left... is this the most efficient way to individually control which acd is the destination for each of the 900 DIDs?

I have a client with 900 DIDs. We are probably going to setup about 5 ACD Queues or so. I have a trunk setup with the following rule in "send call to extension", which sends the call to 4XXXX with XXXX being the last 4 digits of the DID: !([0-9]{4}$)!4\1 Now, what I want to do is setup a single "rule" (edit: a single rule per DID) somewhere that controls which queue to send each DID to, or to just hang up the call if that DID is not currently in service. I tried creating an IVR node with a DTMF match of: !E!73! According to what I read on the forum, I thought this would send all calls ( without any digits input from caller ) directly to agent queue 73, but it's not working. I'm sure I misunderstood how to do that "redirect", but maybe there's a better way to accomplish this? Thanks

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.

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

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.

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.

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

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

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

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.*,

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.

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.

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.

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?