Matching incoming calls from goip and freepbx14

Hello,

I’ve setup goip as a trunk to my freepbx installation everything seems to be fine. I’ve also setup an IVR and I want calls to the GSM number of goip to be answered by the IVR. It seems that I’m not able to do that. Basically I’ve configured goip to forward incoming calls to a non-existent extension on my pbx - 5000, then I have created an inbound route which matches for DID 5000 and invokes the ivr. THe sip output of an unsuccessful call is:

   > 0x7fd4041db290 -- Strict RTP learning after remote address set to: 10.25.0.47:10000
    -- Executing [[email protected]:1] ResetCDR("SIP/goip-trunk-1-00000025", "") in new stack
    -- Executing [[email protected]:2] NoCDR("SIP/goip-trunk-1-00000025", "") in new stack
    -- Executing [[email protected]:3] Progress("SIP/goip-trunk-1-00000025", "") in new stack
    -- Executing [[email protected]:4] Wait("SIP/goip-trunk-1-00000025", "1") in new stack
       > 0x7fd4041db290 -- Strict RTP switching to RTP target address 10.25.0.47:10000 as source
    -- Executing [[email protected]:5] Playback("SIP/goip-trunk-1-00000025", "silence/1&cannot-complete-as-dialed&check-number-dial-again,noanswer") in new stack
    -- <SIP/goip-trunk-1-00000025> Playing 'silence/1.slin16' (language 'en')
    -- <SIP/goip-trunk-1-00000025> Playing 'cannot-complete-as-dialed.slin16' (language 'en')
    -- <SIP/goip-trunk-1-00000025> Playing 'check-number-dial-again.slin16' (language 'en')
       > 0x7fd4041db290 -- Strict RTP learning complete - Locking on source address 10.25.0.47:10000
    -- Executing [[email protected]:6] Wait("SIP/goip-trunk-1-00000025", "1") in new stack
    -- Executing [[email protected]:7] Congestion("SIP/goip-trunk-1-00000025", "20") in new stack
[2018-10-02 19:09:22] WARNING[3366][C-00000023]: channel.c:5005 ast_prod: Prodding channel 'SIP/goip-trunk-1-00000025' failed
  == Spawn extension (from-internal, 5000, 7) exited non-zero on 'SIP/goip-trunk-1-00000025'
    -- Executing [[email protected]:1] Macro("SIP/goip-trunk-1-00000025", "hangupcall") in new stack
    -- Executing [[email protected]:1] GotoIf("SIP/goip-trunk-1-00000025", "1?theend") in new stack
    -- Goto (macro-hangupcall,s,3)
    -- Executing [[email protected]:3] ExecIf("SIP/goip-trunk-1-00000025", "0?Set(CDR(recordingfile)=)") in new stack
    -- Executing [[email protected]:4] NoOp("SIP/goip-trunk-1-00000025", " monior file= ") in new stack
    -- Executing [[email protected]:5] AGI("SIP/goip-trunk-1-00000025", "attendedtransfer-rec-restart.php,,") in new stack
    -- Launched AGI Script /var/lib/asterisk/agi-bin/attendedtransfer-rec-restart.php
    -- <SIP/goip-trunk-1-00000025>AGI Script attendedtransfer-rec-restart.php completed, returning 0
    -- Executing [[email protected]:6] Hangup("SIP/goip-trunk-1-00000025", "") in new stack
  == Spawn extension (macro-hangupcall, s, 6) exited non-zero on 'SIP/goip-trunk-1-00000025' in macro 'hangupcall'
  == Spawn extension (from-internal, h, 1) exited non-zero on 'SIP/goip-trunk-1-00000025'

However, if I change the inbound rule to match any did/cid then it works as expected:

 > 0x7fd4041e0980 -- Strict RTP learning after remote address set to: 10.25.0.47:10000
    -- Executing [[email protected]:1] NoOp("SIP/goip-1-00000026", "Catch-All DID Match - Found 5000 - You probably want a DID for this.") in new stack
    -- Executing [[email protected]:2] Log("SIP/goip-1-00000026", "WARNING,Friendly Scanner from 10.25.0.47") in new stack
[2018-10-02 19:10:46] WARNING[3766][C-00000024]: Ext. 5000:2 @ from-trunk: Friendly Scanner from 10.25.0.47
    -- Executing [[email protected]:3] Set("SIP/goip-1-00000026", "__FROM_DID=5000") in new stack
    -- Executing [[email protected]:4] Goto("SIP/goip-1-00000026", "ext-did,s,1") in new stack
    -- Goto (ext-did,s,1)
    -- Executing [[email protected]:1] Set("SIP/goip-1-00000026", "__DIRECTION=INBOUND") in new stack
    -- Executing [[email protected]:2] Gosub("SIP/goip-1-00000026", "app-blacklist-check,s,1()") in new stack
    -- Executing [[email protected]:1] GotoIf("SIP/goip-1-00000026", "0?blacklisted") in new stack
    -- Executing [[email protected]:2] Set("SIP/goip-1-00000026", "CALLED_BLACKLIST=1") in new stack
    -- Executing [[email protected]:3] Return("SIP/goip-1-00000026", "") in new stack
    -- Executing [[email protected]:3] ExecIf("SIP/goip-1-00000026", "0?Set(__FROM_DID=s)") in new stack
    -- Executing [[email protected]:4] Set("SIP/goip-1-00000026", "CDR(did)=5000") in new stack
    -- Executing [[email protected]:5] ExecIf("SIP/goip-1-00000026", "0 ?Set(CALLERID(name)=+359887xxxxx)") in new stack
    -- Executing [[email protected]:6] Set("SIP/goip-1-00000026", "__MOHCLASS=") in new stack
    -- Executing [[email protected]:7] Set("SIP/goip-1-00000026", "__REVERSAL_REJECT=FALSE") in new stack
    -- Executing [[email protected]:8] GotoIf("SIP/goip-1-00000026", "1?post-reverse-charge") in new stack

ALso during my testing I also came accross a situation where even with the catch-all rule the call is still not handled by freepbx. My goip sip trunk is as follows:

Outgoing:
host=10.25.0.47
port=5060
context=from-internal
insecure=port,invite
qualify=yes
secret=xxxxxxxx
type=peer
nat=no
canreinvite=no
dtmfmode=rfc2833

Inbound:
Usercontext: goip-1
host=dynamic
dtmfmode=rfc2833
canreinvite=no
qualify=yes
secret=xxxxxxx
type=friend
context=from-trunk

I’m afraid you are confused here.

Can you explain what you are trying to accomplish?

You have a DID 5000?

Where did you enter 5000? Can you post a screenshot of your Inbound routes?

Set context to from-trunk for the outgoing peer details as well.

1 Like

I managed to solve this thanks to someone on irc. The problem was indeed the usage of context from-internal on the outgoing peers. I ended up configuring only a single peer for the outgoing with context from-trunk. I find the configuration of trunks a bit counter intuitive since you only need to configure just the outbound peer to have both inbound and outbound access to it.

It’s only counter-intuitive if you believe that the context is for anything but an inbound call. You can’t set the context for an outbound call - it’s already in a context at that point and you are processing. Even with an extension, the call context you are using is for the leg that is inbound to the PBX (from the extension).

The terms Incoming and Outgoing as used to describe the tabs in the chan_sip trunk config are misleading. Regrettably, my imperfect mastery of lexicography betrays a dearth of suitable hallmarks that might serve as an improvement.

2 Likes

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.