thr3ads.net - asterisk users - [asterisk-users] SIP trunks going to the wrong context [Dec 2017]

If this information is useful, please help other people find it:
Share via:

Ade Vickers

2017-Dec-14 21:10 UTC

[asterisk-users] SIP trunks going to the wrong context

Hi all,

I'm trying to resolve a weird issue with SIP routing.

I have a number of SIP trunks, from a selection of providers, all of 
which are registered in sip.conf:

    [general]
    context=default
    allowguest=no
    allowoverlap=no
    udpbindaddr=0.0.0.0
    tcpenable=yes
    tcpbindaddr=0.0.0.0
    transport=udp
    bindport=15060
    srvlookup=yes
    allowsubscribe=yes
    limitonpeers=yes
    callcounter=yes
    vmexten=5199
    nat=no

    ; SE registrations
    register => user1:password1 at sipgate.co.uk:5060/se2489
    register => user2:password2 at sipgate.co.uk:5060/se1268
    register => user3:password3 at sipgate.co.uk:5060/se0845
    register => user4:password4 at callcentric.com:5060/se1777
    register => user5:password5 at sipgate.co.uk:5060/se4130
    register => user9:password9 at sip.vohippo.com:5060/se1413

    ; SJ registrations
    register => user6:password6 at sipgate.co.uk:5060/sj0151
    register => user7:password7 at callcentric.com:5060/sj1777
    register => user8:password8 at sipgate.co.uk:5060/sj0203

I then have a selection of #included files. The first defines se2489:

    [se2489]
    type=friend
    insecure=port,invite
    secret=password1
    defaultuser=user1
    fromuser=user1
    fromdomain=sipgate.co.uk
    host=sipgate.co.uk
    port=5060
    outboundproxy=proxy.live.sipgate.co.uk
    disallow=all
    allow=ulaw
    context=external-se
    qualify=yes
    canreinvite=no
    dtmfmode=rfc2833

The second defines sj0151:

    [sj0151]
    type=friend
    insecure=port,invite
    secret=password6
    defaultuser=user6
    fromuser=user6
    fromdomain=sipgate.co.uk
    host=sipgate.co.uk
    outboundproxy=proxy.live.sipgate.co.uk
    disallow=all
    allow=ulaw
    context=sj-main
    regcontext=sj-main??? ?? ; Added to try to fix wrong context on IB calls
    subscribecontext=sj-main ; Added to try to fix wrong context on IB calls
    qualify=yes
    canreinvite=no
    dtmfmode=rfc2833

When an inbound call comes in to sj0151, I get the following error:

    NOTICE[10777][C-00000000]: chan_sip.c:26407 handle_request_invite:
    Call from 'user1' (217.10.79.23:5060) to extension 'sj0151'
rejected
    because extension not found in context 'external-se'.

Surely it should have looked in sj-main, not external-se?

Also, the "Call from 'user1' is always 'user1' no matter
which sipgate
account originated the call. The Callcentric numbers can't receive 
inbound calls, the vohippo number shows "Call from 'user9'" as
one would
expect. ALL of them look in context 'external-se', but the SJ 
registrations should all be looking in 'sj-main'. What's more, it
seems
to be struggling with pattern matching... The extension is passed 
correctly (albeit to the wrong context, for 3 of the numbers), so the 
following dialplan should pick them all up, surely?:

    [external-se]
    ; Transfer any call from any SE external trunk to the IVR @ the office.
    ; If the office is unavailable (no internet, for example), then go
    to voicemail)
    exten => _se.,1,Dial(IAX2/cloud/1000,30,r)
    same? => n,Voicemail(5000)
    same? => n,Hangup()

However, it simply doesn't work. If I replace _se. with _se2489. (or 
just se2489), it works fine (for calls arriving on the se2489 extension; 
obviously the others bork).


Can anyone tell me what I'm doing wrong, based on the above?

FWIW; this seems to have occurred because I've been attempting to prune 
my dialplan; I used to have them all going into a single context, and I 
picked them out & routed them individually. I am _trying_ to simplify 
the structure/mess that is extensions.conf... but as a result I ran into 
this little conundrum. The main problem is to resolve the "wrong 
context"; I have a suspicion I could fix the "can't find
extension"
problem by getting rid of the letters & using a purely numeric extension.

Many thanks,

Ade.

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20171214/98729d02/attachment.html>

Tony Mountifield

2017-Dec-14 22:05 UTC

head link

[asterisk-users] SIP trunks going to the wrong context

In article <f10ac6bb-665f-0423-7963-9124aef8e947 at
solutionengineers.com>,
Ade Vickers <asterisk at solutionengineers.com>
wrote:> Hi all,
> 
> I'm trying to resolve a weird issue with SIP routing.
> 
> I have a number of SIP trunks, from a selection of providers, all of 
> which are registered in sip.conf:
> 
>     [general]
>     context=default
>     allowguest=no
>     allowoverlap=no
>     udpbindaddr=0.0.0.0
>     tcpenable=yes
>     tcpbindaddr=0.0.0.0
>     transport=udp
>     bindport=15060
>     srvlookup=yes
>     allowsubscribe=yes
>     limitonpeers=yes
>     callcounter=yes
>     vmexten=5199
>     nat=no
> 
>     ; SE registrations
>     register => user1:password1 at sipgate.co.uk:5060/se2489
>     register => user2:password2 at sipgate.co.uk:5060/se1268
>     register => user3:password3 at sipgate.co.uk:5060/se0845
>     register => user4:password4 at callcentric.com:5060/se1777
>     register => user5:password5 at sipgate.co.uk:5060/se4130
>     register => user9:password9 at sip.vohippo.com:5060/se1413
> 
>     ; SJ registrations
>     register => user6:password6 at sipgate.co.uk:5060/sj0151
>     register => user7:password7 at callcentric.com:5060/sj1777
>     register => user8:password8 at sipgate.co.uk:5060/sj0203
> 
> I then have a selection of #included files. The first defines se2489:
> 
>     [se2489]
>     type=friend
>     insecure=port,invite
>     secret=password1
>     defaultuser=user1
>     fromuser=user1
>     fromdomain=sipgate.co.uk
>     host=sipgate.co.uk
>     port=5060
>     outboundproxy=proxy.live.sipgate.co.uk
>     disallow=all
>     allow=ulaw
>     context=external-se
>     qualify=yes
>     canreinvite=no
>     dtmfmode=rfc2833
> 
> The second defines sj0151:
> 
>     [sj0151]
>     type=friend
>     insecure=port,invite
>     secret=password6
>     defaultuser=user6
>     fromuser=user6
>     fromdomain=sipgate.co.uk
>     host=sipgate.co.uk
>     outboundproxy=proxy.live.sipgate.co.uk
>     disallow=all
>     allow=ulaw
>     context=sj-main
>     regcontext=sj-main?????? ???? ; Added to try to fix wrong context on IB
calls
>     subscribecontext=sj-main ; Added to try to fix wrong context on IB
calls
>     qualify=yes
>     canreinvite=no
>     dtmfmode=rfc2833
> 
> When an inbound call comes in to sj0151, I get the following error:
> 
>     NOTICE[10777][C-00000000]: chan_sip.c:26407 handle_request_invite:
>     Call from 'user1' (217.10.79.23:5060) to extension
'sj0151' rejected
>     because extension not found in context 'external-se'.
> 
> Surely it should have looked in sj-main, not external-se?
> 
> Also, the "Call from 'user1' is always 'user1' no
matter which sipgate
> account originated the call. The Callcentric numbers can't receive 
> inbound calls, the vohippo number shows "Call from
'user9'" as one would
> expect. ALL of them look in context 'external-se', but the SJ 
> registrations should all be looking in 'sj-main'. What's more,
it seems
> to be struggling with pattern matching... The extension is passed 
> correctly (albeit to the wrong context, for 3 of the numbers), so the 
> following dialplan should pick them all up, surely?:
> 
>     [external-se]
>     ; Transfer any call from any SE external trunk to the IVR @ the office.
>     ; If the office is unavailable (no internet, for example), then go
>     to voicemail)
>     exten => _se.,1,Dial(IAX2/cloud/1000,30,r)
>     same?? => n,Voicemail(5000)
>     same?? => n,Hangup()
> 
> However, it simply doesn't work. If I replace _se. with _se2489. (or 
> just se2489), it works fine (for calls arriving on the se2489 extension; 
> obviously the others bork).
> 
> 
> Can anyone tell me what I'm doing wrong, based on the above?
> 
> FWIW; this seems to have occurred because I've been attempting to prune
> my dialplan; I used to have them all going into a single context, and I 
> picked them out & routed them individually. I am _trying_ to simplify 
> the structure/mess that is extensions.conf... but as a result I ran into 
> this little conundrum. The main problem is to resolve the "wrong 
> context"; I have a suspicion I could fix the "can't find
extension"
> problem by getting rid of the letters & using a purely numeric
extension.
> 
> Many thanks,
> 
> Ade.
I think your problem is that the "/se2489" or "/sj0151" in
your register
statement (for example) is not used to select or match the inbound SIP
peer.

When the call comes in from sipgate, it probably doesn't have a fromuser.
The fromuser can be used to select the peer based on matching the [string]
that names the peer.

Otherwise, when Asterisk is looking for a matching peer section, I believe
it only matches on the host from which the call comes. So when your call
comes in from sipgate.co.uk, that is the only piece of information it uses,
and so it always matches the first one, irrespective of the registration
that originated the call.

So I think you really do need to have a single peer section for all sipgate
calls, pointing to one sipgate context in your dialplan that contains all
your various extensions like se2489, sj0151, etc.

Cheers
Tony
-- 
Tony Mountifield
Work: tony at softins.co.uk - http://www.softins.co.uk
Play: tony at mountifield.org - http://tony.mountifield.org

Frank Vanoni

2017-Dec-14 22:25 UTC

head link

[asterisk-users] SIP trunks going to the wrong context

I don't know if it applies to your problem, but I also had some
troubles with multiple account on same SIP provider.?
Here what works for me:


In sip.conf:


register => 111111:qwertz at sip.provider.zz/111111 ; Trunk1
register => 222222:asdfgh at sip.provider.zz/222222 ; Trunk2
register => 222222:yxcvbn at sip.provider.zz/222222 ; Trunk3


[trunk1]
type=friend
host=sip.provider.zz
defaultuser=111111
secret=qwertz
canreinvite=no
insecure=invite
nat=force_rport,comedia
qualify=yes
context=trunkincoming
description=Trunk 1

[trunk2]
type=friend
host=sip.provider.zz
defaultuser=222222
secret=asdfgh
canreinvite=no
insecure=invite
nat=force_rport,comedia
qualify=yes
context=trunkincoming
description=Trunk 2

[trunk3]
type=friend
host=sip.provider.zz
defaultuser=333333
secret=yxcvbn
canreinvite=no
insecure=invite
nat=force_rport,comedia
qualify=yes
context=trunkincoming
description=Trunk 3



In extensions.conf:

[trunkincoming]
exten => 111111,1,GoTo(firstline,111111,1)
exten => 222222,1,GoTo(secondline,222222,1)
exten => 333333,1,GoTo(thirdline,333333,1)

[firstline]
exten => 111111,1,Dial(SIP/officephone,120,m)

[secondline]
exten => 222222,1,Dial(SIP/livingroomphone,120,m)

[thirdline]
exten => 333333,1,Dial(SIP/bedroomphone,120,m)

Tony Mountifield

2017-Dec-14 22:53 UTC

head link

[asterisk-users] SIP trunks going to the wrong context

In article <1513290358.2926.4.camel at linuxista.com>,
Frank Vanoni <mailinglist at linuxista.com> wrote:> I don't know if it applies to your problem, but I also had some
> troubles with multiple account on same SIP provider.?
> Here what works for me:
> 
> 
> In sip.conf:
> 
> 
> register => 111111:qwertz at sip.provider.zz/111111 ; Trunk1
> register => 222222:asdfgh at sip.provider.zz/222222 ; Trunk2
> register => 222222:yxcvbn at sip.provider.zz/222222 ; Trunk3
> 
> 
> [trunk1]
> type=friend
> host=sip.provider.zz
> defaultuser=111111
> secret=qwertz
> canreinvite=no
> insecure=invite
> nat=force_rport,comedia
> qualify=yes
> context=trunkincoming
> description=Trunk 1
> 
> [trunk2]
> type=friend
> host=sip.provider.zz
> defaultuser=222222
> secret=asdfgh
> canreinvite=no
> insecure=invite
> nat=force_rport,comedia
> qualify=yes
> context=trunkincoming
> description=Trunk 2
> 
> [trunk3]
> type=friend
> host=sip.provider.zz
> defaultuser=333333
> secret=yxcvbn
> canreinvite=no
> insecure=invite
> nat=force_rport,comedia
> qualify=yes
> context=trunkincoming
> description=Trunk 3
> 
> 
> 
> In extensions.conf:
> 
> [trunkincoming]
> exten => 111111,1,GoTo(firstline,111111,1)
> exten => 222222,1,GoTo(secondline,222222,1)
> exten => 333333,1,GoTo(thirdline,333333,1)
> 
> [firstline]
> exten => 111111,1,Dial(SIP/officephone,120,m)
> 
> [secondline]
> exten => 222222,1,Dial(SIP/livingroomphone,120,m)
> 
> [thirdline]
> exten => 333333,1,Dial(SIP/bedroomphone,120,m)
But because you have all three of your trunk peers pointing to the
same context, you don't necessarily know whether the inbound calls
are matching different peers or all the same one.

If you had each trunk pointing at a different context, you would
probably run into the same problem as the OP.

Cheers,
Tony
-- 
Tony Mountifield
Work: tony at softins.co.uk - http://www.softins.co.uk
Play: tony at mountifield.org - http://tony.mountifield.org

Julian Beach

2017-Dec-15 17:58 UTC

head link

[asterisk-users] SIP trunks going to the wrong context

On Thursday, December 14, 2017, 10:05:23 PM, Tony Mountifield
(tony at softins.co.uk) wrote:
> So I think you really do need to have a single peer section for all sipgate
> calls, pointing to one sipgate context in your dialplan that contains all
> your various extensions like se2489, sj0151, etc.
That is what I do - all my incoming calls (which originate from the
same IP and Port) go into a single context in extensions.conf, from
where they are directed into individual call handlers depending on the
DCID

[incoming calls]

exten => 44********20,n,Goto(handler-a,s,1)
exten => 44********00,n,Goto(handler-b,s,1)
exten => 44********21,n,Goto(handlet-c,s,1)
exten => 44********22,n,Goto(handler d,s,1)

-- 
Best regards,
 Julian                            mailto:jb_soft at trink.co.uk

Possibly Parallel Threads

Search for more maybe matching threads

asterisk users - Dec 2017 - SIP trunks going to the wrong context

[asterisk-users] SIP trunks going to the wrong context

[asterisk-users] SIP trunks going to the wrong context

[asterisk-users] SIP trunks going to the wrong context

[asterisk-users] SIP trunks going to the wrong context

[asterisk-users] SIP trunks going to the wrong context

Possibly Parallel Threads