You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What is exposed by Extensions API method signatures needs to be defined/narrowed by interfaces.
This requires design discussion on what can or can not be customized by 3rd party developers.
Currently preOutboundAction takes an Object parameter and returns an ExtensionResponse with an Object payload hence is too generic.
To maintain more control of RC, we can limit 3rd party customization of RC by only exposing specific customizable properties of RC like system-wide or session-wide outbound-proxy or outbound-sms properties.
To allow customization of RC functions/logic, different approach might be necessary.
Currently the Extension method signatures depend on specific exposed classes in extensions.api
telephony.api.CreateCall maps to extension.api.CallRequest
properties in IncomingPhoneNumbersEP constructsextension.api.ApiRequest
There is currently no exposed extension.api class for CreateSmsSession nor UssdCall requests.
There is no interface to customize RC system wide or session wide configurations like outbound-proxy or outbound-sms.
The text was updated successfully, but these errors were encountered:
abdulazizali77
changed the title
Issue #1981: Extensions API Design: Interfaces need to be defined: preOutboundAction is too generic
Issue #1981: Extensions API Design: Interfaces need to be defined for the method signatures
May 4, 2017
abdulazizali77
changed the title
Issue #1981: Extensions API Design: Interfaces need to be defined for the method signatures
Issue #1981: Extensions API Design: Interfaces need to be defined for the Extensions method signatures
May 4, 2017
What is exposed by Extensions API method signatures needs to be defined/narrowed by interfaces.
This requires design discussion on what can or can not be customized by 3rd party developers.
Currently
preOutboundAction
takes anObject
parameter and returns anExtensionResponse
with anObject
payload hence is too generic.To maintain more control of RC, we can limit 3rd party customization of RC by only exposing specific customizable properties of RC like system-wide or session-wide
outbound-proxy
oroutbound-sms
properties.To allow customization of RC functions/logic, different approach might be necessary.
Currently the Extension method signatures depend on specific exposed classes in extensions.api
telephony.api.CreateCall
maps toextension.api.CallRequest
IncomingPhoneNumbersEP
constructsextension.api.ApiRequest
There is currently no exposed extension.api class for
CreateSmsSession
norUssdCall
requests.outbound-proxy
oroutbound-sms
.The text was updated successfully, but these errors were encountered: