cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
199
Views
15
Helpful
3
Replies

Extension mobility API: clearing call history and rate limit.

floatingpurr
Beginner
Beginner

So, I'm trying to build an Extension-mobility-API-based service with a CUCM 11.5 cluster. I have 2 questions:

 

  1. Since I have to deal with ~4k devices with relative login/out events, I need to know if there is any limitation on the number of requests that the Extension mobility API can handle per time unit. I haven't found any reference about it so far.

  2. As per the doc, it looks like there is no way to automatically delete the device call history upon logout. The param "Clear Call Logs on Intra-Cluster EM" seems working just for manual logouts. Is there a way to clear the call history without relying on workarounds with the AXL? It's a pretty common use case, after all.

Thanks!

1 Accepted Solution

Accepted Solutions

dstaudt
Cisco Employee
Cisco Employee

Not aware of any documented rate limits for the API. As under the covers I believe it uses the same mechanism as the phone service, I would expect the scalability/impact to be similar with the basic E/M feature. As always, do test at scale yourself to understand any unexpected performance impacts.

As mentioned, to force clearing of the call log you'll either need to restart the device (i.e. via AXL) or use IP Phone Services to POST an XML command to the phone to clear the call logs.

View solution in original post

3 Replies 3

dstaudt
Cisco Employee
Cisco Employee

Not aware of any documented rate limits for the API. As under the covers I believe it uses the same mechanism as the phone service, I would expect the scalability/impact to be similar with the basic E/M feature. As always, do test at scale yourself to understand any unexpected performance impacts.

As mentioned, to force clearing of the call log you'll either need to restart the device (i.e. via AXL) or use IP Phone Services to POST an XML command to the phone to clear the call logs.

Thanks for your answer. Is there a documented rate limit for the basic E/M? Using the API, I guess that you rely on the basic E/M behind the scenes. Moreover, in that case, there is at least also an Application Server in front on it to process the requests. I'm not sure of the performance of such a component. Yep, testing at scale would be good, but it's hard to set up a testing scenario at scale like mine.

Regarding the reset of call history, It'd have been way more straightforward using the EM API or e global config param. What a bummer!

Thanx @dstaudt!

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Recognize Your Peers