v1/RegisterTerminalRequest

[avc859587618170]

So, another post reminded me that there is a RegisterTerminalRequest in the api, and I got it to work using this payload:

{
  "device": "3138675309:RCD2CM2ACT81T:0.0.0.0:1",
  "loginInfo": {
    "forceLogin": true,
    "sharedControl": false,
    "password": "1234",
    "mediaMode": "NONE",
    "dependencyMode": "MAIN"
  }
}

And, most importantly, I got the unregister to work as well. I noticed it kicked me out of One-X, which I expected, and for fun I called the number from my cell and my web page still get the "BroadcastStationEvent" with the phone call info in it. Does that mean I could also answer the call from my web page? Without Avaya One-X? That just doesn't seem like that would work. I haven't built that part yet into my proof of concept tool..

Dave

[avc859587618170]

So, I think I was able to prove audio doesn't come through.. which I'm wondering now what would this be used for? Why would I call the registerterminalrequest?

Thanks!

Dave

[flynn1]

So, another post reminded me that there is a RegisterTerminalRequest in the api, and I got it to work using this payload:



And, most importantly, I got the unregister to work as well. I noticed it kicked me out of One-X, which I expected, and for fun I called the number from my cell and my web page still get the "BroadcastStationEvent" with the phone call info in it. Does that mean I could also answer the call from my web page? Without Avaya One-X? That just doesn't seem like that would work. I haven't built that part yet into my proof of concept tool..

Dave

Yes, you can use WTI to "AnswerCall". There are a load of other Call Control functions available too.

[flynn1]

You are not getting audio because mediaMode=NONE means you do not want to get any.

In order to receive media, you need to register in CLIENT media mode and provide your required codec & IP parameters. For example:

{
        "loginInfo": {
                "sharedControl": false,
                "password": 1234,
                "forceLogin": true,
                "mediaMode": "CLIENT",
                "dependencyMode": "MAIN"
        },
        "device": "50503:CM181:0.0.0.0:3",
        "localMediaInfo": {
                "encryptionList": "none",
                "codecs": "g711U",
                "packetSize": 20,
                "rtpAddress": {
                        "address": "12.10.13.142",
                        "port": 4726
                },
                "rtcpAddress": {
                        "address": "12.10.13.142",
                        "port": 4727
                }
        }
}

This tells CM, Whenever 50503 is in a call:
1. Send RTP (media) to 12.10.13.142:4726
2. Send RTCP to 12.10.13.142:4727
3. Accept media for this station only from 12.10.13.142:4726
4. Use codec G.711 Mu law. If CM is not configured to allow this, the call will fail
5. Do not use encrypted media

Please note that, currently, WebRTP and such technologies are not supported. CM can only send media as RTP to an IP address & port. This address must be reachable from the Media Gateway/Server. This may make it tricky for some applications (e.g. cloud-based) to get the most out of this feature.

Martin

[avc859587618170]

Martin, you are awesome!! Thanks for all of your help! I really appreciate it!!! I'm getting the same kick out of doing this that I got out of figuring out ossi! I just wish there had been the same level of help for that. As it was, I used the Directory Enabled Management install guide for most of my info, as well as paste the long string of fids into excel and figure it out by hand. Very tedious..

Thanks again!

Dave

[avc859587618170]

Please note that, currently, WebRTP and such technologies are not supported. CM can only send media as RTP to an IP address & port. This address must be reachable from the Media Gateway/Server. This may make it tricky for some applications (e.g. cloud-based) to get the most out of this feature.

Martin

Hey Martin, did you mean WebRTC, and if so, we will be looking at that in a bit in the hopes we can eliminate a softphone, and just use a web app we create to make calls. Do you mean that WebRTC doesn't support using WTI?

Dave

[flynn1]

Yep. Sorry about, I meant WebRTC. Only full-fat RTP is currently supported.

[avc859587618170]

One last question.. it looks like in our lab we are using G.711MU, but when I put g711MU I get invalid parameter. Only g711U seems to work, and I still have no audio. Is there something else I can look for? I've opened the two ports above in your example on my laptop, and I've tried both my internal ipaddress and my external ipaddress, and no luck on audio for either of those.


Thanks again,

Dave

[flynn1]

The correct string to use in localMediaInfo is "g711U". To see all valid values, you will need to refer to a DMCC Programmers Guide (Appendix B: Constant Values). See the first post in https://support.avaya.com/forums/for...rking-with-wti to see how to get these documents.

Things to look at:
1. Make sure you can ping The media Server/Gateway from your laptop.

2. On CM, run the SAT command "list trace station 3138675309". Now make the call. The output should show if the call succeeds or fails. It should also show some of the media information such as IP Address of Gateway/Server and your IP. If it fails, it should give some cryptic error reason.

3. Start a Media monitor using WTI (you may be doing this already). You should receive a MediaStart event with various media information when the call starts. If you just get a MediaStop, the call failed.

4. Doublecheck your firewall. Make sure the RTP is not being blocked by some intermediate device.

You mentioned your laptop has two IP addresses. Only one of these is likely to be reachable by the Aura equipment (presumably the internal address). Always use this.

[avc859587618170]

Thanks Martin! I'll give all that a try as soon as I'm able.

Have a good day,

Dave

[avc859587618170]

Hmmm. I'm hoping I'm just missing something simple. Still no audio. I've confirmed with the DMCC manual that g711U is the correct codec. The phone call does come through and rings and my website registers it, and I'm even able to answer, but I get dead air. The trace on the station shows the call and that it was ringing, and it showed my ipaddress and port, it's the 10.94.165.80:4726..:



It also shows it's connected when I answer.. I took a look at the EndPointRegistrationEvent for both Avaya One-X and my website, and they are very close to the same. So for One-X here's my registration event:

{
  "EndpointRegisteredEvent": {
    "endpointMACAddress": "02:05:85:7f:eb:81",
    "networkRegion": 1,
    "unicodeScript": -1,
    "monitorCrossRefID": 18,
    "setType": 9611,
    "serviceState": "inService",
    "endpointAddress": "10.94.165.80",
    "signallingProtocolType": "H323",
    "mediaMode": "CLIENT",
    "eptDevice": {
      "deviceIdentifier": "3136622132:RCD2CM2ACT81T:10.9.188.14:0"
    },
    "dependencyMode": "MAIN",
    "device": {
      "deviceIdentifier": "3136622132:rcd2cm2act81t:0.0.0.0:1"
    },
    "productType": "oneX_Comm"
  },
  "timestamp": 1725554867909
}

and for my website, here's the registration event:

{
  "EndpointRegisteredEvent": {
    "endpointMACAddress": "unknown",
    "networkRegion": 1,
    "unicodeScript": 0,
    "monitorCrossRefID": 18,
    "setType": 9611,
    "serviceState": "inService",
    "endpointAddress": "10.2.188.16",
    "signallingProtocolType": "H323",
    "mediaMode": "CLIENT",
    "eptDevice": {
      "deviceIdentifier": "3136622132:RCD2CM2ACT81T:10.9.188.14:1"
    },
    "dependencyMode": "MAIN",
    "device": {
      "deviceIdentifier": "3136622132:rcd2cm2act81t:0.0.0.0:1"
    },
    "productType": "IP_API_A"
  },
  "timestamp": 1725554835566
}​

Looks like mediaMode and dependencyMode are the same, I guess that's good. For my website event, I'm not sure what endpointAddress is. That's not the IP Address of my laptop. Although I did try to send that Ip address in the terminal request, just in case, and I still didn't get any audio.

Just so we are on the same page, I have a plantronics headset plugged into my computer, and it works for One-X, MS Teams, etc.. so I'm guessing there's nothing fancy I need to do with that?

Just in case, I'm guessing it doesn't matter that my website address is "https://localhost:7046/agentinterface" since I get the ringing event along with the info about the incoming call?

Not quite sure where to go from here.

Thanks,

Dave

[avc859587618170]

I'm starting to think my website needs to turn on the mic and speaker on my headset? Maybe? 🤔 Yea, when I answer the call through my website, the headset doesn't seem to know I'm on a call. The mute button or answer/make call buttons don't do anything.

[flynn1]

Ah, so when you say that you "have no audio", you just mean that there is no audio coming out of your headphones. Correct?

The bad news is that is is much more complex than you think. The Media Server will send RTP packets containing the audio to your port. It is up to you to process these packets. You will need some sort of RTP stack that can decode the messages and do something with them.

You can confirm that the laptop is receiving the RTP using a packet sniffer such as Wireshark.

If you are set on implementing some sort of web based softphone, you should take a look a the Avaya Client SDK. There is a Javascript version of that which, I think, can be embedded into a webpage. You can download the SDK and the Avaya Client SDK Developer Documentation Local Archive from https://www.avaya.com/en/partners/devconnect/sdks/

Martin

[avc859587618170]

Thanks Martin, that's what I was afraid of!! Thanks for the info and link. I'll take a look at that!

Have a good day,

Dave