socnet Posted August 28, 2013 Report Share Posted August 28, 2013 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 Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted August 28, 2013 Report Share Posted August 28, 2013 Well you could match the from and the to information. But I think because the CSTA concept is linked to the extension device, the call-ID are different. Quote Link to comment Share on other sites More sharing options...
socnet Posted August 29, 2013 Author Report Share Posted August 29, 2013 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? Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted August 29, 2013 Report Share Posted August 29, 2013 We have made some proprietary extensions for CSTA messages, for example to show what type of call an incoming calls is (ACD, hunt, ...). We could do the same thing for the Call-ID. But of course it would be better to have a standard-compliant solution. Quote Link to comment Share on other sites More sharing options...
socnet Posted August 30, 2013 Author Report Share Posted August 30, 2013 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? Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted September 3, 2013 Report Share Posted September 3, 2013 Did take a look into this. Lets say there are two phones registered for sip:123@domain.com and a call comes in. Then one of the phones is supposed to pick up the call. If they both have the same CallID, how can the PBX tell which call leg should be connected?! deviceID will be the same for both legs . If this is supposed to work, we need to change the meaning of deviceID to something related to the registration, not the extension. Quote Link to comment Share on other sites More sharing options...
socnet Posted September 7, 2013 Author Report Share Posted September 7, 2013 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. Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted September 9, 2013 Report Share Posted September 9, 2013 In the SIP world, the UUID would serve perfectly as device identifier. Unfortunately only few devices support this in the registration (snom does). If we would use the UUID as the device identifier and the extension@domain as the default, we could get this working properly for snom devices; other devices might have the limitation to one registration per extension then. Quote Link to comment Share on other sites More sharing options...
socnet Posted September 9, 2013 Author Report Share Posted September 9, 2013 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. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.