05-15-2023 10:27 PM - last edited on 05-16-2023 06:29 AM by Roland_Ian
I have a problem. I tried calling my virtual number using my phone number. Unfortunately, my phone says that the number(virtual number) is invalid. My phone number is in the 'verified number' list. My virtual number can receive sms from my phone and send sms to my phone. It can also send a call to my phone. My only problem is the incoming call.
Right now, I'm using this basic endpoint for testing:
const svamlResponse = {
instructions: [
{
name: "say",
text: "Hi, thank you for calling your Sinch number. Congratulations! You just responded to a phone call.",
local: "en-US",
},
],
action: {
name: "hangup",
},
};
res.json(svamlResponse);
Solved! Go to Solution.
05-16-2023 07:19 AM
Hi,
If you are using a callback server (thats why you are receiving the call events) you must respond to the DICE with SVAML to also connect to the conference.
As you stated to put an InApp and PSTN call together you must use a conference.
ConnectConf
https://developers.sinch.com/docs/voice/api-reference/svaml/actions/#connectconf
Callback server
If you don't have an application to handle your callback events we have a sample one on github which uses nodejs so you can get an idea of what is required.
https://github.com/sinch/voice-api-webhook-nodejs
If you want to know more about Callback servers we have this quick start
https://community.sinch.com/t5/Voice-API/What-is-a-callback-in-the-Sinch-Voice-world/ta-p/10250
There is an example in the github sample to return a connectConf, look at the bottom of the index.js at the commented out SVAML examples.
05-17-2023 04:25 AM
The first ICE arrives at your backend when you call your number assigned to your application
{
"event": "ice",
"callid": "8d668511-9497-4c23-a7b7-xxxxxxxxxxx",
"callResourceUrl": "https://calling-euc1.api.sinch.com/calling/v1/calls/id/8d668511-9497-4c23-a7b7-xxxxxxxxxxx",
"timestamp": "2023-05-17T10:52:57Z",
"version": 1,
"userRate": {
"currencyId": "USD",
"amount": 0
},
"cli": "46xxxxxxxxxx",
"to": {
"type": "did",
"endpoint": "+46xxxxxxxxx"
},
"domain": "pstn",
"applicationKey": "xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx",
"originationType": "PSTN",
"rdnis": "+46xxxxxxxxx"
}
Here is an added say instruction before the connectConf so you know when you are connected to a conference and when one participant only is in the conference music will play.
Notice the conferenceId is called InAppToPSTN (you can call your conference anything you want)
This must match on the InApp (MXP) leg when doing the connectConf SVAML response
{
"instructions": [
{
┊ "name": "say",
┊ "text": "Conference test",
┊ "locale": "en-GB"
}
],
"action": {
"name": "ConnectConf",
"conferenceId": "InAppToPSTN",
"suppressCallbacks": false,
"moh": "ringing"
}
}
Note here the to is type conference and endpoint is InAppToPSTN (the conferenceId). Even though you have requested a conference connect you must re-confirm that in the SVAML response with connectConf (again, because you are using a callback server)
{
"event": "ice",
"callid": "4f1632b4-c582-4cfe-84b1-xxxxxxxxxxxx",
"callResourceUrl": "https://calling-euc1.api.sinch.com/calling/v1/calls/id/4f1632b4-c582-4cfe-84b1-xxxxxxxxxxxx",
"timestamp": "2023-05-17T10:53:07Z",
"version": 1,
"user": "InApp-caller",
"userRate": {
"currencyId": "USD",
"amount": 0
},
"to": {
"type": "conference",
"endpoint": "InAppToPSTN"
},
"domain": "mxp",
"applicationKey": "xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx",
"originationType": "MXP",
"rdnis": "",
"callHeaders": [
{
┊ "key": "info",
┊ "value": "MXP and PSTN Conf test, InAppToPSTN Conference name"
}
]
}
Here you will respond with the same conferenceId as before (InAppToPSTN). There will be the same welcome message, but because their are two particpants in the conference InAppToPSTN the music will stop playing and the conference can connect.
{
"instructions": [
{
┊ "name": "say",
┊ "text": "Conference test",
┊ "locale": "en-GB"
}
],
"action": {
"name": "ConnectConf",
"conferenceId": "InAppToPSTN",
"suppressCallbacks": false,
"moh": "ringing"
}
}
That will be enough to get both parties in the conference.
05-16-2023 06:08 AM - edited 05-16-2023 06:46 AM
I fixed the problem. I forgot to add '+' prefix when calling my virtual number. My next problem is the ICE event. I'm using conference call to do inbound call because it's said in this post. This is my progress so far: I receive an ICE event from incoming call, create a conference using callConference(), return the conference id that is assigned to my created conference back to sinch server via SVAML connectConf action.
Now, sinch server returns another ICE and I don't know what to do with this another ICE event. I ended the call using my phone and sinch server returns a DICE event.
05-16-2023 07:19 AM
Hi,
If you are using a callback server (thats why you are receiving the call events) you must respond to the DICE with SVAML to also connect to the conference.
As you stated to put an InApp and PSTN call together you must use a conference.
ConnectConf
https://developers.sinch.com/docs/voice/api-reference/svaml/actions/#connectconf
Callback server
If you don't have an application to handle your callback events we have a sample one on github which uses nodejs so you can get an idea of what is required.
https://github.com/sinch/voice-api-webhook-nodejs
If you want to know more about Callback servers we have this quick start
https://community.sinch.com/t5/Voice-API/What-is-a-callback-in-the-Sinch-Voice-world/ta-p/10250
There is an example in the github sample to return a connectConf, look at the bottom of the index.js at the commented out SVAML examples.
05-16-2023 11:55 AM - edited 05-16-2023 12:24 PM
This is what I've done so far:
- Call my virtual number, sinch server reaches to my backend with ICE event:
{
event: 'ice',
callid: '...',
callResourceUrl: 'https://calling-euc1.api.sinch.com/calling/v1/calls/id/...',
timestamp: '...',
version: 1,
userRate: { currencyId: 'USD', amount: 0 },
cli: '-my-phone-number-',
to: { type: 'did', endpoint: '-my-virtual-number-' },
domain: 'pstn',
applicationKey: '...',
originationType: 'PSTN',
rdnis: ''
}
- My server reaches the sinch client.
- Invoke callConference function and put a random uuidv4 number in the function's argument-list.
- Retrieve the random uuidv4 number and send it to the sinch server via SVAML's connectConf action.
- Another ICE event has come:
{
event: 'ice',
callid: '...',
callResourceUrl: 'https://calling-apse1.api.sinch.com/calling/v1/calls/id/...',
timestamp: '...',
version: 1,
custom: '{}',
user: 'MyUserId',
userRate: { currencyId: 'USD', amount: 0 },
cli: '-My-Virtual-Number-',
to: {
type: 'conference',
endpoint: '3602f098-9962-49a5-b090-...'
},
domain: 'mxp',
applicationKey: '...',
originationType: 'MXP',
rdnis: '',
callHeaders: []
}
How to respond to the second ICE? Right now, I'm responding with connectConf and using the event endpoint as conferenceId:
res.status(200).
send({
action: {
name: "connectConf",
conferenceId: 3602f098-9962-49a5-b090-...,
moh: "music2"
}
});
Once the last ICE event receives the response, sinch client ends the call in my client app. Moreover, my phone is still ringing and waiting for something.
05-17-2023 04:25 AM
The first ICE arrives at your backend when you call your number assigned to your application
{
"event": "ice",
"callid": "8d668511-9497-4c23-a7b7-xxxxxxxxxxx",
"callResourceUrl": "https://calling-euc1.api.sinch.com/calling/v1/calls/id/8d668511-9497-4c23-a7b7-xxxxxxxxxxx",
"timestamp": "2023-05-17T10:52:57Z",
"version": 1,
"userRate": {
"currencyId": "USD",
"amount": 0
},
"cli": "46xxxxxxxxxx",
"to": {
"type": "did",
"endpoint": "+46xxxxxxxxx"
},
"domain": "pstn",
"applicationKey": "xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx",
"originationType": "PSTN",
"rdnis": "+46xxxxxxxxx"
}
Here is an added say instruction before the connectConf so you know when you are connected to a conference and when one participant only is in the conference music will play.
Notice the conferenceId is called InAppToPSTN (you can call your conference anything you want)
This must match on the InApp (MXP) leg when doing the connectConf SVAML response
{
"instructions": [
{
┊ "name": "say",
┊ "text": "Conference test",
┊ "locale": "en-GB"
}
],
"action": {
"name": "ConnectConf",
"conferenceId": "InAppToPSTN",
"suppressCallbacks": false,
"moh": "ringing"
}
}
Note here the to is type conference and endpoint is InAppToPSTN (the conferenceId). Even though you have requested a conference connect you must re-confirm that in the SVAML response with connectConf (again, because you are using a callback server)
{
"event": "ice",
"callid": "4f1632b4-c582-4cfe-84b1-xxxxxxxxxxxx",
"callResourceUrl": "https://calling-euc1.api.sinch.com/calling/v1/calls/id/4f1632b4-c582-4cfe-84b1-xxxxxxxxxxxx",
"timestamp": "2023-05-17T10:53:07Z",
"version": 1,
"user": "InApp-caller",
"userRate": {
"currencyId": "USD",
"amount": 0
},
"to": {
"type": "conference",
"endpoint": "InAppToPSTN"
},
"domain": "mxp",
"applicationKey": "xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx",
"originationType": "MXP",
"rdnis": "",
"callHeaders": [
{
┊ "key": "info",
┊ "value": "MXP and PSTN Conf test, InAppToPSTN Conference name"
}
]
}
Here you will respond with the same conferenceId as before (InAppToPSTN). There will be the same welcome message, but because their are two particpants in the conference InAppToPSTN the music will stop playing and the conference can connect.
{
"instructions": [
{
┊ "name": "say",
┊ "text": "Conference test",
┊ "locale": "en-GB"
}
],
"action": {
"name": "ConnectConf",
"conferenceId": "InAppToPSTN",
"suppressCallbacks": false,
"moh": "ringing"
}
}
That will be enough to get both parties in the conference.
05-17-2023 08:27 AM - edited 05-17-2023 10:04 AM
Eidit: I think the reason for my problem is the region(callResourceUrl) of both devices are not the same. Is it possible to specify a region in the callConference function?
I made a client and phone join a conference. However, the 'moh' or the music of both devices are still running.
Here's the log of my previous test
server started at port 4000
{
event: 'ice',
callid: '...',
callResourceUrl: 'https://calling-euc1.api.sinch.com/calling/v1/calls/id/...',
timestamp: '...',
version: 1,
userRate: { currencyId: 'USD', amount: 0 },
cli: '...',
to: { type: 'did', endpoint: '...' },
domain: 'pstn',
applicationKey: '...',
originationType: 'PSTN',
rdnis: ''
}
Phone Connected to Conference f8b40a0c-50a1-47e0-b3ce-03f8fb356e53
{
event: 'ice',
callid: '...',
callResourceUrl: 'https://calling-apse1.api.sinch.com/calling/v1/calls/id/...',
timestamp: '...',
version: 1,
custom: '{}',
user: '...',
userRate: { currencyId: 'USD', amount: 0 },
cli: '...',
to: {
type: 'conference',
endpoint: 'f8b40a0c-50a1-47e0-b3ce-03f8fb356e53'
},
domain: 'mxp',
applicationKey: '...',
originationType: 'MXP',
rdnis: '',
callHeaders: []
}
Client Connected to Conference f8b40a0c-50a1-47e0-b3ce-03f8fb356e53
05-24-2023 05:31 AM
Conferences have regional scope. Please see https://developers.sinch.com/docs/voice/api-reference/#conference-calls
If you know you are going to both be in the same region then use the global ocra api endpoint for the Sinch client. If you know the clients are in different regions then use a specific url for that endpoint.