3

I'm running into a funny little issue with Asterisk 10.3, but it seems to be applicable to 10.4 as well.

The server running Asterisk was relocated from a VPS to dedicated hardware, and now only 1 of several SIP peers can connect properly.

SIP peers are loaded from an ODBC connection into realtime. Given that 1 is able to connect without any issue, and functions as expected, runs the queries, and so on I've ruled any database connection issues out. The one client happens to be a Grandsteam ATA.

But that's where it stops. Nobody else can connect as Asterisk tells them 401 Unauthorized when they try to register.

The only variables that have changed in this equation may be the way the networks are setup. The old host was a VPS (Xen) and the new hardware is dedicated. In this case the server is sitting on a public IP. There shouldn't be any funky NAT trickery happening on the dedicated hardware, but mostly all connecting peers are behind a NAT of some kind.

What I've tried so far:

  • Adjusted nat=no on each peer, same result
  • Adjusted nat=no on each peer, insecure=invite,port, same result

To top it all off the Grandstream is connecting just fine. But other clients like CSipSimple, Cisco IP 79xx, Polycoms... no go.

Any idea what might need be changed to allow these peers to connect again?

Example:

    <--- SIP read from UDP:12.34.56.78:35286 --->
    REGISTER sip:sip.server.com SIP/2.0
    Via: SIP/2.0/UDP 10.0.0.163:35286;rport;branch=z9hG4bKPjZ8cqUxWzs6KnfN5kqG9lrD-V0hXQNppc
    Route: <sip:sip.server.com;lr>
    Max-Forwards: 70
    From: "Erik" <sip:334@sip.server.com>;tag=uwgq3EEWaQ0DuPwWEzuLfVA3aajqyXL6
    To: "Erik" <sip:334@sip.server.com>
    Call-ID: ohWlNbqWRdOme5TvFr3.r6mnPUbjoKqs
    CSeq: 1582 REGISTER
    User-Agent: CSipSimple r1108 / GT-S5830D-10
    Contact: "Erik" <sip:334@10.0.0.163:35286;ob>
    Expires: 900
    Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
    Content-Length: 0

    <------------->
    --- (13 headers 0 lines) ---
    Sending to 12.34.56.78:35286 (NAT)

    <--- Transmitting (NAT) to 12.34.56.78:35286 --->
    SIP/2.0 401 Unauthorized
    Via: SIP/2.0/UDP 10.0.0.163:35286;branch=z9hG4bKPjZ8cqUxWzs6KnfN5kqG9lrD-V0hXQNppc;received=12.34.56.78;rport=35286
    From: "Erik" <sip:334@sip.server.com>;tag=uwgq3EEWaQ0DuPwWEzuLfVA3aajqyXL6
    To: "Erik" <sip:334@sip.server.com>;tag=as2da10195
    Call-ID: ohWlNbqWRdOme5TvFr3.r6mnPUbjoKqs
    CSeq: 1582 REGISTER
    Server: Asterisk PBX 10.3.0
    Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
    Supported: replaces, timer
    WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="7837df5c"
    Content-Length: 0

    <------------>
1
  • Where is this bound address at? Which config file and where would it be located in the panel because I do not see this. Thanks,
    – user150482
    Dec 20, 2012 at 21:21

3 Answers 3

2

As this might helps for somebody:

insecure=invite

helped me after a similar relocation. For me it was vm to vm but bridged to the exact same network so I just don't get it why my working configuration stopped to work. I experienced one way call effect. The calls from outside SIP PBX going into the asterisk then sent out to voip softclients were working but the voip softclients couldn't communicate at all.

1
  • What security implications does this have?
    – Andreas
    Mar 3, 2016 at 11:54
1

Issue resolved! Despite Asterisk offering the ability to deal with more than one address by specifying 0.0.0.0 as your listen address, the box on which Asterisk was present was sending invites from other aliased IPs on the server instead of the one intended. Binding Asterisk to one IP, and connecting to that one IP, resolves this issue entirely.

2
  • can you elaborate? 0.0.0.0 should accept connections from any device, no?
    – Thufir
    Mar 24, 2015 at 5:23
  • I don't think this (your own) answer should be checked. You haven't really solved or explained the root problem.
    – TSG
    Jan 27, 2017 at 17:40
0

I had this issue and I solved it by moving to a TCP based connection. I already had TCP enabled and just enabled the extension to use it.

There seems to be an issue with NAT and UDP in my environment. If I find out more I will update my answer, but hopefully this will prove useful to others who find this problem as well.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy