Scott1234

great !

I am guessing it's because the phone just needs to be able to read the cert? and its never worked?

Looking closer into the phone logs its self, even with mode set to 2 forced, its failing to encrypt. I only became aware of this behaviour as the yealink dm portal generates alerts when calls fail to encrypt. Phone's logs show, Jun 9 08:42:17 ATP [1092.1109]: DURL<3+error > [DCMN]download common error, errcode:404, no out. Jun 9 08:42:17 ATP [1092.1109]: ATP <3+error > https to file failed, code = 404, msg = , retry = 1 Jun 9 08:42:17 sua [1002.1970]: NET <3+error > [255] depth=2:/C=US/O=Internet Security Research Group/CN=ISRG Root X1 Jun 9 08:42:17 sua [1002.1970]: NET <3+error > [255] depth=1:/C=US/O=Let's Encrypt/CN=R3 Jun 9 08:42:17 sua [1002.1970]: NET <3+error > [255] depth=0:/CN=pbxdomain.com Jun 9 08:42:17 ATP [1092.1109]: DURL<3+error > [DCMN]Recode is 404, Request err.

I think it might be because I am using non standard sip ports and its not factoring that in when doing the loopback? I forgot to look before but the PCAP does not define any SIP ports so it would be defaulting to 5060 ? The loop back call user agent shows up as Vodia-WEBRTC, maybe as my attempts where vodia app.

I just get static and the call gets held up there for ever until ended on Domain A never shows up in Domain B logs Trunk debug 9 on Domain A shows its matched the DID on Domain B Trunk debug 9 on Domain B shows nothing [9] 19:36:50.282 TRUN: Dialplan: Simple match begin of 0877777777 to * [9] 19:36:50.282 TRUN: Last message repeated 2 times [9] 19:36:50.282 TRUN: Dialplan: Evaluating * against 0877777777@domainA.com [5] 19:36:50.282 TRUN: Dialplan "loopback-test": Match 0877777777@domainA to sip:+61877777777@domainB;user=phone on Try Loopback trunk [7] 19:36:50.283 MEDI: Port 345: Set codec preference count 2 [7] 19:36:50.283 MEDI: Port 346: Set codec preference count 2 [8] 19:36:50.283 MEDI: Port 346: state code from 0 to 100 [9] 19:36:50.283 MEDI: Port 346: Adding codec PCMA/8000 to available list [9] 19:36:50.283 MEDI: Port 346: Update codecs preference size 2, available codecs size 2 [7] 19:36:50.283 MEDI: Port 346: Allocated ports 53646 and 53647 [8] 19:36:50.284 MEDI: Port 345: state code from 0 to 183 [8] 19:36:50.284 MEDI: Port 345: Ignore double SDP [9] 19:36:50.284 MEDI: Port 345: Adding codec PCMA/8000 to available list [9] 19:36:50.284 MEDI: Port 345: Update codecs preference size 2, available codecs size 2 [6] 19:36:50.284 MEDI: Port 345: Choose codec PCMA/8000 [6] 19:36:50.520 MEDI: Port 345: Sending RTP to my.wan.ip:49940, codec PCMA/8000 [7] 19:36:50.601 MEDI: Port 345: Set DTLS SRTP key for client [9] 19:36:50.623 MEDI: Port 345: Received first RTP packet Static so hangup, [8] 19:36:58.967 MEDI: Port 345: Clearing port with SIP Call-ID kwegJ14w [8] 19:36:58.969 MEDI: Port 346: state code from 100 to 487 [8] 19:36:58.969 MEDI: Port 346: Send hangup with reason bye [8] 19:37:30.969 MEDI: Port 346: Clearing port with SIP Call-ID be3cbe2b@pbx

Yeah but, why doesn't the Yealink <-> PBX leg negotiate to SRTP when the call starts from the handset when 'Optional' is in use. When the call comes into the handset from say external source the PBX <-> Yealink leg will negotiate SRTP, as it should. The only way to get it to use SRTP when the call is placed from the phone is with it on forced. It's like the PBX isn't prioritizing SRTP in that instance, when it should, and forcing proves it works, when the phone gives it no other option.... The external trunk legs remain with SRTP in all flow cases.

Yep this, it will group them into their matching domain ID's in the yealink device management portal, matching the PBX layout. If you link your RPS to your DM, when the phone provisions it automatically creates the domain in DM and gives it a unique site ID, just the phone does not populate into that ID without being told as part of its configuration.

Attempting to get loop back working so if you dial another on-net so to speak DID that's on the PBX it will connect internally. I notice on loopback it wants to UPDATE the SIP Contact to say, 200@125.125.125.125 i.e extension@rawip from the extension@domain original contact. I suspect my loop back calls are not working when testing because I have , Ignore packets that do not match a domain on the system turned on, is there a way to do it preserving the contact domain? I can see otherwise its matching to the other domain no problem

In an effort to get every thing squared away with TLS and SRTP, I am reviewing config's and pcap's and question the following, in the built in Yealink common. #Specify whether to encrypt the SIP messages; 0-Disabled (default), 1-Optional, 2-Forced; account.{lc}.srtp_encryption = {outbound-secure tcp 1 0} Where is it pulling outbound-secure from to decide? should it not be some thing like this, I just made it up based on how the rest of the config treats TLS using the domain setting. #Specify whether to encrypt the SIP messages; 0-Disabled (default), 1-Optional, 2-Forced; account.{lc}.srtp_encryption = {outbound-layer tcp:udp/tcp/tls udp=0 tcp=1 tls=2} The entire system is set TLS default my inbound and outbound partners are TLS and SRTP , confirmed with PCAP's, even though the trunks are not forced they do negotiate SRTP as they should because its been offered. Carrier -> PBX -> Yealink Phone will be TLS + SRTP on all legs with the original setup {outbound-secure tcp 1 0} which translates into '1-Optional' on the phone its self. Yealink Phone -> PBX will never get SRTP negotiated when in '1-Optional' mode the rest of the legs have SRTP. The phone is offering SRTP in the invite, so is the PBX but does not seem to pick it. I have to use '2-Forced' for outbound calls from the phone to use it, not sure where to look more is it the PBX ignoring it ? or the Phone? Has any one messed around with it in depth ? Ideally I would like to keep it on Optional to allow the fall back if possible so calls cant fail if some thing goes wrong some where.

It can be a general pram as a quick fix, I am sure there would be a smarter way to do it as part of RPS based on some initial reading I was doing of their doc's, I will investigate that and come back. The phone talks back to Yealink DM with its known site ID when config is loaded if it's in your general prams and put's it into the correct entry within that portal, based on. ##DM YEALINK## dm.enterprise_id = abc123 dm.site_id = lmno123

Apparently, they just updated something with Bria iOS and now TLS is broken and wont register with the PBX. Apparently, something to do with this , RFC 5746 - Transport Layer Security (TLS) Renegotiation Indication Extension (ietf.org)

You could but then you would have to be copy and pasting the rest of your custom settings from the root level per domain, then when you want to make updates to some of those settings you will have to go through each domain one by one to update, not efficient. Basically, needs a new "input box" like Yealink General but for Site ID.

Hey team, I know its easy to add your Yealink global enterprise DM / Site ID to general pramas, but it would be ideal for a custom general prams per tenant/domain that covers this to help split the data with in that system for easy location and alerting from the Yealink side. I have not dived too deeply yet, but maybe its possible to do it on the level of the RPS config and map based on domain ID, aka Site ID/Region ID, like customerid.domain.com etc with customer ID being the key value, like how rps maps the provision request. thoughts ?

I tired OPUS only and still the same the first few seconds of connected call on the app are broken / jittered then smooths out, every time. 711A/U or Opus. Wi-Fi or LTE same. Bria Enterprise seems to be fine with the same tests. Confirmed with pcap that OPUS was being used.

Are you talking about accessing the phones Web Interface after its provisioned to the pbx ? If so, set your domain admin / password in the Settings -> General Settings of the given domain (at the bottom) then you can login to the phone's web interface as the admin with those details, you will need to re-sync the phone after updating the password. The base auto provision template will not overwrite custom settings as long as they are not included in yealink_common.txt or yealink general prams.

I hear you on the points raised in the first post, I was attempting to use 68 more to see if even 68 was viable it's kind of not, unless you spend heaps of time educating the users on its quirks. It's a shame as this being polished could be a real draw card. I found when you answer a call and then hold it, you can drag that call and drop it on the end user (blind) no problem. But if you hold the call then make a new call to the end user to speak to them first then end the call to drag the holding call to the person so it comes in as a new call it does nothing just ignores you and the call sits on hold you have to resume the call then drag it to the person. Yeah you can drag the holding call to the active call for a inflight transfer but then there is no ring back or alert tone to know they were merged. Also when clicking the transfer button and then dragging the staff member across it drags the whole block of all the people, looks unprofessional. Also if you drag a holding call over to a staff member but then change your mind and take it back to the 'My calls' and let go the call just drops..... Simple things like clicking the staff members profile pic/name should just default to calling them with the dots there available if you want to do something different. Its honestly a shambles. V68 should be fixed up to be at a decent working state before you move on to 69. It's like no one has actually used it when developing it? lol.

Is the mailbox setting you speak of a V69 feature ?

FYI, I have a solution. Old thread but it came up when I was looking. I have put up with this same issue for a while with Yealink's but have been dealing with it and training users accordingly. But I decided to actually spend some time looking today at the config and found a solution. Using DSS Key Deal Type 1 mode "Attended Transfer" has the best user workflow when using buttons, just no transfer reminder ability, which is important when you don't have a dedicated reception person and want the call to go back to the original person. Any way if you are setup to use DSS Key Deal Type 1 in the yealink parameters and want to still get transfer back reminder ability when the user presses the DSS Key to start the transfer and either hangs up to complete transfer or presses the transfer softkey while in flight during ring back it will switch the call to a blind transfer and follow the reminder logic and call back to the original person based on the pbx reminder time, all while keeping the benefits of using type 1 on Yealinks. Add this extra line to add to your general prams, transfer.semi_attend_tran_enable = 0 Tested on T5x Range, will post back once I check T4x Basically, your transfer key options in the phone's web interface should look like this.

I presume the MOS graphs graph the trunk side and the customer side hence the weight of the dot's, would it not be possible to colour the trunk dots differently? When reviewing the global MOS scores, I noticed some zero ones which must be no media.., so Investigated customers to locate, once located I then went through the extensions to try find the one responsible but was not able to, so I presumed some of the graphed dots must be the trunk side?

I thought it might be wise to jump in here on the comment on using the Yealink General parameter. It's great to be able to drop in commands to include in the config and see my base changes; however, the level where it's applied in the master config needs to be changed, as some settings used in the general parameters get overwritten with the common file. For example, I wanted to set a random midnight-to-3am resync of phones so that when button template changes are made or an extension has been renamed, they will be synced to the other phones via the button template after midnight and you don't have to resync manually, and I just advise people accordingly. ##daily autop for button renames## static.auto_provision.weekly.enable = 1 static.auto_provision.weekly.begin_time = 0:00 static.auto_provision.weekly.end_time = 3:00 static.auto_provision.weekly.dayofweek = 0123456 I placed the {parameter yealink-general} at the end of the file, whereas the above example would not fully apply as there were already defined settings for some of these. That is just one example but there have also been others for the same reasons.

A PBX reload works for the ring tones. I was able to remove some ring back tones after reload, but not all. Strange behaviour like it has an open call to the file some where?.

Yeah, might have done the inverse. I used to be able to remove ring back / general audio, but that's not working now. I can remove ring Melodys now. I confirmed the ring back/general audio files are not being used in any domain or system settings, but it won't remove, I also can't preview play the file. Something does not feel right, for example if I upload a custom ringer from the famous 24 TV show The best ring tone.... and upload it to replace Ringer 6, which is a very hash ringer. it uploads and the description reflects everywhere under sub domains however when previewing the file, it still plays the old ringer, maybe a system reboot is needed when replacing them. ctu-external.wav

Not sure if I missed it but was this added to any build yet? I don't even seem to be able to delete ring back/general audio files now either under the main tenant upload audio section. 68.0.30

Not sure if I am following you. The PBX has direct WAN IP attached to interface, and I am using, {ip-address}. , Should this not replace with the WAN/Interface IP? Log level 9 looks like this, nothing further happens. The PCAP that shows up for this attempt has <sip:number@{x-pre-adr}> no IP data.

I have a need on a trunk where I need to define the from header as. <sip:{ext-ani}@{ip-address}> I used {ip-address} based on, Trunk Custom Headers (vodia.com) however, in PACP when using I see its replaced as <sip:123456789@{x-pre-adr}> with no IP data. just the include statement. Anyone have any thoughts?