Reviews:
 ·VOIPo
·Future Nine Corp..
| reply to rcilink
Re: End of VOIP in Pakistan? said by rcilink:For those of you in a country that has SIP ports (usually 5060) blocked, try this company: www.callpacket.com Download their free softphone. It will search for a port that is open and use it to connect the SIP session. (It even tries 53/udp!) So, yes you could configure any SIP phone to use callpacket and use port 53 (not 5060). 53 is DNS, so if you are reading this, your ISP most likely has not blocked 53. Let us know how it works. I have Callpacket softphone and I don't see it searching for ports. There is setting inside which asks for SIP port number which by default set to 5060 and that's it. Why do you think it's dynamic? Also their forums still not having any posts, very strange.
--
FIOS availability maps
http://www.emailconfirm.com/fiosmaps/ |
|
| said by artisticcheese:I have Callpacket softphone and I don't see it searching for ports. There is setting inside which asks for SIP port number which by default set to 5060 and that's it. Why do you think it's dynamic? Also their forums still not having any posts, very strange. Ok, change the SIP port from 5060 to 53. Test the softphone and it should work.
This will (should) get through most of the blockages that ISPs have setup for blocking port 5060 (SIP). I am sure there are other ways to block it, but this should work for Pakistan.. Anyone in Pakistan try it yet?
As for their 'forums' at callpacket, they need to change the default configuration. Right now, the registration wants a verification code (those graphical letters, usually strangely shaped, etc), but the register page does not show the graphic.. so, there is no way to 'register' to post on those forums... I am sure once the 1,000,000 people are all taken care of (new sign-ups), that they will have time to fix it. |
|
Reviews:
·VOIPo
·Future Nine Corp..
| I put 53, press save button and form is immediately cleared. Also regardless of that it will probably not work for me since I'm inside corporate firewall which has outgoing 53 blocked as well. If they in fact support 53 then I hoped they would run it on 80 or 443 as well.
--
FIOS availability maps
http://www.emailconfirm.com/fiosmaps/ |
|
| reply to rcilink
I had tried callpacket softphone but it does not work. |
|
Reviews:
·ViaTalk
| If an ISP is blocking VoIP by block access TO UDP port 5060, then they would not care that YOU are not using UDP port 5060.
When you change the 'SIP port' setting on your ATA or softphone, you are changing the UDP port you are using to initiate a VoIP call.
Unless you change the Destination address used by your VoIP service provider (VSP) via the address for the Outbound proxy or the SIP Proxy, you will still be blocked. If your VSP supports VoIP signaling (i.e. SIP messages) through a non-standard port, then the SIP Proxy or Outbound proxy would look like:
vbuzzer.com:80
sip.broadvoice.com:5061 (this one is fake)
Therefore, don't waste you time changing the SIP port option on your ATA or softphone. Instead, find a VSP (like vbuzzer or FreeWorldDialup) that communicates using a different SIP port.
See ya...
d.c. |
|
| said by im_chandave:...the SIP Proxy or Outbound proxy would look like: vbuzzer.com:80 sip.broadvoice.com:5061 (this one is fake) Therefore, don't waste you time changing the SIP port option on your ATA or softphone. Instead, find a VSP (like vbuzzer or FreeWorldDialup) that communicates using a different SIP port. That's what I am trying to tell you.. Callpacket is 'listening' on more than just port 5060. so, You can point the softphone (or PAP2) to port 53/udp either by changing the '5060' to '53'. Or, you can make it say voip.callpacket.com:53.
Give it a try. I encourage you to block all traffic to any destination host port 5060. That will be a fair test, right?
I tried the 53 port with callpacket and the PAP2. It works. |
|
Reviews:
·ViaTalk
1 edit | hmm....I just changed my Asterisk box to use voip.callpacket.com's UDP port 53 as the destination port for SIP messages. I sniff the line between my gateway router and my Asterisk box (it's not behind a NAT), I see my SIP REGISTER being sent to 67.43.159.38 UDP port 53, but I don't see any packets coming back from 67.43.159.38 UDP port 53. I do see packets coming from 67.43.159.38 UDP port 5060 to my Asterisk box. But, that's their "Pinger" (a NULL SIP OPTIONS message used to determine if I'm still reachable) from my previous REGISTER and the "Pinger" packets do stop after 200 seconds (the standard REGISTER expiration time assigned by callpacket).
Can you do a syslog dump of the SIP dialog from your PAP2 doing a SIP REGISTER to voip.callpacket.com's UDP port 53? I'm curious to see what type of reply you are getting from them.
Here's my SIP message dump:
to 67.43.159.38:53
Retransmitting #4 (NAT):
REGISTER sip:voip.callpacket.com SIP/2.0
Via: SIP/2.0/UDP 203.198.202.49:5060;branch=z9hG4bK4e70bf0a;rport
From: <sip:cp00009990@voip.callpacket.com>;tag=as4e98a88e
To: <sip:cp00009990@voip.callpacket.com>
Call-ID: 6c305f3b58490ea330bbac0f45658932@voip.callpacket.com
CSeq: 105 REGISTER
User-Agent: Asterisk PBX
Expires: 120
Contact: <sip:19498615600@203.198.202.49>
Event: registration
Content-Length: 0
Since I'm not getting any SIP replies (neither 1XX nor 200), my Asterisk box is just retransmitting.
Ignore Asterisk indicating that I have enabled NAT. I just want Asterisk to issue out an 'rport' enquiry to force the SIP Proxy to return my source port info.
See ya...
d.c. |
|
| ok, i changed the SIP port on the PAP2 to 53 and saved/rebooted the device.
In addition, i set 2 rules in the shorewall Linux firewall as follows:
DROP loc net:voip.callpacket.com udp 5060 -
DROP loc net:voip.callpacket.com tcp 5060 -
* I later went back in and put the IP in place of the "voip.callpacket.com".
So, no possible traffic is allowed to the net at IP voip.callpacket.com port tcp or udp 5060. (that is, no traffic from inside my network is allowed to 'voip.callpacket.com' port 5060 (udp or tcp).
I booted the PAP2. It is using port 53 outgoing to register with callpacket and is telling me 'online'.
The tcpdump looks like this:
00:38:09.259827 24.63.aaa.bbb.53 > 67.43.159.38.5060:
00:38:09.342385 67.43.159.38.5060 > 24.63.aaa.bbb.53:
00:38:24.347053 24.63.aaa.bbb.53 > 67.43.159.38.5060:
00:38:24.429197 67.43.159.38.5060 > 24.63.aaa.bbb.53:
*I placed a call and the following is the traffic I saw:
00:42:39.530119 67.43.159.38.5060 > 24.63.aaa.bbb.53:
00:42:39.569663 24.63.aaa.bbb.16416 > 67.43.159.38.61672:
00:42:39.599115 24.63.aaa.bbb.16416 > 67.43.159.38.61672:
00:42:39.628858 24.63.aaa.bbb.16416 > 67.43.159.38.61672:
00:42:39.658618 24.63.aaa.bbb.16416 > 67.43.159.38.61672:
00:42:39.690477 24.63.aaa.bbb.16416 > 67.43.159.38.61672:
00:42:39.720258 24.63.aaa.bbb.16416 > 67.43.159.38.61672:
00:42:39.721346 67.43.159.38.61672 > 24.63.aaa.bbb.16416:
00:42:39.748859 67.43.159.38.61672 > 24.63.aaa.bbb.16416:
00:42:39.750338 24.63.aaa.bbb.16416 > 67.43.159.38.61672:
00:42:39.777895 67.43.159.38.61672 > 24.63.aaa.bbb.16416:
00:42:39.779822 24.63.aaa.bbb.16416 > 67.43.159.38.61672:
00:42:39.808440 67.43.159.38.61672 > 24.63.aaa.bbb.16416:
00:42:39.809721 24.63.aaa.bbb.16416 > 67.43.159.38.61672:
00:42:39.838496 67.43.159.38.61672 > 24.63.aaa.bbb.16416:
00:42:39.839227 24.63.aaa.bbb.16416 > 67.43.159.38.61672:
00:42:39.868960 24.63.aaa.bbb.16416 > 67.43.159.38.61672:
NOTE: 24.63.aaa.bbb is my IP and 67.43.159.38 is callpacket
So, If the ISP is merely blocking all outgoing 5060 traffic (tcp or udp), then this should work. If the ISP is blocking incoming 5060 (to the customer), that might be a problem.. I will have to build a test for that one. |
|
Reviews:
·ViaTalk
| said by rcilink: : NOTE: 24.63.aaa.bbb is my IP and 67.43.159.38 is callpacket [/code] So, If the ISP is merely blocking all outgoing 5060 traffic (tcp or udp), then this should work. If the ISP is blocking incoming 5060 (to the customer), that might be a problem.. I will have to build a test for that one. Let's not use incoming and outgoing because these are relative terms. Instead use source port and destination port.
I think you have it switched around. Take a look at your tcpdump:
said by rcilink:[code] 00:38:09.259827 24.63.aaa.bbb.53 > 67.43.159.38.5060: 00:38:09.342385 67.43.159.38.5060 > 24.63.aaa.bbb.53: [/code] According to this, you [24.63.aaa.bbb.53] are using port 53 as your source port but you are sending the packet to callpacket's port 5060 [67.43.159.38.5060]. And, Callpacket [67.43.159.38.5060] is replying back to you [24.63.aaa.bbb.53].
And, later:
said by rcilink:[code] *I placed a call and the following is the traffic I saw: 00:42:39.530119 67.43.159.38.5060 > 24.63.aaa.bbb.53: [/code] Callpacket is still communicating from its port 5060 [67.43.159.38.5060] to your port 53 [24.63.aaa.bbb.53].
From your tcpdumps, you are the one using UDP port 53 as a destination port for traffic termination. When you communicate with Callpacket, traffic terminating at Callpacket still goes to their destination UDP port of 5060.
Therefore, if the ISP is blocking UDP packets with a destination port of 5060, you changing your source port will not allow you to bypass the ISP's block.
See ya...
d.c. |
|
| Now I am confused... I use a Linux firewall (Mandrake, running Shorewall - IPtables).
The 'rules' file has the following lines in it:
#ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL
# PORT PORT(S) DEST
DROP:info loc net:161.247.133.94 tcp 80 -
DROP loc net:67.43.159.38 udp 5060 -
DROP loc net:67.43.159.38 tcp 5060 -
loc is any 192.168.1.x IP address on the internal network.
net in this case, is specific IP of 67.43.159.38 (voip.callpacket.com)
I left that first rule in there for testing. It is the IP of a supermarket web page.
If i load a browser and point to that page (www.stopandshop.com), it never loads (gets DROPPED). I have 'info', so I see it in the syslog.
So, I would say that the PC source IP is 192.168.1.75 and a random source port, with an intended destination port of 80 at the www.stopandshop.com IP.
So, my only guess is that the 53 UDP originating from my PAP2 to 'register' the SIP device must leave-open a return-packet path through the firewall, allowing them to use 5060 source port to point to my 'port 53'.
If you have some kind of firewall that will do it, try this quick test:
1. login to your firewall.
2. block all outgoing traffic to port 5060 destination IP=67.43.159.38 (block both UDP and TCP)
3. Change your softphone or PAP2 to use port 53 (replace 5060)
4. Reboot PAP2 or reset softphone.
5. Test call. does it work?
--
I am curious if others can get this working.. and help explain why I am seeing 5060 traffic (my 'source' IP is using port 53 to talk to the 'destination' IP (callpacket) at port 5060.. |
|
 kapilThe Kapil
join:2000-04-26
60606 | reply to OLFVOIPER
????????? |
|
Reviews:
·ViaTalk
| reply to rcilink
said by rcilink:Now I am confused... I use a Linux firewall (Mandrake, running Shorewall - IPtables). Drop down into a command shell and check your IPTables. If you are trying to discard connections with an UDP destination port of 5060, you should see a rule like the following in your OUTPUT chain:
REJECT udp -- anywhere anywhere udp dpt:5060 reject-with icmp-port-unreachable
If you see the above type of rule in the INPUT chain, then its in the wrong chain.
said by rcilink:So, my only guess is that the 53 UDP originating from my PAP2 to 'register' the SIP device must leave-open a return-packet path through the firewall, allowing them to use 5060 source port to point to my 'port 53'. Right. This is the default behavior of a multihomed Linux box with net.ipv4.ip_forward=1 and no IPTable rules blocking the FORWARDing.
That's not the issue. The issue is that if an ISP blocks packets TO UDP destination port 5060, then there's no way you can SIP REGISTER/INVITE with the majority of the VSPs since they are expecting you to send your SIP packets using a destination address of their SIP Proxy and a destination port of 5060. This is egress filtering. It's a lot more resource conserving since the packet is never released to the destination. Why attempt to route the packet to the destination just so you can filter it coming back when you could just drop the packet and not even have to worry about dealing with a return packet.
If the ISP is trying to squench VoIP by ingress filtering of packets with a UDP source port of 5060, then they are using a lot more resources than they need to. For international pipes, most upstream ISPs charge for what you dump up to them for conveyance. They don't normally charge you for receiving the traffic. So, it is much more cost-effective to filter outgoing packets instead of incoming packets.
See ya...
d.c. |
|
| OK, here's what I find:
# iptables -vL
. (snipped-out the non-relevant stuff)...
Chain loc2net (1 references)
pkts bytes target prot opt in out source destination
0 0 DROP udp -- any any anywhere ser.callpacket.com state NEW udp dpt:5060
0 0 DROP tcp -- any any anywhere ser.callpacket.com state NEW tcp dpt:5060
Do you feel that this should be blocking port 5060 (udp and tcp) to ser.callpacket.com ? (CNAME is voip.callpacket.com)
This rule should disallow any machine/device on my internal network from accessing port 5060 at callpacket. This is an attempt to simulate an ISP who blocks SIP port 5060. |
|
Reviews:
·ViaTalk
| Which rule chain is loc2net associated with (INPUT, OUTPUT, FORWARD)? And, for that rule that calls loc2net, is it limited in scope by an interface specification?
For testing purposes, you might just want to temporarily REJECT (instead of DROPing) all egress packets with a destination port of 5060.
See ya...
d.c. |
|
| said by im_chandave:Which rule chain is loc2net associated with (INPUT, OUTPUT, FORWARD)? And, for that rule that calls loc2net, is it limited in scope by an interface specification? loc2net is associated with eth0_fwd rule. It is a forward rule (in=eth0, the inside net) and (out=eth1, the public Internet).
I will have to do some more research (info to syslog, etc.)..
The whole point of this test was to simulate an ISP blocking port 5060 to a subnet. I think I have done that, and have been successful using port 53 on my equipment, even though port 5060 is still used on the callpacket equipment.
I will change the rule to report dropped/rejected packets (specific to port 5060) and let you know what I see. |
|
| I guess this new provider "vonics" is also using ports that are getting around the issue somehow as well.
Taimoor |
|
| reply to doc159
I just wanted to throw in my two cents' worth about the importance of this thread.
Although it focuses on providers in Pakistan blocking ports, I suspect this will become an increasing problem in countries where telecom providers are fighting to maintain their dominance.
I live in Brazil, where essential SIP ports have yet to be blocked by my ISP (the telephone company), but whose contract specifically states that the service cannot be used for VOIP. Of course, I use it anyway--Vonage, Free World Dialup and a couple of other providers--to facilitate contact Canada and the U.S.
It will not surprise me in the least if the telephone companies, which dominate broadband here, start blocking ports. Nor would it surprise me if this becomes common practice in other parts of the world where telecom providers have national or regional monopolies, and are also the primary source of broadband.
It would seem to me that at this stage a means of port flexibility in SIP and other VOIP systems becomes critically important. Even if you live in a country where this isn't likely to be an issue, it may become a problem when you require an inexpensive means of maintaining contact with relatives, friends and business associates elsewhere.
Off the soapbox now  |
|
| reply to rcilink
I am using a USA company that use non-conventional SIP ports. Everything has been working fine. Their servers are not setup on 5060. They are the best solution for port blocking issue. They will be hard to signup with since they cater to US customers only. I signed up when I visit USA last month. Email them and maybe the have a way for you. They are really cheap too $20 month for unlimited calls. I love it..Chao
Lokesh |
|
| Sorry I forgot the link.
www.myvoicecall.com |
|
cgigate
join:2003-05-12
Fort Worth, TX | reply to doc159
Vbuzzer is nice!
They are using port 80 for SIP!
it cannot be blocked! |
|
