Dial-In-Conference via OpenTok

[aleksander-tatskiy]

According your article here: https://www.nexmo.com/blog/2019/04/23/connecting-webrtc-and-pstn-with-opentok-and-nexmo-dr

1. we bought nexmo phone number
2. user call to this number
3. operator/bot (which we coded in webhooks) answers with instructions to input PIN Code
4. user enter PIN code
5. we find OpenTok Session ID by PIN code (stored in database)
6. after that we provide JSON response with
   response = [ { action: 'talk', text: 'Welcome to the conference call' }, { action: 'conversation', name: <OPENTOK_SESSION_ID> } ]

Couple Questions:

1. Will this scenario connect user to OpenTok JS web session (in browser). BTW, Dial-out works fine for us.
2. By this flow (from your article) how OPEN TOK will determine our Open Tok API keys? and we should create token for specific user in open tok session.

@msach22 Can you help us, please?

[aleksander-tatskiy]

@msach22 How to put all participants into the nexmo conversation?

[aleksandr-leontev]

@msach22 Yes, I can't receive this header from nexmo:
https://github.com/opentok/opentok-nexmo-sip/blob/master/Dial-In-Conference/server.js#L152

[aleksandr-leontev]

const setSipOptions = () => ({ auth: { username: config.sip.username, password: config.sip.password, }, secure: false, });
We can't find where you set this header to receive it
https://github.com/opentok/opentok-nexmo-sip/blob/master/Dial-In-Conference/server.js#L152

[msach22]

Hi All, thanks for filing an issue. Could you share the headers you receive on the nexmo side when you run this application?

[aleksandr-leontev]

@msach22 With which webhook we can check headers which Nexmo receives? (Looks like OpenTok library doesn't send it?)
As we understand when we call opentok.dial method, opentok send the request to the Nexmo.

Tbh with you, we use Ruby library, but we tried your example with node.js, too

Now the question which we sent to the NEXMO and to the OPENTOK support:

Why when we use OPENTOK dial method (https://github.com/opentok/OpenTok-Ruby-SDK/blob/master/lib/opentok/sip.rb#L38) and set our own params/headers (as we saw OPENTOK call these headers by some reasons, but send the data in the body of the request) we don’t receive these params on answer_url (https://developer.nexmo.com/voice/voice-api/webhook-reference#answer-webhook) webhook?

We tried all cases how we can use keys: SipHeader_X-UserId, X-UserId and UserId
Or please help us and explain, how we should connect OPENTOK WebRTC session to NEXMO conversation? What we do wrong?
How your senior developer receives this header here:
https://github.com/opentok/opentok-nexmo-sip/blob/master/Dial-In-Conference/server.js#L149
And yes, we tried to use this code example, we didn’t receive this query params, too.

Is it right, how we realized dial-in feature - both, the user who calls should connect to NEXMO conversation and the WebRTC (Web OpenTok) users/session should call to NEXMO and be in the same conversation on the NEXMO.
To combine them into one conversation on nexmo.

[aleksandr-leontev]

(https://tokbox.com/developer/guides/sip/)

We implemented part when the user calls, enters the pin code.
We found our opentok meeting in database, by this pin code and use sessionId as conversation name for ncco response.
It works well for us.

But when the user continues to hang on the phone, he does not hear anyone from the WebRTC(opentok web session) side.

So we are a bit confusing how WebRTC users should connect to the NEXMO conversation.
Between user mobile and nexmo conversation - it is clear for us.
We think that we should call opentok#dial method for this via our own virtual number.
So in this dial method we should set "X-OpenTok-SessionId": header/param
As we understand you do it here (on the answer_url webhook): https://github.com/opentok/opentok-nexmo-sip/blob/master/Dial-In-Conference/server.js#L149

and after that check it from headers on answer_url. Is it right? pls, help us Manik, CC @msach22 :)
We already spend real money on Nexmo

[aleksander-tatskiy]

@msach22

Could you clarify please steps to connect PSTN users to Opentok session via Sip Interconnect (DIAL-IN)?

We have opentok session with session_id
We have Nexmo voice application with a virtual number
The user wants to call from his phone to Opentok Audio/Video session.

He dial-in conference number.
We receive params in answer_url

In answer_url:

We check if some headers present (Opentok session_id === Nexmo conversation name)
If no header, we will ask user to enter a pic code
else -> we will add him to the conversation.
We ask the user to enter a pin code to detect sessionID (pin code generated for current Session in the database)

response = [
          {
            action: 'talk',
            text: 'Please enter a a pin code to join the session'
          },
          {
            action: 'input',
            dtmf: {
              maxDigits: 5,
              submitOnHash: true,
              timeOut: 10
            },
            eventUrl: ["sip_dtmf_url"]
          }
        ]
render json: response.to_json

We defined sip_dtmf action where we will find Session-Id by entered pin code (eventUrl: ["sip_dtmf_url"])

response = [
        {
          action: "talk",
          text: "Welcome to conference call"
        },
        {
          action: "conversation",
          name: session_id,
        }
      ]

render json: response.to_json

Should we call opentok.sip.dial here or should we at all call it in dial-in case?

[Kadhiresan-K]

Hi @msach22

We are facing the same issue as the above one, mentioned by @aleksander-tatskiy

In our case, the Application starts the opentok video session, and using this session_id we generate SipToken and dial out to LVN.
and participants dials to the LVN get the prompts for the pin after entering the pin, he joins for the call.
He can hear the voice from the video session But the person who is in the video session can not hear the PSTN to LVN participant's voice.

It's like a one-way voice to the PSTN to LVN participant's, Is there is any way to make two-way voice communication (video session to SIP call)?

Our Current Approach: