SIP registration problems - please help!
ichigo:
Okay... that's quite messed up...
To go over your suggestions one by one: I had initially set up ASAHI as SP1, so the X_UserAgentPort = 5060 has already been tried. Nevertheless, I tried what ever you suggested, just in case SP2 magically opens up the connection... but no luck :(
I tried setting up the PPoE on the Mac, which was quite easy. But I had trouble getting the TC to connect to the network created by the Mac. My iPhone connected happily and used the internet connection, but TC refused - not sure what I did wrong.
I could try out the PBXes option, but I am not sure which settings I have to change... unless you "guide" me.
I will try using a FON router (I realized I had one, given to me by SoftBank when I got the iPhone) tonight and see if that helps.
Finally, you mentioned at the beginning that the rport parameter is ignored by the OBi... Is there a way to let the developers know...maybe they can fix that with an update?
Thank you for your patience with this so far!
============
Tested with the new router: modem>router>OBi (ethernet);
Mac connected via WiFi
Still getting the 401 error, when I checked on the Mac. Added port forwarding for 5060-5061, but it still gives the 401.
Stewart:
Sorry for the long delay in replying.
I tried having PBXes register to a local device. Unfortunately, it sends rport, so that won't work for you.
There are still lots of missing pieces to this puzzle. In a "classic" SIP request, the Via header tells the server the IP address and port to which the response should be sent. Obviously, that won't work if the client is behind a NAT. There are three ways of dealing with that problem. One is for the server to reply to whatever IP/port from which the request came, which is Callcentric's approach and works fine on your system. A second method is a SIP ALG in the router, which substitutes the proper address and port in various headers. Finally, the client device can act as if it is on a public IP, learning (by STUN or received/port parameters) the proper IP and port to send.
In the present failing situation, the OBi learns its public address, but not the correct public port number. It then sends an incorrect Via header with the public IP but port 5061. When you have no forwarding in place, the response gets discarded, resulting in the "Waiting for server response" status. With forwarding, you get the response, but it's another 401. I don't know whether that's because the server sees an inconsistency between the Via header and the actual source, or it's for some unrelated reason. We could find out, if you have a way for you (or someone else) to test OBi with ASAHI on a public IP.
I don't know how we are getting a response to the initial REGISTER request, which has the private address in Via. Also, X-Lite is presenting only the private address, and is working fine. Either when Via shows a private address, the server responds to the source address/port, or the AE is doing some sort of ALG. We could find out, by testing X-Lite through a router known to have no SIP ALG, or have one that can be disabled.
If the OBi does work with ASAHI, behind a NAT that doesn't translate the source port number, a different router would be the easiest solution. Perhaps port forwarding on the FON router would help, or alternate firmware could be loaded in, e.g. DD-WRT. Does the AE have latest firmware? Can your modem be configured to do the PPPoE internally? Any chance of getting the TC to associate with the Mac Wi-Fi?
Otherwise, perhaps Obihai could fix it to ignore the received tag when rport is off, or you could insert some kind of SIP PBX or proxy in the path, running on your Mac, in the cloud, or a commercial service.
ichigo:
Hi Stewart! Good to see you back!
I did try forwarding the ports on the FON router, but still got a 401. Loading alternate firmware to the type of FON router I have is too much of a hassle, and I don’t think I have the technical expertise for that:
http://sites.google.com/site/hottunalabs/home/fonera-simpl-hacking
I will try and get a different router from one of my friends – the only reason I have been holding it off is due to the UI for these routers (usually) being in Japanese – but I can try.
The AE firmware version is 7.6.1, which is the latest for my model. The NTT ADSL modem is just that – a modem – it needs a computer or router to configure the PPPoE – although considering its size, I would have expected it to have that functionality. The issue with getting the TC to associate with the Mac Wi-Fi is that the Mac Wi-Fi has a very simple setup, which does not allow the network to be extended (I think – you can correct me if I am wrong). For instance, the options that I have on the TC for setting up the wireless are: a) Create a wireless network, b) Participate in a WDS network and c) Extend a wireless network. Option a) is ruled out. For b), the Mac has to be set up as a WDS main, but I don’t see any way of doing that and for c), the TC reports that “the selected network cannot be extended”. :/
I don’t think I am desperate enough to “insert some kind of SIP PBX or proxy in the path, running on the Mac, in the cloud, or a commercial service” :)
Will let you know how I get along with an alternate router (will take some time though) and also see if I can get OBihai to come up with a fix.
ichigo:
I finally got around to testing the OBi with a router (NEC's Aterm WR8500N) that is "tested" to be compatible with IP phones from NTT West, Asahi, etc. The PPPoE was done by this router and I connected the OBi to it directly, using ethernet. Still kept getting the 401s. Here are the logs from this setup (as earlier, starting from the initial REGISTER request, reply to the REGISTER, etc.):
REGISTER sip:asahi-net.or.jp:5060 SIP/2.0
Call-ID: a253a417@192.168.0.3
Content-Length: 0
CSeq: 14732 REGISTER
From: <sip:050XXXXXXXX@asahi-net.or.jp>;tag=SP130c9d33a77dbdd44
Max-Forwards: 70
To: <sip:050XXXXXXXX@asahi-net.or.jp>
Via: SIP/2.0/UDP 192.168.0.3:5060;branch=z9hG4bK-622dcc19
User-Agent: OBIHAI/OBi100-1.3.0.2690
Contact: <sip:050XXXXXXXX@192.168.0.3:5060>;expires=60;+sip.instance="<urn:uuid:00000000-0000-0000-0000-9cadef1035b2>"
Allow: ACK,BYE,CANCEL,INFO,INVITE,NOTIFY,OPTIONS,REFER
Supported: replaces
========
SIP/2.0 401 Unauthorized
Call-ID: a253a417@192.168.0.3
l: 0
CSeq: 14732 REGISTER
From: <sip:050XXXXXXXX@asahi-net.or.jp>;tag=SP130c9d33a77dbdd44
To: <sip:050XXXXXXXX@asahi-net.or.jp>
v: SIP/2.0/UDP 192.168.0.3:5060;received=118.xx.xx.xx;branch=z9hG4bK-622dcc19
User-Agent: OBIHAI/OBi100-1.3.0.2690
Allow: ACK,BYE,CANCEL,INFO,INVITE,NOTIFY,OPTIONS,REFER
Supported: replaces
Date: Sat, 24 Mar 2012 17:59:37 GMT
WWW-Authenticate: Digest realm="ocn.ne.jp", domain="sip:210.227.109.205", nonce="1332608824", opaque="", stale=FALSE, algorithm=MD5
=============
REGISTER sip:asahi-net.or.jp:5060 SIP/2.0
Call-ID: a253a417@192.168.0.3
Content-Length: 0
CSeq: 14733 REGISTER
From: <sip:050XXXXXXXX@asahi-net.or.jp>;tag=SP130c9d33a77dbdd44
Max-Forwards: 70
To: <sip:050XXXXXXXX@asahi-net.or.jp>
Via: SIP/2.0/UDP 192.168.0.3:5060;branch=z9hG4bK-7c725f12
Authorization: DIGEST algorithm=MD5,nonce="1332608824",opaque="",realm="ocn.ne.jp",response="5aab2584f7ebc78b94337030683ec13b",uri="sip:asahi-net.or.jp:5060",username="ABCDEFGX"
User-Agent: OBIHAI/OBi100-1.3.0.2690
Contact: <sip:050XXXXXXXX@118.xx.xx.xx:5060>;expires=60;+sip.instance="<urn:uuid:00000000-0000-0000-0000-9cadef1035b2>"
Allow: ACK,BYE,CANCEL,INFO,INVITE,NOTIFY,OPTIONS,REFER
Supported: replaces
=====================
SIP/2.0 401 Unauthorized
Call-ID: a253a417@192.168.0.3
l: 0
CSeq: 14733 REGISTER
From: <sip:050XXXXXXXX@asahi-net.or.jp>;tag=SP130c9d33a77dbdd44
To: <sip:050XXXXXXXX@asahi-net.or.jp>
v: SIP/2.0/UDP 192.168.0.3:5060;received=118.xx.xx.xx;branch=z9hG4bK-7c725f12
User-Agent: OBIHAI/OBi100-1.3.0.2690
Allow: ACK,BYE,CANCEL,INFO,INVITE,NOTIFY,OPTIONS,REFER
Supported: replaces
Date: Sat, 24 Mar 2012 17:59:38 GMT
WWW-Authenticate: Digest realm="ocn.ne.jp", domain="sip:210.227.109.205", nonce="1332608824", opaque="", stale=FALSE, algorithm=MD5
=================
REGISTER sip:asahi-net.or.jp:5060 SIP/2.0
Call-ID: a253a417@192.168.0.3
Content-Length: 0
CSeq: 14734 REGISTER
From: <sip:050XXXXXXXX@asahi-net.or.jp>;tag=SP130c9d33a77dbdd44
Max-Forwards: 70
To: <sip:050XXXXXXXX@asahi-net.or.jp>
Via: SIP/2.0/UDP 192.168.0.3:5060;branch=z9hG4bK-49226648
Authorization: DIGEST algorithm=MD5,nonce="1332608824",opaque="",realm="ocn.ne.jp",response="5aab2584f7ebc78b94337030683ec13b",uri="sip:asahi-net.or.jp:5060",username="ABCDEFGX"
User-Agent: OBIHAI/OBi100-1.3.0.2690
Contact: <sip:050XXXXXXXX@118.xx.xx.xx:5060>;expires=60;+sip.instance="<urn:uuid:00000000-0000-0000-0000-9cadef1035b2>"
Allow: ACK,BYE,CANCEL,INFO,INVITE,NOTIFY,OPTIONS,REFER
Supported: replaces
Stewart:
Assuming that the stale=FALSE in the second 401 can be taken at face value, perhaps the OBi is for some reason not calculating the response= correctly.
Run this perl script to test. Put it in a file and edit the values of $authid and $pass, and edit $nonce to match an Authorization header that you have captured. Run it by typing
Code:
perl filename
in a terminal window, with the current path pointing to the folder where you put the file. It should display a string that matches the corresponding response parameter.
Code:
#!/usr/bin/perl -w
use Digest::MD5 qw(md5_hex);
$authid = 'ABCDEFGX';
$pass = 'putyourpasswordhere';
$realm = 'ocn.ne.jp';
$method = 'REGISTER';
$uri = 'sip:asahi-net.or.jp:5060';
$nonce = '1332608824';
$a1 = md5_hex("$authid:$realm:$pass");
$a2 = md5_hex("$method:$uri");
print md5_hex("$a1:$nonce:$a2"), "\n";
Navigation
[0] Message Index
[#] Next page
[*] Previous page