SOLVED Trying to set up a trunk...

[Dave Gray]

Working on a raspberry pi, trying to get a trunk set up with did logic. I'm confused...
Trunk is set up per DIDLogic's web page. It registers OK, but shows UNREACHABLE. My understanding, is that reachability is dependant on Asterisk sending a chain of OPTIONS packets. OK, set sip debug ip sip.didlogic.net. I see the options, and I see the 200 OK replies. But, Asterisk still sees the trunk as unreachable. Huh? What am I missing here?

 

[leemason]

Can you post your trunk setup (removing any usernames and passwords of course)?

 

[Dave Gray]

Umm, yes, that would be a good idea...

host=sip.didlogic.net
user=5XXXX
username=5XXXX
fromuser=5XXXX
authname=5XXXX
secret=zzzzzzzzz
type=friend
qualify=yes
insecure=port,invite
disallow=all
allow=ulaw

Everything else is left blank/default.

Note that outgoing doesn't work, either. I can see the INVITE go out. didlogic.net replies with a 407 (Authorization required). Asterisk just sends another INVITE, no auth string. It seems like it isn't seeing the replies (but it is, I can see the traffic from the console in debug mode.)

 

[gpuser]

I believe you've created a sip account in the portal and the 5xxxx is not your portal userid. If you have many unsuccessful tries, didlogic server will lock you out for 3 hours! You even won't be able browse didlogic.com from the same network (same public ip). So make sure your sip username and password are correct and then switch off Pi for about 4 hours before trying again. Goodluck!

 

[Dave Gray]

Yeah, that would be an easy mistake to make. But that isn't it.
The account registers OK. That means the account # and secret are correct, or it would fail (with the above-mentioned lockout. I am not locked out.)

REGISTER sip:sip.didlogic.net SIP/2.0
Via: SIP/2.0/UDP 96.XX.XXX.50:5060;branch=z9hG4bK16f24900;rport
Max-Forwards: 70
From: <sip:[email protected]>;tag=as73a428ba
To: <sip:[email protected]>
Call-ID: 2b07e7240ff68b724c99be6f2dabce62@[::1]
CSeq: 1965 REGISTER
User-Agent: FPBX-2.11.0(11.3.0)
Authorization: Digest username="5XXXX", realm="sip.didlogic.net", algorithm=MD5, uri="sip:sip.didlogic.net", nonce="UooewVKKHZWJNnreSVDQUpV8c54rkjgfdRe3RIA=", response="d2e44d756d32000008c9bebd14660118", qop=auth, cnonce="4d22bdb6", nc=00000003
Expires: 120
Contact: <sip:[email protected]:5060>
Content-Length: 0
 
 
---
 
<--- SIP read from UDP:178.63.143.236:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.0.0.45:5060;branch=z9hG4bK16f24900;rport=5060
From: <sip:[email protected]>;tag=as73a428ba
To: <sip:[email protected]>;tag=b27e1a1d33761e85846fc98f5f3a7e58.b9d1
Call-ID: 2b07e7240ff68b724c99be6f2dabce62@[::1]
CSeq: 1965 REGISTER
Contact: <sip:[email protected]:5060>;expires=120
Server: kamailio (4.0.3 (x86_64/linux))
Content-Length: 0

That works. But this apparently doesn't:

--- (8 headers 0 lines) ---
Retransmitting #4 (NAT) to 178.63.143.236:5060:
OPTIONS sip:sip.didlogic.net SIP/2.0
Via: SIP/2.0/UDP 96.XX.XXX.50:5060;branch=z9hG4bK63eccdd3;rport
Max-Forwards: 70
From: "Unknown" <sip:[email protected]>;tag=as10fe0d87
To: <sip:sip.didlogic.net>
Contact: <sip:[email protected]:5060>
Call-ID: [email protected]:5060
CSeq: 102 OPTIONS
User-Agent: FPBX-2.11.0(11.3.0)
Date: Mon, 18 Nov 2013 14:10:47 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Content-Length: 0
 
 
---
 
<--- SIP read from UDP:178.63.143.236:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.0.0.45:5060;branch=z9hG4bK63eccdd3;rport=5060
From: "Unknown" <sip:[email protected]>;tag=as10fe0d87
To: <sip:sip.didlogic.net>;tag=b27e1a1d33761e85846fc98f5f3a7e58.acb7
Call-ID: [email protected]:5060
CSeq: 102 OPTIONS
Server: kamailio (4.0.3 (x86_64/linux))
Content-Length: 0

Hmmm. Now I notice that the reply is using the internal address (10.0.0.45) instead of the external address that Asterisk put in the header (96.XX.XXX.50). Is that why Asterisk doesn't recognize the 200/OK ? What setting do I need to fix here?

 

[Dave Gray]

OK, halfway there. My gateway, a Netgear WGR-614, was too smart for its britches. Turned off the "Stateful Packet Inspection" firewall, and now my OPTIONS packets work, and the route is alive. Yay. But, the inbound route isn't working. I cannot see any SIP packets coming in when I call in. I can call out (yay), and even loop through my Google Voice line (I'm at work, so I called in on GV, then out via DISA), that works great.

I suspect that my gateway is still screwing me, as I'm not seeing any packets from didlogic.net when I call inbound. Hmmm. Does anyone know, do they use the same outgoing address to send inbound packets? If it's coming from a different server, that will be a pain, since there's no existing NAT mapping to forward to my PBX. I *can* set up a static port map, but then, I have no protection short of the PBX itself. Don't like that.

 

[sko001]

Did you forward UDP ports 5060 and 10000-20000 to your PBX? The incoming traffic may have trouble locating your PBX.

 

[Dave Gray]

Yes, I've set a static port forward for UDP 5000-20000 to the PBX (out of frustration.) I still don't see any packets coming in (via the set sip debug on) when I try to ring that line.
With my current setup, I can't see packets coming in from the outside... I miss the days when I kept a FreeBSD host as the primary firewall and router. I am quite suspicious of the router.

 

[PBX@Home]

Can you turn on logging in the router? See if it is dropping the requests? (sorry I didn't look up the router model)

 

[Dave Gray]

Afraid it's pretty primitive. As far as logging is concerned, well, it tells you all the web sites people are surfing, what else could you possibly want?

Useless, in other words. I do have a plan B here... I have a firewall/router box someone gave me a while back. Hopefully it will be a bit more flexible.

 

[PBX@Home]

My thought on logging was: Since calls are not reaching the PBX, are they even getting to the router? If the router is dropping them, then there is some work on that front. But if calls are not even reaching the router, there is some other issue.

 

[Dave Gray]

Well, yes. That's my thought as well. But, first I have to work out a way to see what's coming in to the router, and it isn't cooperating. It'll have to wait til I can get something else on there.

 

[sko001]

Did you set up Iptables or is your router not allowing incoming traffic from the didlogic IP address?

 

[Dave Gray]

Pretty sure it isn't IPTables. The thing does register, and the OPTIONS packets now are understood, and I can make outgoing calls with 2 way audio. Supposedly, the gateway is set to hold the NAT mapping for as long as 20 minutes (and it pings the server every 30 seconds or so.) The gateway is set to map all SIP inbounds to the PBX. I'm kind of at a loss right now.

 

[atsak]

You should be looking at that Netgear. The older ones were BRUTAL for this kind of problem; they would drop packets even though forwarding was turned on. I do not know if the newer ones are better because I don't use them. Can you try another new one, just to test?

 

[Hyksos]

How is the did routed at the provider, you have not talked about that and no screenshot either.
You haven't posted your full trunk config either since there is no mention of a register string here.
Why don't you simply try to install any voip app on a mobile phone with a data connection and have this connect to your public IP, you will see the packets come in via sip debug.
If your router is configured right there is no reason for it not to forward you the packet. Did you try with with iptables disabled?

If you are sure the provider is sending it to you just prove that by plugging a pc in your modem and do a wireshark capture while trying to call your DID.

Calling your DID and not seeing anything via sip debug is pretty basic to diag.. no need to have another router, you just have to make sure packets sent to your publicip:5060 reach asterisk and make sure your provider is setup to send the incoming calls to the sip account you're registering.

If you are sure the provider is setup right, then concentrate on proving packet sent to IP:5060 reach asterisk when they do exist... when sure of that (with sip app and mobile phone) then go back to your provider setup since he's not sending you the call.

Decompose this simple enough problem into even more simple elements and test each separately, you can't go wrong with pure logic and step by step elimination.

There are tons of ways to see what's wrong here in under 10 minutes with really basic tools and knowledge, just break it down.

 

[Hyksos]

ah, and next time you wonder why asterisk seem to be ignoring SIP packets that you think it should react to, notice the Call-ID.
(this is about your first reported issue with asterisk ignoring packets you COULD see in sip debug.)
Hope this helps next time.

It seem that I some point your router though its public IP was 10.0.0.45 ?
What's up with that? what IP is that? you haven't told that either.

 

[Dave Gray]

Hmmm, where to start.

OK, the bit with the 10.0.0.45 address, was the router rewriting SIP packets. They don't mention it, but the firewall apparently has an ALG, turning off the firewall fixed that. The trunk registers (always did) and now it is recognized as being on-line. (10.0.0.45 is the PBX's internal address.) I can make outgoing calls with it. The 200 OK packets were coming back with the wrong address.

So, halfway there.

I've set up a softphone on my iPhone, and that works great, both ways, so the provider is working. Don't know why I didn't think to just use my laptop directly from the modem... I was still trying to figure how to get a tap there, with everything switched and no hubs in the house. Experimenting with that will have to wait, wife was in the hospital yesterday so there went all evening, and taking the net connection down is a Big Deal, what with her Filipino Channel OTT box, and the daughter on Netflix... But we will get it.

I had no idea that something as cheap & cheesy as that router could actually run dd-wrt - I'll have to look in to that - it could make life easier on several fronts.

 

[Dave Gray]

So, finally have some time to work on this. I've updated the router with the latest firmware - ah huh, there *is* a SIP gateway in there, turned that off.

(BTW, that router won't do dd-wrt - the 614-v8 would, but I have a v7, way different box.)

Hmmm, set up my cell phone to connect (using the 3CX client, works great) and I *can* make calls in & out. I've created yet another SIP subaccount and set up a new trunk and routing. Routed the line to that account. Still does not work. So, a dumb phone works, but asterisk won't. (Routed through my home lan, not the internet connection as in the previous post.)

sip set debug on, I see the packets for the registration go by, but nothing when I try to call. Hmmm, so how do I shut off iptables to test that?

Anyone got tcpdump compiled for a pi?

 

[Dave Gray]

Well, I got it working. It isn't supposed to be this hard.

Didlogic has a (simplified) web page to set up your account. You create a SIP device (this is what you register to) and then you get a DID and set it to forward to your SIP device. Easy, right?

Outgoing calls worked as soon as I straightened out the router - it had a SIP ALG, with no indication that it existed. Turning off the firewall killed that (and a router update allowed me to kill the ALG and keep the firewall.)But no incoming calls. No packets hitting asterisk, at all. No packets off the net, at all.

Ran in to a thread on a similar issue, from somebody in Australia. Turns out, if you use the dropdown to forward your line to a SIP device, it does not work. I spent a loooong time looking for that invite (using tcpdump to scope out the packets.) When you use the dropdown to forward to a SIP address, then give it your [email protected] address, you get packets. Yay. Then I had to get iptables to play nice. Turns out that sip.didlogic.net, is the same IP as sip.didlogic.com, BUT your incoming calls actually come from another, different IP (didlogic.com - just didlogic.com.). (That's where tcpdump was invaluable. ) Had to put in a dummy trunk pointing to didlogc.com , to get it routed. And, now it works both ways.

(Oh, tcpdump is in the raspbian repository, just apt-get install tcpdump.)