Signalwire.com Vitalpbx Support

VitalPBX Community Support Wish List Signalwire.com Vitalpbx Support

  • Post
    voiprehberi
    Participant
    Up
    1
    Down
    ::

    Hi,

    I want to use signalwire.com with my vitalpbx pbx server. Can you contact them and add the vitalpbx option into connectors section please ?

     

    0
Viewing 15 replies - 16 through 30 (of 30 total)
  • Replies
    Up
    -1
    Down
    ::

    I recommend you disable the SIP Guest feature because is not secure at all, and also, make sure you’ve applied changes correctly.

    0
    Up
    -1
    Down
    ::

    Also, I’ve added this to the incoming section

    0
    InTeleSync
    Participant
    Up
    -1
    Down
    ::

    I set to allow guests to at least try to get the calls in, per your recommendation over here: https://vitalpbx.org/en/community/general-discussion/inbound-calls-not-working/#post-1120

    I’m at least getting the calls in, but my results are obviously radically different from your’s. Recognize I’m in multi-tenant mode, with these tests and DIDs running through the main tenant.

    [2020-02-18 12:21:48] WARNING[2205][C-00000002]: chan_sip.c:10431 process_sdp: Declining non-primary audio stream: audio 11668 RTP/AVP 0 8 101 13
    > 0x7fbbbc006810 -- Strict RTP learning after remote address set to: 167.99.107.109:11668
    -- Executing [signalwire@default-trunk:1] Gosub("SIP/signalwire-trunk-in-00000001", "set-global-tenant-vars,s,1") in new stack
    -- Executing [s@set-global-tenant-vars:1] NoOp("SIP/signalwire-trunk-in-00000001", "Setting Global Vars for vitalpbx Tenant") in new stack
    -- Executing [s@set-global-tenant-vars:2] Set("SIP/signalwire-trunk-in-00000001", "__TENANT_PATH=4dd074781b0a1660") in new stack
    -- Executing [s@set-global-tenant-vars:3] Set("SIP/signalwire-trunk-in-00000001", "__TENANT_PREFIX=") in new stack
    -- Executing [s@set-global-tenant-vars:4] Set("SIP/signalwire-trunk-in-00000001", "__QUEUE_AGENTS_CONTEXT=queue-call-to-agents") in new stack
    -- Executing [s@set-global-tenant-vars:5] Set("SIP/signalwire-trunk-in-00000001", "__FOLLOWME_CONTEXT=ext-followme") in new stack
    -- Executing [s@set-global-tenant-vars:6] Set("SIP/signalwire-trunk-in-00000001", "__HINTS_CONTEXT=extension-hints") in new stack
    -- Executing [s@set-global-tenant-vars:7] Set("SIP/signalwire-trunk-in-00000001", "__DEFAULT_COS=cos-all") in new stack
    -- Executing [s@set-global-tenant-vars:8] Return("SIP/signalwire-trunk-in-00000001", "") in new stack
    -- Executing [signalwire@default-trunk:2] Gosub("SIP/signalwire-trunk-in-00000001", "sub-check-blacklist,s,1(4dd074781b0a1660,+13862467330)") in new stack
    -- Executing [s@sub-check-blacklist:1] NoOp("SIP/signalwire-trunk-in-00000001", "Testing if +13862467330 is in Black List") in new stack
    -- Executing [s@sub-check-blacklist:2] GotoIf("SIP/signalwire-trunk-in-00000001", "0?banned") in new stack
    -- Executing [s@sub-check-blacklist:3] Return("SIP/signalwire-trunk-in-00000001", "") in new stack
    -- Executing [signalwire@default-trunk:3] Gosub("SIP/signalwire-trunk-in-00000001", "sub-setup-call-type,s,1(incoming)") in new stack
    -- Executing [s@sub-setup-call-type:1] NoOp("SIP/signalwire-trunk-in-00000001", "Determinating Call Type") in new stack
    -- Executing [s@sub-setup-call-type:2] GotoIf("SIP/signalwire-trunk-in-00000001", "0?return") in new stack
    -- Executing [s@sub-setup-call-type:3] Gosub("SIP/signalwire-trunk-in-00000001", "s-incoming,1()") in new stack
    -- Executing [s-incoming@sub-setup-call-type:1] NoOp("SIP/signalwire-trunk-in-00000001", "Incoming Call") in new stack
    -- Executing [s-incoming@sub-setup-call-type:2] Set("SIP/signalwire-trunk-in-00000001", "__CALL_TYPE=2") in new stack
    -- Executing [s-incoming@sub-setup-call-type:3] Set("SIP/signalwire-trunk-in-00000001", "__CALL_TYPE_LABEL=IN") in new stack
    -- Executing [s-incoming@sub-setup-call-type:4] Return("SIP/signalwire-trunk-in-00000001", "") in new stack
    -- Executing [s@sub-setup-call-type:4] Set("SIP/signalwire-trunk-in-00000001", "__CALL_TYPE_CONFIGURED=yes") in new stack
    -- Executing [s@sub-setup-call-type:5] Set("SIP/signalwire-trunk-in-00000001", "CDR(calltype)=2") in new stack
    -- Executing [s@sub-setup-call-type:6] Return("SIP/signalwire-trunk-in-00000001", "") in new stack
    -- Executing [signalwire@default-trunk:4] Gosub("SIP/signalwire-trunk-in-00000001", "dynamic-routing-in,s,1(+13862467330)") in new stack
    -- Executing [s@dynamic-routing-in:1] NoOp("SIP/signalwire-trunk-in-00000001", "Test if must to apply dynamic routing") in new stack
    -- Executing [s@dynamic-routing-in:2] Set("SIP/signalwire-trunk-in-00000001", "EXTERNAL_CALLER=+13862467330") in new stack
    -- Executing [s@dynamic-routing-in:3] Set("SIP/signalwire-trunk-in-00000001", "DYNROUTING_DM=0") in new stack
    -- Executing [s@dynamic-routing-in:4] GotoIf("SIP/signalwire-trunk-in-00000001", "1?gd") in new stack
    -- Goto (dynamic-routing-in,s,6)
    -- Executing [s@dynamic-routing-in:6] GotoIf("SIP/signalwire-trunk-in-00000001", "0?:rb") in new stack
    -- Goto (dynamic-routing-in,s,11)
    -- Executing [s@dynamic-routing-in:11] Return("SIP/signalwire-trunk-in-00000001", "") in new stack
    -- Executing [signalwire@default-trunk:5] Goto("SIP/signalwire-trunk-in-00000001", "incoming-calls,signalwire,1") in new stack
    -- Goto (incoming-calls,signalwire,1)
    -- Channel 'SIP/signalwire-trunk-in-00000001' sent to invalid extension: context,exten,priority=incoming-calls,signalwire,1
    -- Executing [i@incoming-calls:1] NoCDR("SIP/signalwire-trunk-in-00000001", "") in new stack
    -- Executing [i@incoming-calls:2] Goto("SIP/signalwire-trunk-in-00000001", "invalid-dest,s,1") in new stack
    -- Goto (invalid-dest,s,1)
    -- Executing [s@invalid-dest:1] NoOp("SIP/signalwire-trunk-in-00000001", "Invalid Route to Dial") in new stack
    -- Executing [s@invalid-dest:2] GotoIf("SIP/signalwire-trunk-in-00000001", "0?end") in new stack
    -- Executing [s@invalid-dest:3] Playback("SIP/signalwire-trunk-in-00000001", "im-sorry&no-route-exists-to-dest&vm-goodbye") in new stack
    -- <SIP/signalwire-trunk-in-00000001> Playing 'im-sorry.ulaw' (language 'en')
    > 0x7fbbbc006810 -- Strict RTP switching to RTP target address 167.99.107.109:11668 as source
    -- <SIP/signalwire-trunk-in-00000001> Playing 'no-route-exists-to-dest.ulaw' (language 'en')
    -- <SIP/signalwire-trunk-in-00000001> Playing 'vm-goodbye.ulaw' (language 'en')

    Attached are the general trunk settings.

    0
    InTeleSync
    Participant
    Up
    -1
    Down
    ::

    Device for Outgoing Calls (Peer)

     

    0
    InTeleSync
    Participant
    Up
    -1
    Down
    ::

    Device for Incoming Calls (User)

    Along with the Registry String.

     

    0
    Up
    -1
    Down
    ::

    I think the problem is that SignalWire sends incoming calls from different IPs, so, when the asterisk receives the call, there’s no trunk configured with that IP, and calls get rejected.

    In this case, I am receiving the call from IP 159.65.244.171, and calls get rejected. Previously I was receiving calls from IP 104.248.176.184 and it was working.

    So, it is not needed to define the inbound route section. actually it is needed to create one trunk for each IP that SignalWire uses for sending incoming calls.

    0
    InTeleSync
    Participant
    Up
    -1
    Down
    ::

    Perhaps we need to be ditching SIP here and going PJSIP and the ability to Match. I have PJSIP registering okay with successful outbound. Inbound nothing. Same result as if when using SIP with Allow Guest = no.

     

    0
    Up
    -1
    Down
    ::

    For using PJSIP, you must change the SIP ports to 5062, and set the PJSIP ports to 5060, I mean, Set PJSIP as the primary protocol for SIP stuff.

    0
    InTeleSync
    Participant
    Up
    -1
    Down
    ::
    Posted by: @ing-joserivera26

    actually it is needed to create one trunk for each IP that SignalWire uses for sending incoming calls.

    What would this look like in VitalPBX?

     

     

    0
    Up
    -1
    Down
    ::

    @intelesync

    I have create the following file

    /etc/asterisk/ombutel/sip__70-1-signalwire.conf

    with the following content inside

    [signalwire1](signalwire-trunk)
    host=159.65.244.171

    [signalwire2](signalwire-trunk)
    host=45.32.95.52

    [signalwire3](signalwire-trunk)
    host=178.128.235.81

    [signalwire4](signalwire-trunk)
    host=104.248.176.184

    In this way I inherit the main trunk settings, and only changing the host value, to match any incoming call with the correct trunk.

     

    0
    InTeleSync
    Participant
    Up
    -1
    Down
    ::

    Excellent! I tried the config file method, but unfortunately am still getting the “no route exists” recording. However, it led me to create the four trunks directly, one for each known IP address from SignalWire, and inbound and outbound are working perfectly now.

    Attached are settings for one of those trunks.

    Thanks @ing-joserivera26 for your work on this!

     

    0
    Up
    -1
    Down
    ::

    Did you remove the inbound section in the trunk definition?

    Did you create this trunk on the main tenant, I mean, In the administrative tenant (VitalPBX)?

    How many trunks do you have created on the VitalPBX GUI using this provider?

    0
    InTeleSync
    Participant
    Up
    -1
    Down
    ::

    Yes, yes and four. Attached is what is looks like. I’m happy with what we’ve got, primarily so that other staff can see what is needed without having to know about custom configs in the CLI.

    0
    Up
    -1
    Down
    ::

    Do you have a call log of an incoming call?

    0
    InTeleSync
    Participant
    Up
    0
    Down
    ::
    For more clarity on this… SignalWire does not have an option for specifying a destination port for SIP endpoints attached to them. That means that if you run your PJSIP through 5062 and secure PJSIP through 5063, you cannot receive your calls from SignalWire. They will only send back via 5060/5061.

    They are the only intermediate SIP trunking provider I’ve run across that does not provide this capability to alter the destination port for their endpoints.

    Yes I am aware I could change my entire infrastructure to run PJSIP through 5060. That is not practical for thousands of devices and endpoints, nor do I want to – I actually LIKE running on non-standard 5062/3 for a myriad of reasons, not the least of which is security.

     

    0
Viewing 15 replies - 16 through 30 (of 30 total)
  • The forum ‘Wish List’ is closed to new topics and replies.