Running a VoIP phone adapter through a Linux machine
The setting
I got an AudioCodes MP202B as a phone line adapter from my Israeli ISP, Netvision. The normal way to connect it is putting it between the computer and the ADSL modem, so it does the “dialing” (sending username and password). This was a no-no for me, because I have a little home network with my own NAT and fake DNSes, so the last thing I wanted was to reconfigure my own network.
My twisted, and not really optimal solution was to let the phone adapter think my own computer is the ISP, so it connects to my computer with pppoe, gets a bogus IP address and DNS details, and then connect to the VoIP network through my computer.
That means, among others, that the phone adapter’s packets undergo NAT just like anything else going through that computer. What about incoming calls, I asked myself. They are initiated by the far end. How will iptables know the that its address needs to be mangled, so it goes to the phone adapter, and not the the host?
The answer, as usual with iptables, is don’t worry, be happy. As it turns out, the phone keeps sending initiation packets on UDP port 5060 periodically, so iptables can easily see the session. The voice packets also find their way. In short, it simply works. As usual.
Note that the bogus IP address the adapter sees is exposed to the VoIP operator in the headers of connection establishment packets. So if the ISP suddenly decides to check if the IP address appearing in these packets is in the valid range, the trick is revealed. Actually, it’s enough to check if the IP address in the headers matches the source address of the UDP packet itself (which has been altered by iptables to the real address given by the ISP). A software update or change in the (security?) configuration in the ISP’s infrastructure can lead to a sudden disconnection of the phone line. But this is not likely to happen: Assuming that the ISP checks the phone number against the ISP’s login name, this leaves no room for malicious tricks. Any extra restrictions are unnecessary, and as any network maintainer knows, add any extra filter, and some manager will shout at you soon.
This solution has an inherent flaw, though: Putting the phone between the computer and ADSL modem allows it to prioritize its own packets over data packets. Without this, voice quality can go down as a result of a massive upload to the web. But running a few tests, I didn’t hear any difference.
Getting the link up
Connect the phone adapter through its WAN jack to the desired Ethernet card (eth3 in my case).
Run a sniffer on the port, and verify that the adapter attempts to start a pppoe session. Something like this:
No. Time Source Destination Protocol Info 1 0.000000 AUDIO_e5:43:0f ff:ff:ff:ff:ff:ff PPPoED Active Discovery Initiation (PADI) 2 0.999256 AUDIO_e5:43:0f ff:ff:ff:ff:ff:ff PPPoED Active Discovery Initiation (PADI) 3 2.999042 AUDIO_e5:43:0f ff:ff:ff:ff:ff:ff PPPoED Active Discovery Initiation (PADI) 4 6.998632 AUDIO_e5:43:0f ff:ff:ff:ff:ff:ff PPPoED Active Discovery Initiation (PADI)
Set up /etc/ppp/pppoe-server-options, which has the options to pppd, to read something like this:
lcp-echo-interval 10 lcp-echo-failure 2 noauth ms-dns 10.2.0.1 ms-dns 10.2.0.2
with emphasis on the “noauth” option, since it’s pretty obvious that whoever is connected to the Ethernet jack doesn’t need authentication. Otherwise, the login name and password configured in the phone adapter must be added to pap-secrets or chap-secrets (whichever applies).
The ms-dns option contains DNS addresses for the adapter. These are fake addresses, which are NATed in the hosting machine, so they are real DNSes to the adapter.
Start off the pppoe server (as root, of course) with
# pppoe-server -I eth3 -L 10.192.0.0 -R 10.192.0.1 -N 1
where -N 1 limits the server to only one connections. The -L and -R set the local and remote addresses.
And by the way, to kill the pppoe server along with its connections go:
# killall pppoe-server
The packet capture should now look like:
No. Time Source Destination Protocol Info 1 0.000000 AUDIO_e5:43:0f ff:ff:ff:ff:ff:ff PPPoED Active Discovery Initiation (PADI) 2 0.000369 EDIMAX_89:ae:12 AUDIO_e5:43:0f PPPoED Active Discovery Offer (PADO) 3 0.000650 AUDIO_e5:43:0f EDIMAX_89:ae:12 PPPoED Active Discovery Request (PADR) 4 0.001711 EDIMAX_89:ae:12 AUDIO_e5:43:0f PPPoED Active Discovery Session-confirmation (PADS) 5 1.020712 EDIMAX_89:ae:12 AUDIO_e5:43:0f PPP LCP PPP LCP Configuration Request 6 1.021534 AUDIO_e5:43:0f EDIMAX_89:ae:12 PPP LCP PPP LCP Configuration Request 7 1.021687 EDIMAX_89:ae:12 AUDIO_e5:43:0f PPP LCP PPP LCP Configuration Reject 8 1.023117 AUDIO_e5:43:0f EDIMAX_89:ae:12 PPP LCP PPP LCP Configuration Ack 9 1.024261 AUDIO_e5:43:0f EDIMAX_89:ae:12 PPP LCP PPP LCP Configuration Request 10 1.024434 EDIMAX_89:ae:12 AUDIO_e5:43:0f PPP LCP PPP LCP Configuration Ack 11 1.024513 EDIMAX_89:ae:12 AUDIO_e5:43:0f PPP LCP PPP LCP Echo Request 12 1.024565 EDIMAX_89:ae:12 AUDIO_e5:43:0f PPP IPCP PPP IPCP Configuration Request 13 1.025981 AUDIO_e5:43:0f EDIMAX_89:ae:12 PPP LCP PPP LCP Echo Request 14 1.026087 EDIMAX_89:ae:12 AUDIO_e5:43:0f PPP LCP PPP LCP Echo Reply 15 1.026740 AUDIO_e5:43:0f EDIMAX_89:ae:12 PPP IPCP PPP IPCP Configuration Request 16 1.026854 EDIMAX_89:ae:12 AUDIO_e5:43:0f PPP IPCP PPP IPCP Configuration Nak 17 1.028069 AUDIO_e5:43:0f EDIMAX_89:ae:12 PPP CCP PPP CCP Configuration Request 18 1.028197 EDIMAX_89:ae:12 AUDIO_e5:43:0f PPP CCP PPP CCP Configuration Request 19 1.028267 EDIMAX_89:ae:12 AUDIO_e5:43:0f PPP CCP PPP CCP Configuration Reject 20 1.029948 AUDIO_e5:43:0f EDIMAX_89:ae:12 PPP LCP PPP LCP Echo Reply 21 1.031115 AUDIO_e5:43:0f EDIMAX_89:ae:12 PPP IPCP PPP IPCP Configuration Ack 22 1.036625 AUDIO_e5:43:0f EDIMAX_89:ae:12 PPP IPCP PPP IPCP Configuration Request 23 1.037321 EDIMAX_89:ae:12 AUDIO_e5:43:0f PPP IPCP PPP IPCP Configuration Ack 24 1.038305 AUDIO_e5:43:0f EDIMAX_89:ae:12 PPP CCP PPP CCP Configuration Ack 25 1.040164 AUDIO_e5:43:0f EDIMAX_89:ae:12 PPP CCP PPP CCP Configuration Request 26 1.043146 EDIMAX_89:ae:12 AUDIO_e5:43:0f PPP CCP PPP CCP Configuration Ack 27 1.572454 10.192.0.1 10.2.0.1 DNS Standard query A ntp.netvision.net.il 28 3.070230 10.192.0.1 10.2.0.1 DNS Standard query A centrex.res.netvision.net.il 29 5.584155 10.192.0.1 10.2.0.1 DNS Standard query A ntp.netvision.net.il 30 6.570551 10.192.0.1 10.2.0.2 DNS Standard query A ntp.netvision.net.il 31 7.019219 AUDIO_e5:43:0f EDIMAX_89:ae:12 PPP LCP PPP LCP Echo Request 32 7.019401 EDIMAX_89:ae:12 AUDIO_e5:43:0f PPP LCP PPP LCP Echo Reply 33 8.070333 10.192.0.1 10.2.0.2 DNS Standard query A centrex.res.netvision.net.il 34 8.541665 10.192.0.1 10.2.0.1 DNS Standard query A centrex.res.netvision.net.il 35 10.580118 10.192.0.1 10.2.0.2 DNS Standard query A ntp.netvision.net.il 36 11.030538 EDIMAX_89:ae:12 AUDIO_e5:43:0f PPP LCP PPP LCP Echo Request 37 11.031304 AUDIO_e5:43:0f EDIMAX_89:ae:12 PPP LCP PPP LCP Echo Reply 38 13.018511 AUDIO_e5:43:0f EDIMAX_89:ae:12 PPP LCP PPP LCP Echo Request (...etc)
So what we have here is a successful pppoe establishment. It’s also clear that the adapter got the DNS addresses OK, since it uses them for queries. But alas, no answer is returned, because my firewall rejects packets from any ppp device which are not within a session.
On my computer, the firewall script is run every time a ppp device goes up, by virtue of /etc/ppp/ip-up.local calling the firewall setup script.
In the script, I added the following part:
if [ $PHONEIF ] ; then iptables -A INPUT -i $PHONEIF -j droplog iptables -A OUTPUT -o $PHONEIF -j droplog if [ $EXTIF ] ; then iptables -A FORWARD -i $PHONEIF -o $EXTIF -j ACCEPT iptables -A FORWARD -i $EXTIF -o $PHONEIF -j ACCEPT fi # Default rule: Drop forwarded packets from and to adapter iptables -A FORWARD -i $PHONEIF -j droplog iptables -A FORWARD -o $PHONEIF -j droplog fi
Where $PHONEIF and $EXTIF are the interfaces (ppp1 and ppp0, usually), as defined previously in the script.
Now everything works properly, packet capture as follows:
No. Time Source Destination Protocol Info 1 0.000000 AUDIO_e5:43:0f ff:ff:ff:ff:ff:ff PPPoED Active Discovery Initiation (PADI) 2 0.000059 EDIMAX_89:ae:12 AUDIO_e5:43:0f PPPoED Active Discovery Offer (PADO) 3 0.000319 AUDIO_e5:43:0f EDIMAX_89:ae:12 PPPoED Active Discovery Request (PADR) 4 0.000683 EDIMAX_89:ae:12 AUDIO_e5:43:0f PPPoED Active Discovery Session-confirmation (PADS) 5 0.002173 0.0.0.0 255.255.255.255 DHCP DHCP Discover - Transaction ID 0x1fa2870d 6 1.024784 EDIMAX_89:ae:12 AUDIO_e5:43:0f PPP LCP PPP LCP Configuration Request 7 1.026219 AUDIO_e5:43:0f EDIMAX_89:ae:12 PPP LCP PPP LCP Configuration Request 8 1.026369 EDIMAX_89:ae:12 AUDIO_e5:43:0f PPP LCP PPP LCP Configuration Reject 9 1.027837 AUDIO_e5:43:0f EDIMAX_89:ae:12 PPP LCP PPP LCP Configuration Ack 10 1.028997 AUDIO_e5:43:0f EDIMAX_89:ae:12 PPP LCP PPP LCP Configuration Request 11 1.029168 EDIMAX_89:ae:12 AUDIO_e5:43:0f PPP LCP PPP LCP Configuration Ack 12 1.029244 EDIMAX_89:ae:12 AUDIO_e5:43:0f PPP LCP PPP LCP Echo Request 13 1.029298 EDIMAX_89:ae:12 AUDIO_e5:43:0f PPP IPCP PPP IPCP Configuration Request 14 1.031055 AUDIO_e5:43:0f EDIMAX_89:ae:12 PPP IPCP PPP IPCP Configuration Request 15 1.031172 EDIMAX_89:ae:12 AUDIO_e5:43:0f PPP IPCP PPP IPCP Configuration Nak 16 1.032347 AUDIO_e5:43:0f EDIMAX_89:ae:12 PPP CCP PPP CCP Configuration Request 17 1.032473 EDIMAX_89:ae:12 AUDIO_e5:43:0f PPP CCP PPP CCP Configuration Request 18 1.032544 EDIMAX_89:ae:12 AUDIO_e5:43:0f PPP CCP PPP CCP Configuration Reject 19 1.034022 AUDIO_e5:43:0f EDIMAX_89:ae:12 PPP LCP PPP LCP Echo Reply 20 1.035204 AUDIO_e5:43:0f EDIMAX_89:ae:12 PPP IPCP PPP IPCP Configuration Ack 21 1.040019 AUDIO_e5:43:0f EDIMAX_89:ae:12 PPP IPCP PPP IPCP Configuration Request 22 1.041032 EDIMAX_89:ae:12 AUDIO_e5:43:0f PPP IPCP PPP IPCP Configuration Ack 23 1.041705 AUDIO_e5:43:0f EDIMAX_89:ae:12 PPP CCP PPP CCP Configuration Ack 24 1.042895 AUDIO_e5:43:0f EDIMAX_89:ae:12 PPP CCP PPP CCP Configuration Request 25 1.046591 EDIMAX_89:ae:12 AUDIO_e5:43:0f PPP CCP PPP CCP Configuration Ack 26 3.073250 10.192.0.1 10.2.0.1 DNS Standard query A centrex.res.netvision.net.il 27 3.089492 10.2.0.1 10.192.0.1 DNS Standard query response A 82.166.210.6 28 3.106339 10.192.0.1 82.166.210.6 SIP Request: REGISTER sip:centrex.res.netvision.net.il 29 3.131676 82.166.210.6 10.192.0.1 SIP Status: 200 Ok 30 11.034587 EDIMAX_89:ae:12 AUDIO_e5:43:0f PPP LCP PPP LCP Echo Request 31 11.035375 AUDIO_e5:43:0f EDIMAX_89:ae:12 PPP LCP PPP LCP Echo Reply 32 21.034734 EDIMAX_89:ae:12 AUDIO_e5:43:0f PPP LCP PPP LCP Echo Request 33 21.035485 AUDIO_e5:43:0f EDIMAX_89:ae:12 PPP LCP PPP LCP Echo Reply 34 31.034857 EDIMAX_89:ae:12 AUDIO_e5:43:0f PPP LCP PPP LCP Echo Request (etc...)
With SIP registration repeated every ~80 seconds, and LCP echoes every 10 seconds. The SIP protocol is defined in its RFC.
Note that there is no authentication whatsoever. If there was, we would have seen the server sending a challenge, to which the phone adapter would respond with an answer. In the case above, the server accepts the connection with no questions asked.
Registration packets in detail
This is a good time to mention, that I’ve replaced my real incoming phone number to 073-6666666 and calling number to 04-8222222. After all, I don’t want my real phone numbers out there. I’m not customer support.
The Register/OK pair above look like this:
User Datagram Protocol, Src Port: 5060 (5060), Dst Port: 5060 (5060) Source port: 5060 (5060) Destination port: 5060 (5060) Length: 633 Checksum: 0x1623 (correct) Session Initiation Protocol Request line: REGISTER sip:centrex.res.netvision.net.il SIP/2.0 Message Header From: <sip:200012972736666666@centrex.res.netvision.net.il>;tag=100a4e90-100c00a-13c4-50029-0-7e817330-0 To: <sip:200012972736666666@centrex.res.netvision.net.il> Call-ID: 100b62d8-100c00a-13c4-50029-0-2a161072-0 CSeq: 1 REGISTER Via: SIP/2.0/UDP 10.192.0.1:5060;rport;branch=z9hG4bK-0-2a0-3639eac2 Max-Forwards: 70 Supported: replaces,100rel Allow: REGISTER, INVITE, ACK, BYE, REFER, NOTIFY, CANCEL, INFO, OPTIONS, PRACK, SUBSCRIBE Expires: 1800 Contact: <sip:200012972736666666@10.192.0.1:5060> User-Agent: MP202 B 2FXS/3.0.1_p041_build_19 Content-Length: 0
and then answer is simply
Session Initiation Protocol Status line: SIP/2.0 200 Ok Message Header From: <sip:200012972736666666@centrex.res.netvision.net.il>;tag=100a4e90-100c00a-13c4-50029-0-7e817330-0 To: <sip:200012972736666666@centrex.res.netvision.net.il>;tag=SDq3rh799- Call-ID: 100b62d8-100c00a-13c4-50029-0-2a161072-0 CSeq: 1 REGISTER Via: SIP/2.0/UDP 10.192.0.1:5060;received=46.116.190.192;branch=z9hG4bK-0-2a0-3639eac2;rport=5060 Contact: <sip:200012972736666666@10.192.0.1:5060>;expires=120 Content-Length: 0
Incoming phone call
An incoming phone call, which isn’t answered looks like this:
64 83.972831 82.166.210.6 10.192.0.1 SIP/SDP Request: INVITE sip:200012972736666666@10.192.0.1:5060, with session description 65 84.194196 82.166.210.6 10.192.0.1 SIP/SDP Request: NOTIFY sip:200012972736666666@10.192.0.1:5060, with session description 66 84.339229 10.192.0.1 82.166.210.6 SIP Status: 180 Ringing 67 84.581309 10.192.0.1 82.166.210.6 SIP Status: 200 OK 68 91.035533 EDIMAX_89:ae:12 AUDIO_e5:43:0f PPP LCP PPP LCP Echo Request 69 91.036415 AUDIO_e5:43:0f EDIMAX_89:ae:12 PPP LCP PPP LCP Echo Reply 70 101.035711 EDIMAX_89:ae:12 AUDIO_e5:43:0f PPP LCP PPP LCP Echo Request 71 101.036461 AUDIO_e5:43:0f EDIMAX_89:ae:12 PPP LCP PPP LCP Echo Reply 72 104.484595 82.166.210.6 10.192.0.1 SIP Request: CANCEL sip:200012972736666666@10.192.0.1:5060 73 104.485130 82.166.210.6 10.192.0.1 SIP/SDP Request: NOTIFY sip:200012972736666666@10.192.0.1:5060, with session description 74 104.508747 10.192.0.1 82.166.210.6 SIP Status: 200 OK 75 104.603031 10.192.0.1 82.166.210.6 SIP Status: 487 Request Terminated 76 104.624033 82.166.210.6 10.192.0.1 SIP Request: ACK sip:200012972736666666@10.192.0.1:5060 77 104.629209 10.192.0.1 82.166.210.6 SIP Status: 200 O
The INVITE packet’s details are as follows:
User Datagram Protocol, Src Port: 5060 (5060), Dst Port: 5060 (5060) Source port: 5060 (5060) Destination port: 5060 (5060) Length: 880 Checksum: 0xe69c (correct) Session Initiation Protocol Request line: INVITE sip:200012972736666666@10.192.0.1:5060 SIP/2.0 Message Header Via: SIP/2.0/UDP 82.166.210.6:5060;branch=z9hG4bKckpn1l30a880su8va740.1 Call-Id: SDau8fa01-e00a9a6ae9b1553d6117b50ab6a925a6-a0fo130 From: <sip:048222222@centrex.res.netvision.net.il:5060>;tag=SDau8fa01-10.60.20.110-4294963135-9019 To: <sip:200012972736666666@centrex.res.netvision.net.il:5060> Max-Forwards: 69 Allow: REGISTER, INVITE, BYE, ACK, CANCEL, REFER, INFO, OPTIONS, SUBSCRIBE, UPDATE Session-Expires: 900 CSeq: 3040744 INVITE Contact: <sip:048222222@82.166.210.6:5060;transport=udp> Supported: timer Content-Type: application/sdp Content-Length: 24
Note that the caller’s ID is there!
Outgoing phone call
Picking up the VoIP phone and calling 04-8222222, without the other side answering, yields:
118 221.029993 10.192.0.1 82.166.210.6 SIP/SDP Request: INVITE sip:048222222@centrex.res.netvision.net.il, with session description 119 221.037083 EDIMAX_89:ae:12 AUDIO_e5:43:0f PPP LCP PPP LCP Echo Request 120 221.037885 AUDIO_e5:43:0f EDIMAX_89:ae:12 PPP LCP PPP LCP Echo Reply 121 221.056671 82.166.210.6 10.192.0.1 SIP Status: 100 Trying 122 221.975013 82.166.210.6 10.192.0.1 SIP/SDP Status: 183 Session Progress, with session description 123 222.013388 10.192.0.1 82.166.210.134 UDP Source port: 5004 Destination port: 16480 124 222.032360 10.192.0.1 82.166.210.134 UDP Source port: 5004 Destination port: 16480 125 222.046283 82.166.210.134 10.192.0.1 UDP Source port: 16480 Destination port: 5004 126 222.052372 10.192.0.1 82.166.210.134 UDP Source port: 5004 Destination port: 16480 127 222.066521 82.166.210.134 10.192.0.1 UDP Source port: 16480 Destination port: 5004 128 222.072316 10.192.0.1 82.166.210.134 UDP Source port: 5004 Destination port: 16480 129 222.086438 82.166.210.134 10.192.0.1 UDP Source port: 16480 Destination port: 5004 (and packets keep flowing...)
As people in the industry know, the voice circuit starts without waiting for the other side to answer in an outgoing call.
The invitation packet in detail is pretty much like the previous one, just the other way around:
User Datagram Protocol, Src Port: 5060 (5060), Dst Port: 5060 (5060) Source port: 5060 (5060) Destination port: 5060 (5060) Length: 988 Checksum: 0x196d (correct) Session Initiation Protocol Request line: INVITE sip:048222222@centrex.res.netvision.net.il SIP/2.0 Message Header From: "0736666666"<sip:200012972736666666@centrex.res.netvision.net.il>;tag=100a7b30-100c00a-13c4-50029-da-174234ad-da To: <sip:048222222@centrex.res.netvision.net.il> Call-ID: 100b2350-100c00a-13c4-50029-da-4cc1ed17-da CSeq: 1 INVITE Via: SIP/2.0/UDP 10.192.0.1:5060;rport;branch=z9hG4bK-da-3561c-7fd18a32 Max-Forwards: 70 Supported: replaces,100rel User-Agent: MP202 B 2FXS/3.0.1_p041_build_19 Allow: REGISTER, INVITE, ACK, BYE, REFER, NOTIFY, CANCEL, INFO, OPTIONS, PRACK, SUBSCRIBE Contact: <sip:200012972736666666@10.192.0.1:5060> Content-Type: application/sdp Content-Length: 32
Followed by the Trying packet:
User Datagram Protocol, Src Port: 5060 (5060), Dst Port: 5060 (5060) Source port: 5060 (5060) Destination port: 5060 (5060) Length: 371 Checksum: 0x5d52 (correct) Session Initiation Protocol Status line: SIP/2.0 100 Trying Message Header From: "0736666666"<sip:200012972736666666@centrex.res.netvision.net.il>;tag=100a7b30-100c00a-13c4-50029-da-174234ad-da To: <sip:048222222@centrex.res.netvision.net.il> Call-ID: 100b2350-100c00a-13c4-50029-da-4cc1ed17-da CSeq: 1 INVITE Via: SIP/2.0/UDP 10.192.0.1:5060;received=46.116.190.192;branch=z9hG4bK-da-3561c-7fd18a32;rport=506
and then
Session Initiation Protocol Status line: SIP/2.0 183 Session Progress Message Header From: "0736666666"<sip:200012972736666666@centrex.res.netvision.net.il>;tag=100a7b30-100c00a-13c4-50029-da-174234ad-da To: <sip:048222222@centrex.res.netvision.net.il>;tag=SD2kim999-10.60.20.110-4294957762-7934 Call-ID: 100b2350-100c00a-13c4-50029-da-4cc1ed17-da CSeq: 1 INVITE Via: SIP/2.0/UDP 10.192.0.1:5060;received=46.116.190.192;branch=z9hG4bK-da-3561c-7fd18a32;rport=5060 Contact: <sip:048222222@82.166.210.6:5060;transport=udp> Content-Type: application/sdp Content-Length: 199 Session Description Protocol Session Description Protocol Version (v): 0 Owner/Creator, Session Id (o): - 1227677235 2 IN IP4 82.166.210.134 Owner Username: - Session ID: 1227677235 Session Version: 2 Owner Network Type: IN Owner Address Type: IP4 Owner Address: 82.166.210.134 Session Name (s): - Connection Information (c): IN IP4 82.166.210.134 Connection Network Type: IN Connection Address Type: IP4 Connection Address: 82.166.210.134 Time Description, active time (t): 0 0 Session Start Time: 0 Session Start Time: 0 Media Description, name and address (m): audio 16480 RTP/AVP 18 101 Media Type: audio Media Port: 16480 Media Proto: RTP/AVP Media Format: 18 Media Format: 101 Media Attribute (a): rtpmap:18 G729/8000 Media Attribute Fieldname: rtpmap Media Attribute Value: 18 G729/8000 Media Attribute (a): sendrecv Media Attribute (a): rtpmap:101 telephone-event/8000 Media Attribute Fieldname: rtpmap Media Attribute Value: 101 telephone-event/8000 Media Attribute (a): fmtp:101 0-15 Media Attribute Fieldname: fmtp Media Attribute Value: 101 0-1
I have snipped off the session description protocol parts from the previous packets. The “Media Port” entry is obviously how the sides expose their UDP ports.
July 2014 update
A month ago, or so, the phone suddenly stopped connecting, and the attempt to register was refused flat. I called their support, they told me they will be working on it, and then the phone came back to life. This is the updated UDP packet dump of the registration. Note that it fails first, and then the client tries again, with an improved request.
REGISTER sip:centrex.res.netvision.net.il SIP/2.0 From: <sip:200012972736666666@centrex.res.netvision.net.il>;tag=100a4e40-100c00a-13c4-50029-b-5b9cd2a-b To: <sip:200012972736666666@centrex.res.netvision.net.il> Call-ID: 100b6288-100c00a-13c4-50029-a-4e521aee-a CSeq: 1 REGISTER Via: SIP/2.0/UDP 10.192.0.1:5060;rport;branch=z9hG4bK-b-2cec-1e8eaaf Max-Forwards: 70 Supported: replaces,100rel Allow: REGISTER, INVITE, ACK, BYE, REFER, NOTIFY, CANCEL, INFO, OPTIONS, PRACK, SUBSCRIBE Expires: 1800 Contact: <sip:200012972736666666@10.192.0.1:5060> User-Agent: MP202 B 2FXS/3.0.1_p041_build_19 Content-Length: 0 SIP/2.0 401 Unauthorized From: <sip:200012972736666666@centrex.res.netvision.net.il>;tag=100a4e40-100c00a-13c4-50029-b-5b9cd2a-b To: <sip:200012972736666666@centrex.res.netvision.net.il> Call-ID: 100b6288-100c00a-13c4-50029-a-4e521aee-a CSeq: 1 REGISTER Via: SIP/2.0/UDP 10.192.0.1:5060;received=93.173.36.5;branch=z9hG4bK-b-2cec-1e8eaaf;rport=5060 Content-Length: 0 WWW-Authenticate: Digest realm="NcxSip", nonce="62445575" REGISTER sip:centrex.res.netvision.net.il SIP/2.0 From: <sip:200012972736666666@centrex.res.netvision.net.il>;tag=100a4e40-100c00a-13c4-50029-b-5b9cd2a-b To: <sip:200012972736666666@centrex.res.netvision.net.il> Call-ID: 100b6288-100c00a-13c4-50029-a-4e521aee-a CSeq: 2 REGISTER Via: SIP/2.0/UDP 10.192.0.1:5060;rport;branch=z9hG4bK-d-3689-2ec8fad1 Max-Forwards: 70 Supported: replaces,100rel Allow: REGISTER, INVITE, ACK, BYE, REFER, NOTIFY, CANCEL, INFO, OPTIONS, PRACK, SUBSCRIBE Expires: 1800 Authorization: Digest username="200012972736666666",realm="NcxSip",nonce="62345345",uri="sip:centrex.res.netvision.net.il",response="26e7f74553dae1131cef72c3c90c5b67",algorithm=MD5 Contact: <sip:200012972736666666@10.192.0.1:5060> User-Agent: MP202 B 2FXS/3.0.1_p041_build_19 Content-Length: 0 SIP/2.0 200 Ok From: <sip:200012972736666666@centrex.res.netvision.net.il>;tag=100a4e40-100c00a-13c4-50029-b-5b9cd2a-b To: <sip:200012972736666666@centrex.res.netvision.net.il> Call-ID: 100b6288-100c00a-13c4-50029-a-4e521aee-a CSeq: 2 REGISTER Via: SIP/2.0/UDP 10.192.0.1:5060;received=93.173.36.5;branch=z9hG4bK-d-3689-2ec8fad1;rport=5060 Contact: <sip:200012972736666666@10.192.0.1:5060>;expires=120 Content-Length: 0
As before, numbers and strings that may be specific have been altered in the dump.
Reader Comments
Hi,
Have you found this method workable in the long term? Have there been any troubles? I’m considering implementing your idea…
Thanks,
–Alex
It’s working properly since I wrote this post, which is three months now. I don’t know if that qualifies “long term”…
Hi i have allmost the same router(MP 202c) and my isp(013Netvision) is not willing to give me my router login user andm password(admin access).
What should i do to get them?
Thanks You, Yosef.
Since Eli mentions here the Sip address for Netvision,
Sip:20001297273….@centrex.res.netvision.net.il
Does anyone know if Netvision will allow incoming calls to that SIP URI address (Basically sip to sip)?
Thanks In Advance!