cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Can't call my virtual number.

leyk
Contributor

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);
 
I use ngrok to tunnel my localhost port and put the ngrok url extended with my endpoint in the 'Callback' section of 'App' section in 'Voice & Video' section. I use Thunder Client to test if my endpoint with ngrok url is reachable and I can reach it with no problems.
2 ACCEPTED SOLUTIONS

Accepted Solutions

Roland_Ian
Employee
Employee

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.

 

 

Roland-Ian Clothier, Developer Support Engineer

View solution in original post

Roland_Ian
Employee
Employee

Incoming ICE from PSTN (telephone leg)

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"
}

 

 

SVAML Response for PSTN domain ICE from your callback application

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"
  }
}

 

 

 

ICE from incoming SDK InApp (MXP) leg.

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"
    }
  ]
}

 

 

 

SVAML Response for MXP domain ICE from your callback application

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.

 

Roland-Ian Clothier, Developer Support Engineer

View solution in original post

6 REPLIES 6

leyk
Contributor

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.

Roland_Ian
Employee
Employee

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.

 

 

Roland-Ian Clothier, Developer Support Engineer

leyk
Contributor

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.

Roland_Ian
Employee
Employee

Incoming ICE from PSTN (telephone leg)

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"
}

 

 

SVAML Response for PSTN domain ICE from your callback application

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"
  }
}

 

 

 

ICE from incoming SDK InApp (MXP) leg.

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"
    }
  ]
}

 

 

 

SVAML Response for MXP domain ICE from your callback application

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.

 

Roland-Ian Clothier, Developer Support Engineer

leyk
Contributor

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

 

 

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.

 

https://developers.sinch.com/docs/in-app-calling/overview/#sinch-in-app-global--regional-hostnamesen...

 

Roland-Ian Clothier, Developer Support Engineer