cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
618
Views
0
Helpful
5
Replies

why does listRemoteDestinationProfiles not support the line tag

stephan.steiner
Spotlight
Spotlight

All other list operations I've worked with so far that deal with something that can hold lines support it.. why not the remoteDestinationProfile? Seems odd that you need to do SQL to get this done for remote destination profiles.

5 Replies 5

npetrele
Cisco Employee
Cisco Employee

Good question.  Checking.

it's the same for listDeviceProfiles by the way.. just had to rewrite that using sql as well since I need this information for the task I currently have.

I'd argue it makes sense for it to be supported for all objects that have a lines element.. after all, database wise, they all work the same (with device, devicenumplanmap and numplan tables).

@edit: hmm.. and the same for listPhone. But there with a twist.. there the searchCriteria is actually checked against the allowed values.

I'm sending

<searchCriteria><name>%</name></searchCriteria><returnedTags><name/><product/><locationName/><lines><line><index/><label/><display/><dirn/><associatedEndusers><enduser><userid/></enduser></associatedEndusers></line></lines><callingSearchSpaceName/><userLocale/><devicePoolName/><ownerUserName/></returnedTags>

and the response error is

Unmarshalling Error: unexpected element (uri:"", local:"lines"). Expected elements are <{}loginTime>,<{}dialRulesName>,<{}keySize>,<{}cgpnTransformationCssName>,<{}requireDtmfReception>,<{}numberOfButtons>,<{}locationName>,<{}deviceTrustMode>,<{}traceFlag>,<{}rerouteCallingSearchSpaceName>,<{}hlogStatus>,<{}authenticationMode>,<{}remoteDevice>,<{}certificateStatus>,<{}digestUser>,<{}sendGeoLocation>,<{}callingSearchSpaceName>,<{}proxyServerUrl>,<{}allowiXApplicableMedia>,<{}alwaysUsePrimeLine>,<{}confidentialAccess>,<{}userHoldMohAudioSourceId>,<{}phoneSuite>,<{}isActive>,<{}mlppIndicationStatus>,<{}networkHoldMohAudioSourceId>,<{}loginDuration>,<{}devicePoolName>,<{}idleTimeout>,<{}mtpPreferedCodec>,<{}subscribeCallingSearchSpaceName>,<{}mediaResourceListName>,<{}homeNetworkId>,<{}packetCaptureMode>,<{}automatedAlternateRoutingCssName>,<{}defaultProfileName>,<{}secureMessageUrl>,<{}callInfoPrivacyStatus>,<{}softkeyTemplateName>,<{}isDualMode>,<{}protocolSide>,<{}rfc2833Disabled>,<{}packetCaptureDuration>,<{}ringSettingBusyBlfAudibleAlert>,<{}commonPhoneConfigName>,<{}blockIncomingCallsWhenRoaming>,<{}geoLocationFilterName>,<{}unattendedPort>,<{}presenceGroupName>,<{}alwaysUsePrimeLineForVoiceMessage>,<{}idleUrl>,<{}primaryPhoneName>,<{}certificateOperation>,<{}preemption>,<{}product>,<{}retryVideoCallAsAudio>,<{}commonDeviceConfigName>,<{}dndRingSetting>,<{}servicesUrl>,<{}currentConfig>,<{}singleButtonBarge>,<{}allowCtiControlFlag>,<{}hotlineDevice>,<{}builtInBridgeStatus>,<{}mtpRequired>,<{}userLocale>,<{}loadInformation>,<{}dndStatus>,<{}enableCallRoutingToRdWhenNoneIsActive>,<{}mobilityUserIdName>,<{}roamingDevicePoolName>,<{}description>,<{}useTrustedRelayPoint>,<{}upgradeFinishTime>,<{}dndOption>,<{}useDevicePoolCgpnTransformCss>,<{}ownerUserName>,<{}keyOrder>,<{}class>,<{}isProtected>,<{}phoneServiceDisplay>,<{}authenticationString>,<{}informationUrl>,<{}ignorePresentationIndicators>,<{}networkLocale>,<{}deviceMobilityMode>,<{}secureDirectoryUrl>,<{}enableExtensionMobility>,<{}secureInformationUrl>,<{}sipProfileName>,<{}secureIdleUrl>,<{}model>,<{}outboundCallRollover>,<{}loginUserId>,<{}AllowPresentationSharingUsingBfcp>,<{}featureControlPolicy>,<{}geoLocationName>,<{}name>,<{}ecKeySize>,<{}joinAcrossLines>,<{}secureAuthenticationUrl>,<{}earlyOfferSupportForVoiceCall>,<{}messagesUrl>,<{}currentProfileName>,<{}protocol>,<{}authenticationUrl>,<{}secureServicesUrl>,<{}securityProfileName>,<{}aarNeighborhoodName>,<{}requireOffPremiseLocation>,<{}sshUserId>,<{}requireThirdPartyRegistration>,<{}networkLocation>,<{}ringSettingIdleBlfAudibleAlert>,<{}directoryUrl>,<{}phoneTemplateName>

I'd argue behavior should be consistent across operations. And now I'm off to rewrite yet another operation to sql. Well.. this time around I have to combine listPhone with axl as it would take too much time to get all the properties I need from sql.

The engineers say this is by design.  List APIs show the least number of parameters.  You should use get APIs for the most information.

Then I propose adding <lines><lineIdentifiers>.. that is compact.. but linking stuff that can have lines and lines that makes a lot of sense.

What's I'm doing is a reverse sync between PBX and provisioning tool. So I bulk load users, phones, etc.. and I figure listX is a lot more effective than going object by object. There's only one request after all, and if properly implemented on the remote end, one database connection that is opened, rather than hundreds or thousands.

As a workaround, I'm sending an SQL query after the listX to just get devicename and list of line uids.. and then consult the result of listLine that returned all lines.

What about the selective searchCriteria validation?

I'll pass on the suggestions.

However, the executeSQLQuery request is provided precisely because the "stock" requests aren't always going to provide every developer with exactly the information they need in a specific case.