Extensions Of Sip Trunk

Home » Asterisk Users » Extensions Of Sip Trunk
Asterisk Users 4 Comments

Hi,

I just started with setting up a new asterisk system, that will operate on a sip trunk, but I wonder, how to transfer the calls to different extensions, because all calls appear as being send to the base number of the trunk.

E.g. given the trunk range of 1234567800-12345678099, a call to 1234567800 is matched by the same pattern as a call to 12345678099.

; matches 12345678099, too exten => _1234567800,1,Dial(SIP/int)

Except from SIP invite with tcpdump:

INVITE sip:123456780000@provider:5060 SIP/2.0
From: ;tag=as6bc7cbbc To:

I wonder, if I really need to grab the extension with Set(DN=${SIP_HEADER(TO):5}) or something similar?

Another issue is, that I don’t like asterisk to decline foreign INVITE
requests. Any best practices from within asterisk on how to ignore SIP
invitations, that don’t match certain criteria (neither local nor from sip provider)?

System: openSUSE 42.2, Asterisk 14.5.0

Thanks in advance, Pete

4 thoughts on - Extensions Of Sip Trunk

  • 12345678099 doesn’t match _1234567800. The problem is the other side is setting the R-URI to sip:123456780000@provider for any number, so the EXTEN matched in the dialplan is 123456780000. Ask them to fix this problem.

    Yes, something like if they can’t fix the R-URI:
    exten => X_.,n,Set(TO=${CUT(SIP_HEADER(To),@,1)})
    exten => X_.,n,Set(TO=${CUT(TO,:,2)})
    exten => X_.,n,Goto(somewhereelsetopreventloops${TO},1)

    Don’t enable guest access, or send any unknown/guest to a context that will just hangup.

  • Hi Daniel,

    Will do.

    Sorry for the silly question, but how do I feed the TO variable back to the usual pattern matching? Assign to $EXTEN?

    Hmm, tried allowguest=no in general sip.conf section, but this results in asterisk responding with on INVITE from provider, and (valid) calls get blocked.

    Thanks, Pete

  • The goto does that (with fixed typo):
    exten => X_.,n,Goto(somewhereelsetopreventloops,${TO},1)

    The reason to send to another context where you handle specific DIDs is to prevent loops. _X. is kind of a wildcard, if there is no DID for the TO this will loop in _X.