Jump to content

Scott1234

Members
  • Posts

    207
  • Joined

  • Last visited

Posts posted by Scott1234

  1. 11 hours ago, Vodia PBX said:

    Hmm actually not sure. There were some changes with the identification with the trunk, and that could have to do with Teams. I guess we'll find out! But I know that the net mask was causing a lot of erratic problems with Teams trunks that were set up versions ago when the associated IP addresses were a much smaller range.

    It was really just the label. The settings internally were not affected so that you don't have to change anything, it will just show on the front end the other way around and hopefully now makes sense.

    Great,

    Can you give a bit more insight on these, just curious to its creation to better understand the use case and or effects

    • Added global setting provserv2 for Yealink
    • Find the right trunk with trunk domain match and IP

    thanks 

  2. Thanks, the zoho fix will be apricated by my zoho customers that log in and out of agent groups a lot.

    Does this teams related fix's fix being able to use teams call park? 

    Label for night more active/inactive was wrong - Does this mean the service flag naming difference between auto attendant and call queue?

  3. 1 minute ago, Vodia PBX said:

    Well maybe we should just split the V68 Windows app from the V69 Windows app. Then we can just freeze the 68 app pretty much and don't have to deal with this when we add stuff to the V69 app.

    FYI I think that post was before the 6.0.4 version it was the new version before the new new version ... ha ha. 

    6.0.4 is ok at the moment. 

  4. Just had a random thought, in the PBX it would be nice to have a column called something like "Ref" for reference to click to see everywhere that object is referenced/used. 

    FortiGate's do it so you can quickly find stuff where you have set it up and using it and thought that would be handy on the PBX. Such as finding everywhere a service flag has been set to be used ... 

    Any ways that's it :D

     

  5. Hey, this one has all ways thrown me, I think it's been around for a while and needs addressing. There is a difference between Call Queue service flag logic and Auto Attendant service flag logic. (Manual flag testing) 

    In a Call Queue when you set "When service flag is active" and your flag is clear it will trigger the redirection flow. 

    In a Auto Attendant when you set "When service flag is active" and your flag is clear it does not process the redirection flow. 

    Based on the language the Auto Attendant is doing it correctly and the Call Queue is not. 

    v68.0.32 confirmed.

     

     

  6. On the topic of teams, I can never get the SBC to show up with options showing as working on the MS Admin console, ever. 

    On my test pbx (default sip ports) I can get TLS showing as working on MS end but not options.

    On my production system that uses non-standard sip ports, I can't get TLS or OPTIONS to show as working.

    Both work with regards to calls in and out, on the non-standard port one I found I had to define the port in the contact header on the trunk setup to get it to work, but yeah never had luck with TLS and OPTIONS. 

    It's why I was trying to install SNGREP and sniff general sip messages to find out what's going on the options requests. 

    Any input would be appreciated

  7. 10 hours ago, Vodia PBX said:

    The PBX has the option --key-log-address adr:port to tell sniffing tools what the TLS master key is. It then sends a UDP packet with the following content:

    {"cipher":"TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256","sessionid":"0123456789abcdef","mastersecret":"0123456789abcdef"}

    Is that something that sngrep could use as well?

    Not that I can see, you can compile it with openssl or gnutls and run it with a, -k flag to define rsa private keyfile, but using the keyfile setting on the pbx did not help.

    I just found this in their, FAQ page. says,

    I can't see TLS flows even using the private key
    sngrep only support a couple insecure cipthers (TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA and TLS_RSA_WITH_AES_256_GCM_SHA384), and needs to capture the initial TLS negotiation in order to decrypt the conversation. If you're using TLS v1.2 or greater with a DH or ECDH cipher, decrypting is impossible as these ciphers implement Perfect Forward Secrecy.

    So maybe no go. 

  8. Has anyone got SNGREP to work with TLS key support? on the pbx. 

    GitHub - irontec/sngrep: Ncurses SIP Messages flow viewer

    Screenshots · irontec/sngrep Wiki · GitHub

    It's my fav goto sip message explorer but since I have been on a mission to go full TLS and SRTP I am now in the dark :D but want to enjoy this tool again when needed for support. 

    EDIT > I know I can do pcaps from the pbx and get the decode, but sometimes this tool is better to use when listening globally, not just specific to the one call. 

     

  9. Just looking for a bit more info / guidance on this option under Settings -> Network -> Ports

    The Read content for global and domain files, the option, attempt to read files from tenant-specific directory. Not documented. 

    How do we make use of this and allow for a customer directory? I ask as when using a wildcard  DNS setup for customer domain ID's when you want to establish a team's SBC you need to verify the domain on MS and in doing so you need to create a static txt record that then breaks the wild card option for that domain, if I can place the txt file verification on the PBX side instead in a customer folder that is read when the customer URL, i.e. https://customer.pbx.com/ms12345.txt is requested I can avoid having to statically set DNS to auth the SBC on MS.

    I know way back when in the old days I recall a folder on the PBX with copies of all the config files extensions generated etc with the customer id as the folder, is that was this is?

    Would this scenario work with this option enabled?

  10. 11 hours ago, desiredeabn said:

    Any luck with this? Just started setting up today and am running in to the same issue

    I find it to do with, explicitly list addresses for inbound traffic. The addresses included by default in the trunk are outdated.

    The list should be, for most. 

    52.112.0.0/14 52.120.0.0/14

    https://learn.microsoft.com/en-us/microsoftteams/direct-routing-plan#microsoft-365-office-365-and-office-365-gcc-environments-1

    Secondary to that it's typically something to do with the 

    Rewrite global numbers section of the trunk and country code and Trunk may terminate calls for remote systems

    I still think their implementation of how-to setup the user is wrong, but the pbx is the problem and needs the team's part reworked. We should be able to setup the user elements as, 

    Set-CsPhoneNumberAssignment -Identity user4@contoso.com -PhoneNumber "+14255551000;ext=1234" -PhoneNumberType DirectRouting

    So that the users DID can show up in their teams client. 

    https://learn.microsoft.com/en-us/powershell/module/teams/set-csphonenumberassignment?view=teams-ps#example-6

    https://learn.microsoft.com/en-us/powershell/module/teams/set-csphonenumberassignment?view=teams-ps#-phonenumber

    I still have issues but with parking and retrieving with in teams side not working and the caller gets dropped. Transferring / consult transfers are finnicky when it comes to external to the system transfers. FYI Trunk may terminate calls for remote systems must be enabled to allow external transfer function to work.

    I think its best only used to make and take calls, if you need to start parking and transferring it becomes a bit finnicky, receptionists stay away. 

    If anyone can share me a full config guide of it all working, I will be happy. 

  11. It could be to do with sleeping tabs that a lot of browsers use now a days, you can explicitly define what not to ever sleep.  Or use the stand-alone web app from the app store, I have found this works better sometimes, when it comes to users and different org security policy's and making sure the user knows to allow access to microphone / speaker etc, the standalone app makes it somewhat full proof.  

  12. 12 hours ago, Vodia PBX said:

    This is because of the setting "Ignore packets that do not match a domain on the system" (in /reg_security.htm). It's a good idea to have that turned on. 

    There are two things you can do here. First, you can use the system management DNS address as a fallback address for devices that don't support the TLS SNI extension. Second, if that is not possible, you can set the setting sni_sip_ldap to true, this will override the "ignore packets..." for SIP and LDAP.

    Oh and you should retrovision your phonses. The templates should automatically set everything right. 

    Thanks, I will check into SNI support on the external SBC. As I prefer to use "Ignore Packets" setting. This was working fine on the old version, is this part of a fix to support secure TLS renegotiation properly as for why its stopped working on this version?

    Back to call Q and not ringing, I have to set the "Extension feature set" as "Call Queue" Agent vs "Regular Extension" for it to ring, is this the expected setup now?  what happens if that user also wants teams? what is the new "all function levels" setting?

  13. When I upgrade from 68.0.32 to 69.1.1  I can no longer receive inbound calls from the external SBC. (This is not specific to 69.1.1, it's just the first time I have tested an in-place upgrade or 69 at all)

    What is it looking for that is different to 68.0.32 with regards to client hello ?

    I use TLS everywhere, end to end normally. Switching to UDP will make it work.

    [9] 15:48:47.759	SIP xxx.xxx.xxx.xxx:43985: Receive Client Hello(0303D0F6..00000000)ⓘ
    [9] 15:48:47.759	SIP xxx.xxx.xxx.xxx:43985: Client Hello TLS version(0303)ⓘ
    [6] 15:48:47.759	SIP xxx.xxx.xxx.xxx:43985: Session DFFC6302..7562B1F0 not foundⓘ
    [9] 15:48:47.759	SIP xxx.xxx.xxx.xxx:43985: Matched cipher suite TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256ⓘ
    [9] 15:48:47.759	SIP xxx.xxx.xxx.xxx:43985: Enabled secure renegotiationⓘ
    [8] 15:48:47.759	SIP xxx.xxx.xxx.xxx:43985: Client hello did not match any known address, ignoring itⓘ

     

    Edit - When I make a call q for testing and log myself in my phone wont ring, I just gets the hold music and waits in the queue, I don't get it? all the settings look fine.  Direct calls to phone work or hunt groups etc. Has there been some fundamental setting changes changed that I am missing? I could not spot anything. 

  14. 17 minutes ago, Vodia PBX said:

    A common pitfall is to enable "VIP" permission to an extension to hide the CDR in the group. Then the PBX does not keep those CDR. 

    Thanks, I checked not the case here. Plus also its random some times ok some times not but very random when it happens. Have not seen it for a while again, but will be on the look out.

×
×
  • Create New...