socnet

I am trying to get CSTA working on a hosted SnomOne platform. The session connects ok. For brevity, here is the PBX response: <?xml version="1.0" encoding="UTF-8"?><StartApplicationSessionPosResponse xmlns="http://www.ecma-international.org/standards/ecma-354/appl_session" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><sessionID>df3e4yobdsjfczasheyq</sessionID><actualProtocolVersion>http://www.ecma-international.org/standards/ecma-323/csta/ed4</actualProtocolVersion><actualSessionDuration>60</actualSessionDuration></StartApplicationSessionPosResponse> Also the monitor start works ok: <?xml version="1.0" encoding="UTF-8"?><MonitorStartResponse xmlns="http://www.ecma-international.org/standards/ecma-354/appl_session" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><monitorCrossRefID>428</monitorCrossRefID><actualMonitorMediaClass><voice>true</voice><im>true</im></actualMonitorMediaClass></MonitorStartResponse> But I never get any events when the handset makes calls. I have tried a number of clients, include Snom Browser and the TPAI driver, but none of them get any events. The trace above is actually taken from Wireshark from the TAPI driver. I presume that it must be a PBX configuration issue, but don't know where to start. Please can you give me some pointers? Also of interest, the "ResetApplicationSessionTimer" command is returning errors. Request: <ResetApplicationSessionTimer xmlns="http://www.ecma-international.org/standards/ecma-354/appl_session/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><sessionID>df3e4yobdsjfczasheyq</sessionID><requestedSessionDuration>1800</requestedSessionDuration></ResetApplicationSessionTimer> Response: <?xml version="1.0" encoding="UTF-8"?><CSTAErrorCode xmlns="http://www.ecma-international.org/standards/ecma-323/csta/ed4"><operation>invalidSessionID</operation></CSTAErrorCode> But if the "ResetApplicationSessionTimer" command is not sent, then the session disconnects, so it must be doing something. Also, the Log is showing CSTA information, but I never receive it. For instance: [8] 2014/09/11 14:34:01: CSTA: leg=725186, device=8514@xxxremoved, inbound=true, Calling=8514@xxxremoved, Called=59674566@standardsolar.telegate.net.au, State=ringback, CallID = MTExNTcxOGM0ZjU2NmZlMjkwYWNhMWFkZDMxZDUxMzQ Please can you help me work out what I need to change (on the PBX)?

But would you be able to use the UUID for MonitorStart? If not, then using a different value for MonitorStart (and thus ambiguously monitoring both) would be bad.

Generally it's the combination of device plus call id that is unique, as you suggest. However, most phone systems wouldn't have the problem of "two phones being registered as 123" so the ambiguity that you mention wouldn't normally happen. Even the rare ones that do (ie Toshiba) still create uniqueness from the device side, so for instance you could have: 001234ABCDEF:123 (Mac + Tel) as the device. Changing the device to something more temporary (registration) would be bad. The "device" really needs to be the same as the value that you "monitor" at the start. Too many things would depend on this. If it's ok and if you could have a common value for all legs of the same call, then I think you should add it as a separate "global call id" value. That way you won't break anything. You'll just be adding functionality.

Thanks. So we should look out for 5.2 when available?

I have no problem with proprietary extensions, as long as the data is there. I would be happy to be proven wrong, but I don't think you'll find a "standard-compliant" solution or more specifically that it's widely adopted. The closest you'll get is "convention" and it's "conventional" to use the same Call-ID for all legs of the same call. But if you can't do that, then fine. We (and others) just want to correlate the calls together. Otherwise for a group call (ringing say four extensions) then it looks like at least three of the people will miss (not answer) every call. The only two other PBXs that I can think of that use CSTA over XML (Siemens 8000 and Aastra 400), both use the same Call-ID for all legs (as per above). But some of the others that use CSTA (over ASN1) use "Global Linked Call ID" as another variable. Perhaps this would be easier for you?

Thank you. And I admire your modesty. However, I'm not trying to be a CSTA purist. Just pointing out that the response contains invalid XML. Instead of </</initiatedCall>> it should be </initiatedCall> .

Thank you for the reply. Matching caller / called isn't really going to work for us. We're only really interested in definite matches, not probably. But thank you for the suggestion. Since the PBX must know that the calls have a common source (ie the others stop ringing once one is answered) then is it possible that (in time) you could include a corroborative value in the CSTA packet? Perhaps the internal value which the PBX uses for tracking?

Also, note that we are using v5.1 already. (We experienced some of the "problems"). :-)

Done

Hi. Sorry to resurrect an old thread, but in case it's interested, we can help you with SugarCRM integration or integration to other common CRM packages using desktop software. You can see more information here: http://plus-software.com/plus.php?tab=7&item=21 Or if anyone prefers, you can PM me for more information. Thanks

Using CSTA on a v5.1 Snom One in a hosted environment. When an incoming call rings several devices, there appears no way to associate the multiple legs of the call. The "call ids" are different, for instance. Is there any way to get data that would allow us to know that these are the same call? Thanks

Using CSTA on a v5.1 Snom One in a hosted environment. When we transfer incoming calls (using our handsets) then the original caller's telephone number is not provided in any of the CSTA messages to the new extension. Nor is there any correlating information that allows us to link the new call to the original received call. This is unexpected. Is there a way that we can receive either the original caller information or calculate a link? We tried SnapshotDevice but there was nothing interesting in the response. thanks

Using CSTA on a v5.1 Snom One in a hosted environment. When we receive a simple incoming call to a group of extensions, then information is correct (some information is obscured with xx): IN: <DeliveredEvent xmlns="http://www.ecma-international.org/standards/ecma-323/csta/ed4"><monitorCrossRefID>413</monitorCrossRefID><connection><callID>37ee52d1@pbx</callID><deviceID>2653@domain</deviceID></connection><alertingDevice><deviceIdentifier>6129xxxxxxx@175.x.x.x</deviceIdentifier></alertingDevice><callingDevice><deviceIdentifier>6141xxxxxxx@domain</deviceIdentifier></callingDevice><calledDevice><deviceIdentifier>6129xxxxxxx@175.x.x.x</deviceIdentifier></calledDevice><lastRedirectionDevice><notKnown /></lastRedirectionDevice><localConnectionInfo>alerting</localConnectionInfo><cause>normal</cause><IORef xmlns="">9999</IORef></DeliveredEvent> However, when we answer the call (by lifting the handset) then the "caller" and "called" switch, which is wrong. IN: <EstablishedEvent xmlns="http://www.ecma-international.org/standards/ecma-323/csta/ed4"><monitorCrossRefID>413</monitorCrossRefID><establishedConnection><callID>37ee52d1@pbx</callID><deviceID>2653@domain</deviceID></establishedConnection><answeringDevice><deviceIdentifier>6141xxxxxxx@domain</deviceIdentifier></answeringDevice><callingDevice><deviceIdentifier>6129xxxxxxx@175.x.x.x</deviceIdentifier></callingDevice><calledDevice><deviceIdentifier>6141xxxxxxx@domain</deviceIdentifier></calledDevice><lastRedirectionDevice><notKnown /></lastRedirectionDevice><localConnectionInfo>connected</localConnectionInfo><cause>normal</cause><IORef xmlns="">9999</IORef></EstablishedEvent> This only appears to happen for incoming calls, not outgoing. Hopefully the text above is obivous enough, but I can provide more information if needed.

Using CSTA on a v5.1 Snom One in a hosted environment. When we are using CSTA to do consultation calls we receive a corrupt XML response to the request. The request is: 0032<?xml version='1.0' encoding='UTF-8' standalone='yes'?><ConsultationCall><existingCall><callID>4cdff04b@pbx</callID><deviceID>2654@domain</deviceID></existingCall><consultedDevice>2653</consultedDevice></ConsultationCall> The response is: 0032<?xml version="1.0" encoding="UTF-8"?><ConsultationCallResponse xmlns="http://www.ecma-international.org/standards/ecma-323/csta/ed4"><initiatedCall><callID>52d470a7@pbx</callID><deviceID>2654@domain</deviceID></</initiatedCall>></ConsultationCallResponse> Hopefully the fault is obvious (around "/initiatedCall"). The problem happens consistently. Looks like a straightforward fault. Thanks in advance