| reply to ohmer
Re: [Other] voip.ms & pap2t : calls don't always cut when I hang I took a closer look at your debug log; this appears to be a DNS issue. I believe that "getting alternate" during the first call was a failing DNS lookup and the GetServerAddrErr after going on-hook showed that it didn't know where to send the cancel.
Check if you have the latest firmware (I believe it's 5.1.6) -- this unit is notorious for DNS issues.
You might try setting DNS servers to e.g. 4.2.2.1 and 4.2.2.2 and set DNS Server Order to Manual.
Or, try taking DNS out of the picture altogether, by setting an Outbound Proxy of 174.137.63.202 , Use Outbound Proxy to yes, and Use OB Proxy In Dialog to yes. |
|
 ohmer
join:2003-08-06
Quebec, QC
 ·TekSavvy DSL
·ELECTRONICBOX
 ·voip.ms
·Primus Talkbroad..
| said by Stewart:I took a closer look at your debug log; this appears to be a DNS issue. I believe that "getting alternate" during the first call was a failing DNS lookup and the GetServerAddrErr after going on-hook showed that it didn't know where to send the cancel. Check if you have the latest firmware (I believe it's 5.1.6) -- this unit is notorious for DNS issues. You might try setting DNS servers to e.g. 4.2.2.1 and 4.2.2.2 and set DNS Server Order to Manual. Or, try taking DNS out of the picture altogether, by setting an Outbound Proxy of 174.137.63.202 , Use Outbound Proxy to yes, and Use OB Proxy In Dialog to yes. I already upgraded my firmware to the last versiuon (5.1.6).
Changing dns change nothing. |
|
| said by ohmer:Changing dns change nothing. Try the outbound proxy with numeric IP, just as a test to see where the problem lies. I agree that it's not a good long-term solution, because if voip.ms changes the address your system would stop working until you make the corresponding change manually.
It would be useful if you can capture traffic from/to the unit, in addition to the syslog. If the issue does prove to be DNS related, you'll be able to see DNS lookups and replies. If not, at least you'll see what network activity (if any) is associated with the cryptic log messages. |
|
ohmer
join:2003-08-06
Quebec, QC Reviews:
·TekSavvy DSL
·ELECTRONICBOX
·voip.ms
·Primus Talkbroad..
| said by Stewart:said by ohmer:Changing dns change nothing. Try the outbound proxy with numeric IP, just as a test to see where the problem lies. I agree that it's not a good long-term solution, because if voip.ms changes the address your system would stop working until you make the corresponding change manually. It would be useful if you can capture traffic from/to the unit, in addition to the syslog. If the issue does prove to be DNS related, you'll be able to see DNS lookups and replies. If not, at least you'll see what network activity (if any) is associated with the cryptic log messages. Replacing dns name by ip seem to works... no more dns message in the log.
But replacing ca1/ca2 servers by sip.us1.voip.ms also work (but message apear again in the logs).
The CA servers doesn't like me... |
|
| said by ohmer:The CA servers doesn't like me... Be sure that Use DNS SRV is off (I don't believe voip.ms has any SRV records), try setting DNS Query Mode to Sequential, be sure that DNS Server Order is Manual.
If no luck, I recommend capturing traffic to see what is going wrong. IMO there are two likely possibilities: either the DNS lookup is somehow bad, e.g. because of DNS proxying in your network or at your ISP, or the Linksys is interpreting it incorrectly, which might be worked around by a settings change. |
|
TelSat
join:2002-10-10
Toronto, ON | reply to ohmer
I had the same problem I opened a ticket and they asked me what ATA I had which it didn't make sense since that same ATA worked fine with same settings with another provider.
It is working now....this is what I did:
I was on the Toronto server switched to the Montreal server and it worked perfectly then switched back to the Toronto server and it has been working fine. I don't use for outgoing as I have no need for it but since I saw your problem I checked again and it is still working. I had this problem mid Feb. |
|
ohmer
join:2003-08-06
Quebec, QC Reviews:
·TekSavvy DSL
·ELECTRONICBOX
·voip.ms
·Primus Talkbroad..
| reply to Stewart
said by Stewart:said by ohmer:The CA servers doesn't like me... Be sure that Use DNS SRV is off (I don't believe voip.ms has any SRV records), try setting DNS Query Mode to Sequential, be sure that DNS Server Order is Manual. If no luck, I recommend capturing traffic to see what is going wrong. IMO there are two likely possibilities: either the DNS lookup is somehow bad, e.g. because of DNS proxying in your network or at your ISP, or the Linksys is interpreting it incorrectly, which might be worked around by a settings change. DNS SRV is already off. DNS query mode change changed nothing.
I found a thread, it seem to be the same problem as me : »Re: voip.ms incoming call routing problems (fast busy tone)
He's using a similar router (WRT54G vs WRT54GL), same custom firmware (Tomato) and have the same symptoms.
His solution:
quote:
The problem seems to be only present when enabling the keep alive, with no STUN server. I tried keep alive with a STUN server and no more problem, but I don't like to rely on a 3th party server. As I explained in the main voip.ms' thread, setting port forwarding allowed me to drop the keep alive. And as priller suggested, dropping the registration timeout to 180 secs (before the UDP connection timeout of the router, mine's set to 300 secs) allows to drop the port forwarding while keeping the hole opened in the router for incoming calls. And the disconnection of the ATA won't happens with any of these setup, only with the keep alive enabled. I tried two SPA2102 and both are affected by the problem. Maybe we're stuck with a firmware bug? At least, there are workarounds.
Seem OK for now with theses settings.
Curious that happen only with CA servers and not US... |
|
|
|
| Wow, thanks for the update. Just a WAG, maybe the CA server is not responding or returning an error for the $NOTIFY (or whatever you are sending as NAT Keep Alive Msg). The device then decides that the server is sick and tries to find an alternate by DNS. There is none, so it considers the server to be down, until the next register succeeds and it's marked up again. If the US servers do respond, your observations would be consistent with this theory. A numeric IP would prevent any of this from happening, since there would be no way to locate an alternate.
I did a quick check and determined that the keep alive message and its response do get logged when SIP Debug Option is set to full. However, I don't have a voip.ms account to see how their servers respond or whether there is a difference between CA and US in this regard. If you could please test that, it would confirm (or refute) this conjecture. |
|
ohmer
join:2003-08-06
Quebec, QC Reviews:
·TekSavvy DSL
·ELECTRONICBOX
·voip.ms
·Primus Talkbroad..
| Hello,
I hope it's what you talked about... I think they are keep alive packets. I captured theses packets while the line was idle.
From CA2 server
Apr 17 12:10:25 pap2t.lan.xxxx.ca 00259C6XXXXX [0:5060]->174.137.63.202:5060
Apr 17 12:10:25 pap2t.lan.xxxx.ca 00259C6XXXXX [0:5060]->174.137.63.202:5060
Apr 17 12:10:25 pap2t.lan.xxxx.ca 00259C6XXXXX NOTIFY sip:sip.ca2.voip.ms SIP/2.0^M Via: SIP/2.0/UDP 192.168.7.93:5060;branch=z9hG4bK-c02ee611^M From: MY NAME <sip:MYACCNT#_ata@sip.ca2.voip.ms>;tag=d8eb66fbf5f007eo0^M To: <sip:sip.ca2.voip.ms>^M Call-ID: c86e70af-4ab6625a@192.168.7.93^M CSeq: 2 NOTIFY^M Max-Forwards: 70^M Event: keep-alive^M User-Agent: Linksys/PAP2T-5.1.6(LS)^M Content-Length: 0^M ^M
Apr 17 12:10:25 pap2t.lan.xxxx.ca 00259C6XXXXX
Apr 17 12:10:25 pap2t.lan.xxxx.ca 00259C6XXXXX
Apr 17 12:10:26 pap2t.lan.xxxx.ca 00259C6XXXXX [0:5060]->174.137.63.202:5060
Apr 17 12:10:26 pap2t.lan.xxxx.ca 00259C6XXXXX [0:5060]->174.137.63.202:5060
Apr 17 12:10:26 pap2t.lan.xxxx.ca 00259C6XXXXX NOTIFY sip:sip.ca2.voip.ms SIP/2.0^M Via: SIP/2.0/UDP 192.168.7.93:5060;branch=z9hG4bK-c02ee611^M From: MY NAME <sip:MYACCNT#_ata@sip.ca2.voip.ms>;tag=d8eb66fbf5f007eo0^M To: <sip:sip.ca2.voip.ms>^M Call-ID: c86e70af-4ab6625a@192.168.7.93^M CSeq: 2 NOTIFY^M Max-Forwards: 70^M Event: keep-alive^M User-Agent: Linksys/PAP2T-5.1.6(LS)^M Content-Length: 0^M ^M
From US1 server
Apr 17 12:12:13 pap2t.lan.xxxx.ca 00259C6XXXXX [0:5060]->209.62.1.2:5060
Apr 17 12:12:13 pap2t.lan.xxxx.ca 00259C6XXXXX [0:5060]->209.62.1.2:5060
Apr 17 12:12:13 pap2t.lan.xxxx.ca 00259C6XXXXX NOTIFY sip:sip.us1.voip.ms SIP/2.0^M Via: SIP/2.0/UDP 192.168.7.93:5060;branch=z9hG4bK-7ef4f21e^M From: MY NAME <sip:MYACCNT#_ata@sip.us1.voip.ms>;tag=cc0d9a891f18b246o0^M To: <sip:sip.us1.voip.ms>^M Call-ID: 79d25bd5-20a4016a@192.168.7.93^M CSeq: 5 NOTIFY^M Max-Forwards: 70^M Event: keep-alive^M User-Agent: Linksys/PAP2T-5.1.6(LS)^M Content-Length: 0^M ^M
Apr 17 12:12:13 pap2t.lan.xxxx.ca 00259C6XXXXX
Apr 17 12:12:13 pap2t.lan.xxxx.ca 00259C6XXXXX
Apr 17 12:12:13 pap2t.lan.xxxx.ca 00259C6XXXXX [0:5060]<<209.62.1.2:5060
Apr 17 12:12:13 pap2t.lan.xxxx.ca 00259C6XXXXX [0:5060]<<209.62.1.2:5060
Apr 17 12:12:13 pap2t.lan.xxxx.ca 00259C6XXXXX SIP/2.0 489 Bad event^M Via: SIP/2.0/UDP 192.168.7.93:5060;branch=z9hG4bK-7ef4f21e;received=76.10.xx.xx^M From: MY NAME <sip:MYACCNT#_ata@sip.us1.voip.ms>;tag=cc0d9a891f18b246o0^M To: <sip:sip.us1.voip.ms>;tag=as51802732^M Call-ID: 79d25bd5-20a4016a@192.168.7.93^M CSeq: 5 NOTIFY^M User-Agent: VoIPMS/SERAST^M Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY^M Supported: replaces^M Content-Length: 0^M ^M
The packet my ATA sent seem to be the same whatever I'm connected to CA2 or US1, but only US1 reply to my packet (and it seem to complaint about what my ATA sent?). |
|
| said by ohmer:The packet my ATA sent seem to be the same whatever I'm connected to CA2 or US1, but only US1 reply to my packet (and it seem to complaint about what my ATA sent?). OK, we're getting a pretty good understanding about what is going on. In the US1 case, even though the response is an error (saying that the server doesn't implement the keep-alive event), the SPA takes it as showing that the server is up, so all is well. In the CA2 case, there is no response at all, which the SPA is taking to mean the server is down. It looks for an alternate, but there is none and the SPA considers the service to be down until the next registration shows it to be up. IMO, that's a firmware bug.
One workaround is to simply not use NAT keep alive, by port forwarding, setting a short registration expiry, or setting a long timeout in the router. However, there are some instances where keep alive would be needed. For example, you are behind a NAT over which you have no administrative control, e.g. in a hotel, and your provider does not honor a sufficiently short registration expiry, nor does he send inbound keep alive packets.
So, I'll take a look at other NAT Keep Alive Msg options. With luck, we'll find one where the SPA doesn't demand a response, and/or one that should provoke a response from all providers. |
|
ohmer
join:2003-08-06
Quebec, QC Reviews:
·TekSavvy DSL
·ELECTRONICBOX
·voip.ms
·Primus Talkbroad..
1 edit | I modified the "NAT Keep Alive Msg" setting. Default was "$NOTIFY", I put random string ("toto") and it seem to work. It work but I don't really understand what I do :D
This is my log on my idling line:
Apr 17 15:40:21 pap2t.lan.xxxx.ca 00259C6XXXXX [0:5060]->174.137.63.202:5060
Apr 17 15:40:21 pap2t.lan.xxxx.ca 00259C6XXXXX [0:5060]->174.137.63.202:5060
Apr 17 15:40:21 pap2t.lan.xxxx.ca 00259C6XXXXX toto
Apr 17 15:40:21 pap2t.lan.xxxx.ca 00259C6XXXXX
Apr 17 15:40:21 pap2t.lan.xxxx.ca 00259C6XXXXX
Apr 17 15:40:36 pap2t.lan.xxxx.ca 00259C6XXXXX [0:5060]->174.137.63.202:5060
Apr 17 15:40:36 pap2t.lan.xxxx.ca 00259C6XXXXX [0:5060]->174.137.63.202:5060
Apr 17 15:40:36 pap2t.lan.xxxx.ca 00259C6XXXXX toto
Apr 17 15:40:36 pap2t.lan.xxxx.ca 00259C6XXXXX
Apr 17 15:40:36 pap2t.lan.xxxx.ca 00259C6XXXXX
Apr 17 15:40:51 pap2t.lan.xxxx.ca 00259C6XXXXX [0:5060]->174.137.63.202:5060
Apr 17 15:40:51 pap2t.lan.xxxx.ca 00259C6XXXXX [0:5060]->174.137.63.202:5060
Apr 17 15:40:51 pap2t.lan.xxxx.ca 00259C6XXXXX toto
Apr 17 15:40:51 pap2t.lan.xxxx.ca 00259C6XXXXX
Apr 17 15:40:51 pap2t.lan.xxxx.ca 00259C6XXXXX
EDIT: With this change, I don't see dns related message into the logs. |
|
Mangowww.toao.net
join:2008-12-25
Alberta
kudos:8 Reviews:
·voip.ms
·Anveo
 ·Shaw
·FreePhoneLine
·TELUS
·Callcentric
·callwithus
·LINGO
| reply to Stewart
said by Stewart:In the CA2 case, there is no response at all, which the SPA is taking to mean the server is down. It looks for an alternate, but there is none and the SPA considers the service to be down until the next registration shows it to be up. IMO, that's a firmware bug. GOLD!!!
I saw this thread back when you two were working on it but didn't have a chance to test until now. You two are exactly correct. I have wanted to know the solution to this problem for ages.
Knowing this, what should we do? Should we recommend all users set their NAT Keep Alive Msg to "Feel the city breakin' and everybody shakin'" or is it a better solution to convince the providers to respond to NOTIFY messages?
My feeling is that setting the NAT Keep Alive Msg is better. It seems like the device will perform as expected whether or not the provider responds to NOTIFY and whether or not there is an alternate server specified in DNS. As long as the NAT hole is kept open (and so far it seems to be) I see no side effects.
I wonder if this will solve my other issue. In »DNS SRV - I'm stumped I mentioned that this morning my phone had switched to the backup server and refused to switch back to the primary. Maybe it is a different problem because my primary is US3, which is one of the ones that responds to the NOTIFY.
m.
--
Recommended ATA Settings | e164 - make your DID accessible via SIPBroker! | Tips for Reliable Internet Faxing |
|
| reply to Stewart
said by Stewart:said by ohmer:The packet my ATA sent seem to be the same whatever I'm connected to CA2 or US1, but only US1 reply to my packet (and it seem to complaint about what my ATA sent?). OK, we're getting a pretty good understanding about what is going on. In the US1 case, even though the response is an error (saying that the server doesn't implement the keep-alive event), the SPA takes it as showing that the server is up, so all is well. In the CA2 case, there is no response at all, which the SPA is taking to mean the server is down. It looks for an alternate, but there is none and the SPA considers the service to be down until the next registration shows it to be up. IMO, that's a firmware bug. One workaround is to simply not use NAT keep alive, by port forwarding, setting a short registration expiry, or setting a long timeout in the router. However, there are some instances where keep alive would be needed. For example, you are behind a NAT over which you have no administrative control, e.g. in a hotel, and your provider does not honor a sufficiently short registration expiry, nor does he send inbound keep alive packets. So, I'll take a look at other NAT Keep Alive Msg options. With luck, we'll find one where the SPA doesn't demand a response, and/or one that should provoke a response from all providers. Awhile back I saw a sample setup of a SPA/PAP2T, where the recommended setting for "NAT Keep Alive Msg:" was "0000", instead of "$NOTIFY". This is with both "NAT Mapping Enable:" and "NAT Keep Alive Enable:" set to "Yes". Does anyone know what respond be be in this case ("0000")? I new at this, but I'm still unclear about how all this works. |
|
| said by DaveSin:Awhile back I saw a sample setup of a SPA/PAP2T, where the recommended setting for "NAT Keep Alive Msg:" was "0000", instead of "$NOTIFY". This is with both "NAT Mapping Enable:" and "NAT Keep Alive Enable:" set to "Yes". Does anyone know what respond be be in this case ("0000")? I new at this, but I'm still unclear about how all this works. I believe that if the Msg is anything other than the special $NOTIFY or $REGISTER values, the SPA does not expect a reply and the only effect of the keep-alive is to refresh the NAT association in the user's router. Because 0000 is not a valid SIP request line, most servers would just ignore such a packet. Conceivably, a server might reply with 400 Bad Request; the ATA would ignore that. |
|
OmagicQPosting in a thread near you
join:2003-10-23
Bakersfield, CA
kudos:1 Reviews:
·voip.ms
·callwithus
·Callcentric
| said by Stewart:I believe that if the Msg is anything other than the special $NOTIFY or $REGISTER values, the SPA does not expect a reply and the only effect of the keep-alive is to refresh the NAT association in the user's router. Because 0000 is not a valid SIP request line, most servers would just ignore such a packet. Conceivably, a server might reply with 400 Bad Request; the ATA would ignore that. When the keep alive message is "blank", what is sent? I don't have a softphone with a configurable keep alive message to test with. |
|
Mangowww.toao.net
join:2008-12-25
Alberta
kudos:8
1 edit | reply to ohmer
My ticket is still open, but now I see the 489 Bad Event response from CA1. (Not CA2.) Ohmer, if you have the time, could you please check to see if CA1 works for you too?
m. |
|
