vania-janet/multiturn-rag-retrieval-data huggingface dataset:
To send me your street address, respond to this text message with your address."
}
}
}
}
]
}
}
Show more

You can specify any of the following parameters in the parameters object:



 Parameter Type Description 

 message string The text of the SMS message to send. Required. 
 mediaURL list A list of URLs for media files to be sent with the message as MMS attachments. Optional. 
 tenantPhoneNumber string The phone number that is associated with the tenant. The format of the number must match the format that is required by the SMS provider. If no tenantPhoneNumber value is provided, the tenant ID from the phone integration configuration for the active call is used. Optional. 
 userPhoneNumber string The phone number to send the SMS message to. The format of the number must match the format that is required by the SMS provider. If no userPhoneNumber value is provided, the voice caller's phone number from From header of the incoming SIP INVITE request is used. Optional. 



If your SMS with Twilio integration supports more than one SMS phone number, or you are using a non-Twilio SIP trunk, be sure to specify the phone number that you want to use to send the text message. Otherwise, the text is sent using the same phone number that was called.

After the assistant receives an SMS message, a new conversation turn is initiated with the text input vgwSMSMessage. This input indicates that a message was received from the caller. The text of the customer's message is included as the value of the vgwSMSMessagecontext variable.

If the assistant is unable to send an SMS message to the caller, a new turn is initiated with the text input vgwSMSFailed. This input indicates that an SMS message could not be sent the caller. You can design your dialog or actions to handle such a failure by creating intents or actions that are triggered by the input text vgwSMSFailed.

{
"input": {
"message_type": "text",
"text": "vgwSMSMessage"
},
Known limitations 

First, this section covers limitations that apply to all IBM Cloud® Direct Link on Classic offerings, and then it details some limitations of each offering individually.



 General IBM Cloud Direct Link on Classic limitations 



* Each Direct Link on Classic connection requires a unique order. If you require multiple connections, open an IBM Cloud Direct Link order for each connection.
* The IBM Cloud services network is not accessible directly from your remote networks.
* IBM Cloud does not permit customers to back haul traffic between their remote sites across the IBM Cloud backbone. The Direct Link on Classic product is meant to let your remote networks communicate privately with your IBM Cloud infrastructure.
* Direct Link on Classic requires you to use a VRF (Virtual Routing and Forwarding) instance.
* VRF is not fully compatible with the IBM Cloud SSL and IPsec VPN services.
* VRF is not compatible with IBM Cloud account-to-account VLAN spanning.
* Direct Link on Classic requires BGP to establish the routes to a customer's remote network.







 Direct Link Connect on Classic limitations 



* Customers are responsible for any fees that are associated with reaching the PoP from a remote network and any fees that are incurred with the Cloud Connect provider.
* IBM Cloud does not colocate any customer equipment in our network PoPs. Customers must work with their provider to determine whether they need to colocate any equipment in the facility where the IBM Cloud network PoP exists.
* Direct Link Connect availability varies between locations. Customers can contact their IBM Cloud account manager to confirm current or future availability.







 Direct Link Dedicated on Classic limitations 



* The IBM Cloud fees for Direct Link Dedicated cover the cost of port termination on the IBM Cloud infrastructure. Customers are responsible for any fees that are associated with reaching the PoP from a remote network and any cross-connects needed within the PoP facility. IBM Cloud does not order a cross-connect on any customer's behalf.
* IBM Cloud does not colocate any customer equipment in our network PoPs. Customers must work with their provider to determine whether they need to colocate any equipment in the facility where the IBM Cloud network PoP exists.







 Direct Link Dedicated Hosting on Classic limitations 



* Direct Link Dedicated Hosting requires a specific contract between IBM Cloud and the customer.
Timeout 300 seconds 600 seconds [Contact IBM support](https://cloud.ibm.com/docs/get-support?topic=get-support-open-case&interface=ui) 



For more information about supported CPU and memory combinations, see [Supported memory and CPU combinations](https://cloud.ibm.com/docs/codeengine?topic=codeengine-mem-cpu-combo).

Code Engine has limits for apps within a project.



* You are limited to 40 apps per project.
* You are limited to a total of 120 revisions for all apps per project.



Code Engine does not support overcommitment for application resources. Therefore, if you create an application by using the API or with kubectl apply -f <yaml>, the values for Resource.Requests and Resource.Limits for CPU, Memory, and Ephemeral Storage must be specified and must be the same.





 Job defaults and limits 

The following table lists the limits for jobs.



Job limits

 Category Default Maximum value Need to extend the maximum? 

 Array - Array indices 0 9999999 [Contact IBM support](https://cloud.ibm.com/docs/get-support?topic=get-support-open-case&interface=ui) 
 Array - Number of instances 1 1000 [Contact IBM support](https://cloud.ibm.com/docs/get-support?topic=get-support-open-case&interface=ui) 
 CPU 1.0 12.0 [Contact IBM support](https://cloud.ibm.com/docs/get-support?topic=get-support-open-case&interface=ui) 
 Ephemeral storage 400 M 48 G <br>(limited by memory) [Contact IBM support](https://cloud.ibm.com/docs/get-support?topic=get-support-open-case&interface=ui) 
 Memory 4 G 48 G [Contact IBM support](https://cloud.ibm.com/docs/get-support?topic=get-support-open-case&interface=ui)
[2019-06-04](https://cloud.ibm.com/docs/natural-language-understanding?topic=natural-language-understanding-release-notesnatural-language-understanding-jun0419) Fixed a bug that caused entities requests with custom models to ignore the limit option.<br><br>The default limit value for all entities requests is now 50 for all models.<br><br>The maximum limit value of 250 entities has been removed. 
 [2018-11-16](https://cloud.ibm.com/docs/natural-language-understanding?topic=natural-language-understanding-release-notesnatural-language-understanding-nov1618) Version 2 Italian entity type system. 
 [2018-09-21](https://cloud.ibm.com/docs/natural-language-understanding?topic=natural-language-understanding-release-notesnatural-language-understanding-sep2118) Version 2 Portuguese entity type system. 
 [2018-03-16](https://cloud.ibm.com/docs/natural-language-understanding?topic=natural-language-understanding-release-notesnatural-language-understanding-mar1618) Version 2 French entity type system.<br><br>Version 2 German entity type system. 
 [2017-02-27](https://cloud.ibm.com/docs/natural-language-understanding?topic=natural-language-understanding-release-notesnatural-language-understanding-feb2717) Base version. 









 Entity types (Version 1) deprecation announcement 

Entity types (Version 1) is deprecated. As of 11 July 2023, the v1 Entities type system will no longer be available. Consider switching to the v2 Entities type system. By using the more generic v2 Entities type system together with other features, such as Concepts and Categories, you can achieve similar outcomes with more flexibility. For more information about v2 entity types, see [Entity types (Version 2)](https://cloud.ibm.com/docs/natural-language-understanding?topic=natural-language-understanding-entity-types-version-2).





 9 June 2023 

Retired Custom Sentiment Feature
Known limitations 

The following information describes some limitations when working with IBM Cloud® Internet Services (CIS), as well as some suggested courses of action to improve your experience.



* It is recommended that you use Chrome.
* The free trial plan is limited to one instance per account. After you create a resource instance and add a domain to it, you are not allowed to add new resource instances for CIS. This restriction is enforced even if you delete a trial domain and then attempt to add a domain again to the same resource instance. You'll encounter an error if you attempt to do so.
* For this service, we support subdomain delegation only using NS records from another provider. CNAME delegation is not supported.
* A, AAAA, and CNAME wildcard records ("*") cannot be proxied.
* When you delete a dedicated certificate, it might reappear in the list for a short time before the deletion is complete.
* To modify your custom dedicated certificate’s hostnames after ordering, you must order a new certificate and then delete the old one.
* IP rules created with two letter country codes can only be made with the Challenge action. If you want to block visitors from a country, upgrade to the Enterprise plan or place rules on your server to fully block.





 Global load balancer 



* Cloud Internet Services allows you to use the character _ in load balancer hostnames. However, Kubernetes clusters cannot use _.
* The Standard plan permits a maximum of 5 load balancers, pools, and health checks. Each pool can have a total of 6 origins, but only 6 unique origins are permitted throughout each CIS instance.
* Health check events for deleted pools and origins cannot be filtered, but they still appear in the table.
* If you filter Health check events by Pool Health, Degraded pools are included because they technically are healthy, but might contain 1 or more critical origins.
* When adding the request header name for a health check, use Host, capitalized. Using a lower-case host for a health check fails.







 DNS 



* Exporting DNS records includes Cloudflare CNAME records that should be hidden.
If you attempt to exceed the number of allowed connections your client application is blocked with the return code MQRC_MAX_CONNS_LIMIT_REACHED (2025) and an AMQ9694E error message is printed in the queue manager logs.

Because JMS uses two client connections to pass messages you need to be aware that if your queue manager connection limit is 10 you can only connect 5 JMS clients to your queue manager before reaching the connection limit.





 Solution 

To resolve this problem either:



* Disconnect unnecessary client connections to allow newer clients to connect
* Upgrade your queue manager to a larger size to allow more client connections



To let you know when you are getting close to your queue manager client connection limit, the queue manager outputs an AMQ7358W error message in the queue manager logs when it is at 80% of allowed client connections.







 Messages cannot be put to a queue whose name does not start with 'DEV.' 

While attempting to send a message to a new queue whose name does not begin with 'DEV', you receive one of the below error messages:



* JMSWMQ2007: Failed to send a message to destination '[YOUR QUEUE NAME]'
* MQRC_NOT_AUTHORIZED (2035).





 Explanation 

The default configuration of an IBM MQ on Cloud queue manager is for all initial queues to be assigned with authority records, allowing users and applications to send and receive messages. All queues and topics beginning with 'DEV.' are configured to allow messages to be sent and received.

If a new queue or topic has been created whose name does not start with 'DEV.' the predefined authorization records will not apply. Therefore applications will not have the required permissions to send or receive messages to this queue or topic.





 Solution 

To resolve, the problem, use one of the following methods.



* Using runmqsc, run the following commands:

SET AUTHREC PROFILE('TEST.QUEUE') OBJTYPE(QUEUE) GROUP('demoapp') AUTHADD(PUT,GET,BROWSE,INQ)

SET AUTHREC PROFILE('TEST.QUEUE') OBJTYPE(TOPIC) GROUP('demoapp') AUTHADD(SUB,PUB)
Setting up rate limits in API Connect V5 

Duration: 15 mins
Skill level: Beginner



 Objective 

This tutorial shows you how to establish rate limits on your APIs. A rate limit is the maximum number of calls that you want to allow in a particular time interval. Setting rate limits enables you to manage the network traffic for your APIs and for specific operations within your APIs.

In IBM® API Connect for IBM Cloud®, Products provide a way of grouping APIs into a package for a particular set of users, or consumers. Products also contain Plans, which specify whether the set of APIs are controlled with rate limits, and whether subscriptions to the Product reuqire approval from your organization.

When an application developer wants to use your APIs, they select a Product that contains the API they want to use, and subscribe to one of that Product's Plans.

In this tutorial, you will complete the following tasks to estable a rate limit on an API:



1. Create a new rate-limited Plan in an existing Product.
2. See what happens when an application exceeds the allowed rate limits.







 Prerequisites 

You must have already created an API in API Connect, secured with at least an API Key. In the following instructions, our starting point is the [Weather Provider API example file](https://raw.githubusercontent.com/IBM-Bluemix-Docs/apiconnect/master/tutorials/weather-provider-api_1.yaml), secured using a client ID and secret.

Complete the following tutorials to set up the prerequisite conditions for this tutorial:



* [Import your API spec, and proxy an existing REST service](https://cloud.ibm.com/docs/apiconnect/tutorials?topic=apiconnect-tut_rest_landing).
* [Secure your API with a client ID and secret](https://cloud.ibm.com/docs/apiconnect/tutorials?topic=apiconnect-tut_secure_landing).







 Launching API Connect 



1.
Service limitations 

Limitations might change as capabilities are added, so feel free to check back from time to time.



 General restrictions 

The following features are not supported, including all properties associated with these features:



* The following concepts are not supported:



* IPV6
* Multiple IP addresses on the same network interface



* Virtual server instance name change: If you update the name of a virtual server, the name change might not appear consistently in different areas of the IBM Cloud® console. For example, the virtual server name change might not be reflected in the IBM Cloud console, or on the billing invoice, yet it appears correctly in the user's list of running instances.
* Direct Link on Classic access to VPC is supported through [Setting up access to classic infrastructure](https://cloud.ibm.com/docs/vpc?topic=vpc-setting-up-access-to-classic-infrastructure) only. IBM Cloud Direct Link does not have this limitation.
* Nested virtualization on virtual server instances is not a supported configuration.





 Billing note 

When the VPC billing system reports network traffic from load balancers and VPNs, the resources are identified with a nonstandard name. The resource is identified by using the prefix instance-, followed by the last 16 digits of the back-end virtual server instance.

For example, if the load balancer UUID is 10000, but it is running in a virtual server instance that has an internal UUID of 75007600770078007900. The last 16 digits of the instance UUID are: 7600770078007900.

The CRN identifies the load balancer as follows:crn:v1:bluemix:public:is:eu-gb:a/0000000001::load-balancer:instance-7600770078007900.







 Virtual private cloud restrictions 

An IBM Cloud VPC cannot be peered with other VPCs natively. It is possible to connect VPCs by using either Transit Gateway, VPN Gateways, or Floating IPs.



* Both VPN Gateways and Floating IPs can't use an automatic route advertisement between the two VPCs.
There is a [limit](https://cloud.ibm.com/docs/account?topic=account-known-issuesiam_limits) on the total number of policies that are allowed in an account. You can use a few strategies to ensure that you don't reach the limit and to reduce the amount of time that you spend managing access for the identities in your account (users, service IDs, or trusted profiles):



* Use the principle of least privilege and assign only the access that is necessary. This can help you ensure that the identities in your account are limited to only the actions that you want to allow. For example, time-based conditions for access policies grant access during only the timeframe you specify, reducing the opportunity for attack in the event of a security breach. For more information, see [Limiting access with time-based conditions](https://cloud.ibm.com/docs/account?topic=account-iam-time-based&interface=ui).
* Add resources to a resource group to further minimize the number of necessary policies. For example, you might have a team working on a project that uses specific resources in your account. Add the team members to an access group or trusted profile with a policy that assigns access to only the resources that are in a specific resource group. This way, you don't need to assign a policy to each resource for each team member.
* Use access groups to streamline managing access for identities that require the same level of access. You can set up an access group with a specific policy defined, and then add those identities to the group. If the group members need more access later on, you simply define a new policy for the access group.
* Use access management tags to control access to the resources and service IDs in your account at scale. By assigning access only to resources and service IDs that have specific tags that are attached to them, you can avoid multiple updates to your defined policies. For more information, see [Controlling access to resources by using tags](https://cloud.ibm.com/docs/account?topic=account-access-tags-tutorial).
* Use trusted profiles to automatically grant federated users and compute resources access to your account.
For example, if you have 100 keys in your instance, and you want to list only 10 keys, use ../keys?limit=10. The maximum value for limit is 5000. 



For usage notes, check out the following examples for setting your limit and offset query parameters.



Table 3. Provides usage notes for the limit and offset query parameters

 URL Description 

 .../keys Lists all of your available resources, up to the first 2000 keys. 
 .../keys?limit=10 Lists the first 10 keys. 
 .../keys?offset=25&limit=50 Lists keys 26 - 75. 
 .../keys?offset=3000&limit=50 Lists keys 3001 - 3050. 



Offset is the location of a particular key in a data set. The offset value is zero-based, which means that the 10th encryption key in a data set is at offset 9.





 Retrieving keys by state 

By specifying the state parameter at query time, you can retrieve keys that are in the states that you specify.

For example, you might have keys in your service instance that are in the active, suspended, and destroyed states, but you only want to retrieve keys in the active state when you make a GET /keys request.

The state query parameter takes in a list of integers 0 - 5 delimited by commas with no whitespace or trailing commas. Valid states are based on NIST SP 800-57. For more information about key states, see [Key states and transitions](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-key-states).

You can use the following example request to retrieve a different set of keys.

curl -X GET 
'https://api.<region>.hs-crypto.cloud.ibm.com:<port>/api/v2/keys?state=<state_integers>' 
-H 'accept: application/vnd.ibm.collection+json' 
-H 'authorization: Bearer <IAM_token>' 
-H 'bluemix-instance: <instance_ID>'

Replace the state variable in your request according to the following table.
When you get a Twilio phone number, it supports voice, SMS, and MMS automatically. Your new phone number is listed as an active number.







 Ask WhatsApp for permission to enable your Twilio number for WhatsApp. 

WhatsApp has a rigorous process that they use to review all businesses that want to interact with customers over their network. WhatsApp, which is owned by Facebook, requires that you register your business with the Facebook business directory.



1. To register, go to the [Facebook Business Manager](https://business.facebook.com/overview) website, and click Create account and follow the instructions to create an account.
2. Get your Facebook Business Manager ID. In [Settings](https://business.facebook.com/settings), click the Business info tab. The Facebook Business Manager ID is at the top of the page.
3. Submit the Request to enable your Twilio numbers for WhatsApp form from the [Twilio API for WhatsApp](https://www.twilio.com/whatsapp/request-access) web page.

Tips for specifying the following values:



* Phone Number: Specify the Twilio phone number that you created earlier.

Consider provisioning more than one phone number and going through the process of getting permission for the numbers in parallel. If your number was used by a different business previously (because Twilio assigned you a number that was used before, for example), WhatsApp will reject it.
* Are you working with an ISV: No
* Twilio Account SID: From the Twilio site, click the home icon to go to your project dashboard to find the SID.
* Facebook Business Manager ID: Add the ID for the account that you created in the previous step.



4. Click Request Now.



Give WhatsApp time to evaluate and approve your request. It can take up to 7 days for your request to be approved.





 Set up the integration 

To set up the integration, complete the following steps:



1. From the Assistants page, click to open the assistant tile that you want to deploy.
2.
Instructs the phone integration to collect dual-tone multi-frequency signaling (DTMF) input from a user. This command supports the following parameters:



 parameter name description required default 

 termination_key The DTMF termination key, which signals the end of DTMF input (for example, ). no n/a 
 count The number of DTMF digits to collect. This must be a positive integer no larger than 100. Required if termintation_key, or minimum_count and maximum_count, are not defined n/a 
 minimum_count The minimum number of DTMF digits to collect. This property is used along with maximum_count to define a range for the number of digits to collect. This value must be a positive integer with a minimum value of 1 and a maximum value less than maximum_count. Required if terminatation_key and count are not defined. n/a 
 maximum_count The maximum number of DTMF digits to collect. This property is used along with minimum_count to define a range for the number of digits to collect. When this number of digits is collected, a conversation turn is initiated. This value must be a positive integer no greater than 100. Required if termintation_key and count are not defined. n/a 
 inter_digit_timeout_count The amount of time (in milliseconds) to wait for a new DTMF digit after a DTMF digit is received. During an active DTMF collection, this timeout activates when the first DTMF collection is received. When the inter-digit timeout is active, it deactivates the post-response timeout timer. If the inter_digit_timeout_count parameter is not specified, the post-response timer resets after receiving each DTMF digit, and it stays active until either the post-response timeout count is met or the collection completes. This value is a positive integer no higher than 100,000 (or 100 seconds). no n/a 
 ignore_speech Whether to disable speech recognition during collection of DTMF digits, until either the collection completes or a timeout occurs.