As noted the Risport API (and underlying service) does not have info on the device pool of the devices and you can't query that way directly. What you can do is use the AXL API to query for a list of all device names belonging to a particular device pool, then use Risport <selectCmDevice> providing all of the individual device names (up to 1000 in each request). For example, this AXL <executeSqlQuery> request will return the device names of all devices (and note, not just 'phones' but including gateways and other esoteric device) for the 'Default' device pool: <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns="http://www.cisco.com/AXL/API/11.5"> <soapenv:Header/> <soapenv:Body> <ns:executeSQLQuery sequence="1"> <sql>select device.name from device, devicepool where device.fkdevicepool = devicepool.pkid and devicepool.name = "Default" </sql> </ns:executeSQLQuery> </soapenv:Body> </soapenv:Envelope> Example of a <selectCmDevice> request using multiple names: <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:soap="http://schemas.cisco.com/ast/soap"> <soapenv:Header/> <soapenv:Body> <soap:selectCmDevice> <soap:StateInfo/> <soap:CmSelectionCriteria> <soap:MaxReturnedDevices>80</soap:MaxReturnedDevices> <soap:DeviceClass>Phone</soap:DeviceClass> <soap:Model>255</soap:Model> <soap:Status>Any</soap:Status> <soap:NodeName></soap:NodeName> <soap:SelectBy>Name</soap:SelectBy> <soap:SelectItems> <soap:item><soap:Item>SEP000000000001</soap:Item></soap:item> <soap:item><soap:Item>SEP000000000002</soap:Item></soap:item> </soap:SelectItems> <soap:Protocol>Any</soap:Protocol> <soap:DownloadStatus>Any</soap:DownloadStatus> </soap:CmSelectionCriteria> </soap:selectCmDevice> </soapenv:Body> </soapenv:Envelope> ... View more

Check <getUser> field <status>: https://pubhub.devnetcloud.com/media/axl-schema-reference/docs/Files/AXLSoap_getUser.html#Link782 ... View more

https://developer.cisco.com/site/jtapi/documents/cisco-unified-jtapi-supported-jvm-versions/   It appears that the Amazon Linux AMI is (or was at some point) based on CentOS, so having JTAPI formally supported for RHEL is good, though not an exact match.    Similarly, JTAPI testing appears to be with Java 1.7, so 1.8 'should work', but is not officially supported.  If you can run the process that interacts with JTAPI in a 1.7 JVM that would be the best for compatibility/supportability.   So, if you're looking for a perfect blessing, unfortunately AWS docker/Java8 seems to be off the mark.  The ultimate risk is that the non-standard platform introduces some kind of issue - and if DevNet support/JTAPI engineering determines the issue is with the non-standard platform, they may not be able to pursue troubleshooting/fixing.   However, the likelihood that things work fine is very high IMHO, as the platform is very similar to the tested/supported versions, and JTAPI seems to be quite 'pure' Java-wise.  Certainly careful testing/validation on your part can help ensure things work smoothly.   ... View more

Ah...that explains it :)   The error suggests the device doesn't exist...of course I'm assuming that it does...   You might try the request while removing the optional elements, e.g. <uuid>.  You want to provide either the <name> or the <uuid> not both - possibly the implementation sees both and is using <uuid>?</uuid> and ignoring <name>. ... View more

The Jabber SDK is designed to abstract all the audio/video handling - there is no programmatic access to the audio/video streams by a SDK application.   You might be able to accomplish what you want by implementing a virtual 'CTI Port' device, which does specifically allow/require an application to handle the incoming/outgoing media.  CTI Ports are instantiated/controlled using the TAPI or JTAPI CTI interfaces: https://developer.cisco.com/site/jtapi/ https://developer.cisco.com/site/tapi/ ... View more

Certainly the device name you are supplying is not a real one: <name>SEPXXXXXXXXXXXX</name> The actual device name would be SEP+device MAC address, typically.  Note sure why the XXXs are present...if you're trying to do a wildcard type search or list, that is not possible via <getPhone>, which is used only to retrieve a specific device details. ... View more

This article does a pretty good job of describing CUCM DB replication, and covers which configs are pub->sub vs. full-mesh replicated: http://www.ciscopress.com/articles/article.asp?p=2743756&seqNum=8     ... View more

The general approach would be to use the embedded HTML message capability of Jabber bots.  As you suggest, the image would be hosted on an web server and used in an <img> tag or href in the <html> element of a Jabber message stanza.   This learning lab covers most of the concepts, though doesn't have an example specifically of images: https://developer.cisco.com/learning/lab/jabber-botkit-lab/step/1 ... View more

Your original <listPhone> request works fine for me on my 10.5 system.  My suspicion might be that you are perhaps not querying the right system, or a new system without any phones configured...maybe a node replication issue?  if that's not the case, then it would seem something quite weird is wrong with AXL on your CUCM, and you may want to open a DevNet ticket for more in-depth troubleshooting: https://developer.cisco.com/site/support/ ... View more

I did manage to get this working on my CUCM 11.5 lab system...it was extremely tricky deciphering the AXL schema, element XSD types, XSI types and how all that gets interpreted and mapped into the JAX-WS object model.  (Still not convinced the WSDL code generation/native library route is the best one for AXL...i.e. vs. simple string replacement.  It certainly is inefficient, though probably more deterministic...)   I created a sample VS Code project available here, hopefully to collect future samples (feel free to contribute:) https://github.com/CiscoDevNet/axl-java-samples ... View more

No configuration is needed on the CUCM side.  The core steps you need to implement in code are in the 'Media Termination at Route Point' section, one of several sections mentioned previously that may help you understand what to do.  Once the CTIRP has been correctly registered with media, and the RTP media events have been properly responded to, TerminalConnection.answer() should just work as expected. Media Termination at Route Point This feature enables multiple active calls at the route point, and applications can terminate media for all active calls by specifying the IP address and port number for each call or whenever media is established. To use this feature, applications must register the route point by supplying media capabilities. When a call gets answered at this route point, CiscoMediaOpenLogicalChannelEv gets sent to the applications. This event gets sent whenever media is established. Applications must react to this event and specify the IP address and port number where they want to terminate media. A CiscoRouteTerminal represents a special kind of CiscoTerminal that allows applications to terminate RTP media streams. Unlike a CiscoTerminal, a CiscoRouteTerminal does not represent a physical telephony endpoint, which is observable and controllable in a third-party manner. Instead, a CiscoRouteTerminal represents a logical telephony endpoint, which may get associated with any application that intends to route calls and also terminate media. Unlike CiscoMediaTerminal, CiscoRouteTerminal can have multiple active calls at the same time. Typically, CiscoRouteTerminals get used to place calls in queue until an agent is available to service the caller. Note: Only RoutePoint Terminals appear as CiscoRouteTerminal through JTAPI. Terminating media comprises a three-step process: The application registers its media capabilities with this terminal by using the CiscoRouteTerminal.register method. An application adds an observer that implements CiscoTerminalObserver interface by using the Terminal.addObserver method. The application must add addCallObserver on CiscoRouteTerminal or on CiscoRouteAddress to receive CiscoCall object from the provider by using CiscoRTPHandle. Applications receive CiscoMediaOpenLogicalChannelEv for each call and must supply the IP address and port number by using the setRTPParams method on CiscoRouteTerminal. You must modify applications that are written for the CiscoJtapiClient 1.4(x) release or earlier to register with CiscoRouteTerminal. NO_MEDIA_TERMINATION if the applications are not interested in media termination. Multiple applications can register with the same route point as long as they are registered with the same media capabilities and registrationType. All applications, if they have registered with CiscoRouteTerminal.DYNAMIC_MEDIA_REGISTRATION and then add a terminal observer, receive CiscoMediaOpenLogicalChannelEv, but only one application can invoke setRTPParams. Note: Applications that terminate media must use the CallControl package for answering and redirecting calls. Applications that only route calls can use a routing package. ... View more

Let me see if I understand the problem:   * You need to differentiate between mobile calls and land line calls, presumably so you can route them via different service providers/trunks, block them, bill them differently, etc.  Previously you used Route Patterns for this. * Prior to Aug 3, outbound calls to mobiles are prefixed with 044 or 045, and outbound calls to land lines were prefixed with 01.  This makes them easy to differentiate. * After Aug 3, outbound calls to mobile and land lines will both have the same basic format, i.e. 10 digits starting with the area code.  This makes them difficult to differentiate. * Some kind of government provided database will be made available that identifies all mobile phone numbers/ranges   If I'm mostly right, some thoughts/questions:   * How many entries are in this database?  If the number is in the hundreds to a few thousands, it may be possible to just create/maintain a bunch of translation/route patterns - which could be automated using the CUCM AXL SOAP API.  My understanding is that the max number of patterns is constrained by the CUCM performance profile based on the underlying server hardware, and that you can use the CUCM sizing tools to validate a particular configuration (total devices, lines, patterns, etc.) * If the number is too large to use patterns, then you need to consider coding an application that will examine every outbound call, do a dynamic database lookup to check if its mobile, then route the call to the appropriate destination.  There are two APIs that might be suitable here: CURRI and TAPI / JTAPI (CURRI is probably the more approachable one.)       ... View more