dslreports logo
site
 
    All Forums Hot Topics Gallery
spc

spacer




how-to block ads


Search Topic:
uniqs
749
share rss forum feed


cybersaga

join:2011-12-19
Welland, ON

1 edit

[Anveo] Help setting up Anveo with HT496

So I just got setup with Anveo this week. I hooked up a Grandstream HT496 that I got from a friend who wasn't using it anymore. I set it up according to the example on the Anveo site for Grandstream, though not all the options are the same. It's sitting behind a Linksys WRT54GL running OpenWRT.

Outgoing calls work fine. My issue is with incoming calls. After a fresh reboot, incoming calls work fine. But it seems no matter what I set the "Register Expiration" to, after the first registration expires, incoming calls do not ring. It is re-registering, as I can confirm from the Anveo site, just calls don't ring my phone.

So right now, I have the expiration set to 2 minutes. For the first 2 minutes after a reboot, incoming calls work. After that two minutes, the device does re-register, but incoming calls do not ring.

Anveo does populate a call flow variable that'll tell you why the call did not get transferred to the SIP device. When the incoming calls do not come through, that variable says "BUSY".

I figured it might be a NAT thing, so I tried forwarding ports 5060 and 5004 on my router to the ATA, but no difference. I tried enabling STUN, but that didn't fix it. The only difference after enabling STUN is that under NAT on the Status page, it says "detected NAT type is port restricted cone". Without STUN, that's blank.

I also tried populating "Use NAT IP" on the Advanced page with my IP address, and it seem to solve the ringing problem - the phone does ring - but then I have a one-way audio problem (no incoming audio). Plus, my IP is dynamic, so that'll cause other issues.

Any idea what I'm doing wrong here?



cybersaga

join:2011-12-19
Welland, ON

Re: Help setting up Anveo with HT496

Click for full size
Click for full size
Click for full size
My configuration.


Thurmont

@optonline.net

1) Try setting [NAT Traversal (STUN)] to No, as Anveo indicates.

2) Try setting DNS SRV to Yes, as Anveo indicates on some of its other samples. This likely won't be relevant to this exact issue, but as the old joke goes, it couldn't hurt.



cybersaga

join:2011-12-19
Welland, ON

I did have it like that at first, but I switched it back just now: Changed 'NAT Traversal (STUN)' to No, and 'DNS SRV' to Yes.

No change.

Right after the reboot, the call goes through ok. Once the first registration expires (2 mins) the call doesn't ring through and I get "BUSY" as the reason. (I have the CALL.FORWARD.RESULT variable sent to me in the Anveo Communicator so I can see what it is)



cybersaga

join:2011-12-19
Welland, ON
reply to Thurmont

So I moved the ATA in front of my router - hooked it up directly to the cable modem. No change. It was doing the same thing: calls won't ring through and the reason I get is "BUSY".

So this can't be a NAT issue. What else could it be?



cybersaga

join:2011-12-19
Welland, ON
reply to cybersaga

Re: [Anveo] Help setting up Anveo with HT496

Another thing I noticed: When the ATA is in that state where it's "registered" (according to Anveo) but not accepting calls, I pick up the phone, and there's dead air: no dial tone. But then if I hang up and pick up right away, there's a dial done. And then it'll start receiving calls again.



cybersaga

join:2011-12-19
Welland, ON
reply to cybersaga

I'm getting closer I think.

It seems to be an issue between my ATA and my phone. I used the syslog feature on the ATA to see what's going on. It does actually receive the call, sends back a 100 (Trying), then sends back 486 (Busy). So I'm guessing it thinks the phone is busy for whatever reason.

I'm going to try fiddling with other settings (onhook voltage, settings on my phone, etc.) and see if anything changes.

If anyone has any suggestions..... please!



cybersaga

join:2011-12-19
Welland, ON

I take all of that back. I don't think I'm getting anywhere. And if it was an issue between the ATA and my phone, that wouldn't explain why it does work right after a reboot of the ATA.

In monitoring the syslog, I noticed I get a 407 (Proxy Authentication Required) immediately followed by a 481 (Subscription does not exist) every once in a while. I don't know what's up with that.

I got all excited when I found an old post that seemed pretty similar, where he fixed the issue by just doing a factory reset (he, like me, got the device second hand). So I did a factory reset and reconfigured and..... same problem. Argh!


tazzman

join:2009-03-27
Garnavillo, IA
reply to cybersaga

You may try Random TRP Port or maybe a Keep Alive setting. It may not hurt as well entering the same SIP credentials in the outbound proxy.



cybersaga

join:2011-12-19
Welland, ON
reply to cybersaga

Ok, so I figured out what's causing it, but not why. I ended up doing another factory reset, and this time I only changed the fields absolutely necessary to register. And it works, even after re-registering. So then I changed settings one by one to what I wanted them to be.

Turns out it's the MWI SUBSCRIBE. If I turn it off, everything works. When I turn it on, it breaks after the first re-register (or maybe it's the first MWI SUBSCRIBE). I've turned it off and on a few times, and it's predictable, so that's definitely what's causing it.

Now to figure out why. That's probably why I'm getting those 407/381 message back from the server.



cybersaga

join:2011-12-19
Welland, ON

1 edit
reply to cybersaga

I think I'm on the right track, though I don't know how to fix it.

I used the syslog to trace things. It was a bit tough to read, but I think I made some sense of it. I had to read up a bit on how the SIP messages are supposed to look for MWI.

I see the NOTIFY message received after a fresh reboot of the ATA:
NOTIFY sip:myacctnum@my.ip:5060;user=phone SIP/2.0
Via: SIP/2.0/UDP 67.212.84.21:5010;branch=z9hG4bK58ae.8a4e1ac1000000000000000000000000.0
To: sip:myacctnum@sip.ca.anveo.com;tag=7f03c2ed4c830eb8
From: sip:myacctnum@sip.ca.anveo.com;tag=d6175a32a14073806a6e8b2ea329ba44-326d
CSeq: 3 NOTIFY
Call-ID: cf15f225a19a2fe3@192.168.1.158
Content-Length: 140
User-Agent: kamailio (3.2.3 (x86_64/linux))
Max-Forwards: 70
Event: message-summary
Contact: <sip:my.ip:5010;transport=udp>
Subscription-State: active;expires=170
Content-Type: application/simple-message-summary
Messages-Waiting: yes
Message-Account: sip:myacctnum@sip.ca.anveo.com
Voice-Message: 1/0 (0/0)
Fax-Message: 0/0 (0/0)
None: 0/0 (0/0)
 

And my ATA returns a 202. All good. There's one or two more of those until that subscription expires (the time under the "Subscription-State...expires" above). Then I see this come in:
NOTIFY sip:myacctnum@my.ip:5060;user=phone SIP/2.0
Via: SIP/2.0/UDP 67.212.84.21:5010;branch=z9hG4bK28ae.bedaa6d4000000000000000000000000.0
To: sip:myacctnum@sip.ca.anveo.com;tag=7f03c2ed4c830eb8
From: sip:myacctnum@sip.ca.anveo.com;tag=d6175a32a14073806a6e8b2ea329ba44-326d
CSeq: 4 NOTIFY
Call-ID: cf15f225a19a2fe3@192.168.1.158
Content-Length: 0
User-Agent: kamailio (3.2.3 (x86_64/linux))
Max-Forwards: 70
Event: message-summary
Contact: <sip:67.212.84.21:5010;transport=udp>
Subscription-State: terminated;reason=timeout
 

I assume that's to announce that the first subscription has expired? And my ATA returns a 415, "Unsupported Media Type". That's when the trouble starts happening.

Shortly after that I see one of these come in:
SIP/2.0 481 Subscription does not exist
Via: SIP/2.0/UDP 192.168.1.158;branch=z9hG4bKe9a0fb2932022aa7;rport=5060;received=my.ip
From: "Me" <sip:myacctnum@sip.ca.anveo.com;user=phone>;tag=7f03c2ed4c830eb8
To: <sip:myacctnum@sip.ca.anveo.com;user=phone>;tag=d6175a32a14073806a6e8b2ea329ba44-326d
Call-ID: cf15f225a19a2fe3@192.168.1.158
CSeq: 64543 SUBSCRIBE
Server: kamailio (3.2.3 (x86_64/linux))  Content-Length: 0
 
I'm not sure what that is replying to though. I assume that because my ATA didn't understand the memo that the MWI subscription expired, it was trying to use the same Call-ID and Anveo in effect says "I don't know what you're talking about".

And for some reason after that my ATA returns a 486 (BUSY) every time a call comes in.

The syslog is difficult to read and probably doesn't show me everything. I tried to do the whole iptables to forward the traffic to my computer so I could use Wireshark, but I couldn't get that going.

In the morning (oops! it is morning) I'll get in touch with Anveo support and see if they can enable SIP logging or some such thing and see better what's going on.

This is the deepest I've ever gotten into the world of SIP, so correct me if I'm wrong on any of my assumptions.

Edit: I should add that the 481 is followed by this (abbreviated):
Send SIP message: 8 To 67.212.84.21:5010 1 0
SIP/2.0 407 Proxy Authentication Required
Send SIP message: 8 To 67.212.84.21:5010 1 0
Send SIP message: 1 To 67.212.84.21:5010 2 0
SIP/2.0 401 Unauthorized
 

So maybe there's something about the way that my ATA is trying to re-subscribe that Anveo doesn't like? Hopefully the SIP logging on Anveo's end will be telling.


cybersaga

join:2011-12-19
Welland, ON
reply to cybersaga

I put in a ticket this morning with Anveo. We'll see what comes of it.



cybersaga

join:2011-12-19
Welland, ON
reply to cybersaga

It seems my understanding of the problem in the last post was pretty much right. I think it all stems from the fact that my ATA doesn't understand the NOTIFY and returns a 415. I've read that some Grandstream devices send a 415 by design when the NOTIFY does not include a 'Content-Type', which according to strict spec, it should. I've also read that some Grandstream devices have an option to disable SIP validation, so that it'll ignore these kinds of things, but this one doesn't.

After that, it sends another subscribe message using the same Call-ID (which is expired), and gets a 481, naturally. At this point it should send a new subscribe request after the 481 response, but it doesn't. So yeah, Anveo may be sending a message that's not quite right, but this device does a horrible job of handling that.

And for some reason, all this breaks incoming calls.

It looks like I'll have to live without MWI (which isn't terrible since I get emailed the VMs anyway) or use a different ATA.