COS Allows forwarding calls to another private COS

VitalPBX Community Support General Discussion COS Allows forwarding calls to another private COS

  • Post
    PitzKey
    Participant
    US
    Hello everyone,

    We have two Classes of Services, 1 called ABC one called XYZ. Both COSs are private and they cannot call each other.

    4700 Is under XYZ and 102 is under ABC.

    When 4700 receives a call, the can press forward and then forward the call to 102. Why?

    We see in the logs:

    [2020-12-08 10:59:52] VERBOSE[130340][C-00006559] app_dial.c: Called SIP/T3_4700
    [2020-12-08 10:59:52] VERBOSE[130340][C-00006559] app_dial.c: SIP/T3_4700-0000d34f is ringing
    [2020-12-08 10:59:52] VERBOSE[130328][C-00006559] app_dial.c: Local/4700@T3_ivr-only-extensions-00005a11;1 is ringing
    [2020-12-08 10:59:59] VERBOSE[69574][C-00006559] chan_sip.c: Got SIP response 302 "Moved Temporarily" back from 71.246.127.18:13372
    [2020-12-08 10:59:59] VERBOSE[130340][C-00006559] app_dial.c: Now forwarding Local/4700@T3_ivr-only-extensions-00005a11;2 to 'Local/102@T3_cos-XYZ' (thanks to SIP/T3_4700-0000d34f)
    [2020-12-08 10:59:59] VERBOSE[130340][C-00006559] app_dial.c: Not accepting call completion offers from call-forward recipient Local/102@T3_cos-XYZ-00005a12;1
    [2020-12-08 10:59:59] VERBOSE[130328][C-00006559] app_dial.c: Local/4700@T3_ivr-only-extensions-00005a11;1 redirecting info has changed, passing it to SIP/SIPProvider-0000d34e
    [2020-12-08 10:59:59] VERBOSE[130328][C-00006559] app_dial.c: Local/4700@T3_ivr-only-extensions-00005a11;1 stopped sounds
    [2020-12-08 10:59:59] VERBOSE[130353][C-00006559] pbx.c: Executing [102@T3_cos-XYZ:1] NoOp("Local/102@T3_cos-XYZ-00005a12;2", "More than on digit pattern") in new stack
    [2020-12-08 10:59:59] VERBOSE[130353][C-00006559] pbx.c: Executing [102@T3_cos-XYZ:2] Gosub("Local/102@T3_cos-XYZ-00005a12;2", "s,1(102)") in new stack

    And then

    [2020-12-08 10:59:59] VERBOSE[130353][C-00006559] pbx.c: Executing [102@sub-local-dialing:6] Gosub("Local/102@T3_cos-XYZ-00005a12;2", "sub-check-cos-privacy,s,1(T3_cos-ABC,26,T3_cos-XYZ)") in new stack
    [2020-12-08 10:59:59] VERBOSE[130353][C-00006559] pbx.c: Executing [s@sub-check-cos-privacy:1] NoOp("Local/102@T3_cos-XYZ-00005a12;2", "Checking Privacy of CoS: T3_cos-ABC") in new stack
    [2020-12-08 10:59:59] VERBOSE[130353][C-00006559] pbx.c: Executing [s@sub-check-cos-privacy:2] GotoIf("Local/102@T3_cos-XYZ-00005a12;2", "0?:no_local") in new stack
    [2020-12-08 10:59:59] VERBOSE[130353][C-00006559] pbx_builtins.c: Goto (sub-check-cos-privacy,s,15)
    [2020-12-08 10:59:59] VERBOSE[130353][C-00006559] pbx.c: Executing [s@sub-check-cos-privacy:15] NoOp("Local/102@T3_cos-XYZ-00005a12;2", "No Local Call, Allow any CoS") in new stack
    [2020-12-08 10:59:59] VERBOSE[130353][C-00006559] pbx.c: Executing [s@sub-check-cos-privacy:16] Goto("Local/102@T3_cos-XYZ-00005a12;2", "return") in new stack

    “No Local Call, Allow any CoS”

    Full log: https://pastebin.com/KWyehHsF

    Is there a way to prevent this?

    Thank you

    0
Viewing 9 replies - 1 through 9 (of 9 total)
  • Replies
    Up
    0
    Down
    It allows the call because comes from outside. If you try to do an attended transfer, then, the call will be rejected because Asterisk opens a new channel, but, if you do a blind transfer, then, Asterisk uses the same channel (That is already flagged as an incoming call) to do the transfer.
    0
    PitzKey
    Participant
    US
    Up
    0
    Down
    Well, if it rang before am extension in T3_cos-XYZ then don’t allow the call to proceed to T3_cos-ABC.

    Even more to that, if 102 is not in T3_cos-XYZ, simply don’t allow calling 102@T3_cos-XYZ no matter if it’s internal or external. Properly routed calls will go to 102@T3_cos-ABC

    This is really an issue.

    0
    Up
    0
    Down
    If 102 receives an external call and does a blind transfer the call is transferred because the call has been flagged as incoming external.
    0
    PitzKey
    Participant
    US
    Up
    0
    Down
    That is true. But if 4700 is part of XYZ and 102 is part of ABC, you wouldn’t allow 4700 to dial 102@T3_cos-XYZ. Right?

    Same, don’t allow any call to dial 102@T3_cos-XYZ

    0
    PitzKey
    Participant
    US
    Up
    0
    Down
    Does anyone know of a way to prevent this from happening?

    Thanks

    0
    Up
    0
    Down
    On internal calls, this rule is applied, but for blind transfer from external calls, this rule is ignored.

    You can try with attended transfers.

     

    0
    PitzKey
    Participant
    US
    Up
    0
    Down
    Exactly, this defeats the entire idea of COS if a user can send calls between COS. This rule should be applied regardless if this is an internal or external call.

    It’s an administrator’s responsibility to make sure external calls are routed properly, VitalPBX should not be ignoring the COS rules on external calls!!!.

    0
    Up
    0
    Down
    You might try editing the base plan file (extensions__20-baseplan.conf), and change the second line of the context “sub-check-cos-privacy” with this:

    same => n,GotoIf($[$["${CALL_TYPE}"="1"]|$["${LEN(${BLINDTRANSFER})}"!="0"]]?:no_local)

    Let me know if this works for you.

    0
    PitzKey
    Participant
    US
    Up
    0
    Down
    Hello Jose,

    <RANT>

    I’m trying to reply for the tenth time already, I can’t do it because it includes a pastebin link. This is very not user friendly. I even tried posting without the links and then edited, it got removed…. 🙁

    This is going to drive people away from the forums

    </RANT>

    Blind transfer is now properly being blocked, see log: (Posting it in a format the forum will not remove this post )

    pastebin dot com/raw/251H2Grk

    But cyou can still forward a call, see logs: (again, posting the link in a format, so this post is not getting removed)

    pastebin dot com/raw/AFCVZv7b

    Let me know if you need anything further.

     

    Thanks

    0
Viewing 9 replies - 1 through 9 (of 9 total)
  • You must be logged in to reply to this topic.