Hong Kong Broadband
Hong Kong Broadband
Hong Kong Broadband provides SIP-based VOIP connections for residental service. Each account provides unlimited incoming and outgoing calls. The service supports Local Number Portability so you can move your local fixed-line number (an 8-digit Hong Kong phone number starting with the digit 2 or 3) to your HKBN subscription.
HKBN's core uses Nortel's Networks Communication Server 2000 (Compact softswitch) and the Packet Voice Gateway 15000. At the residences, ATA boxes (called Integrated Access Devices, IAD) are provided to subscribers. Additionally, a softphone (Nortel's Multimedia PC Client v2.0) option is available for people to use the VOIP service without the need for an ATA box.
Default features include:
- Caller ID
- Call Blocking
- Call Waiting
- Call Forwarding
- Call Conferencing
- Call History (with the Nortel softphone)
- Instant Messaging (with the Nortel softphone).
Service cost (with the ATA) is $88 HKD/month (~$11.28 USD/month). If you want to use the softphone or already have an ATA then you can opt for the softphone option that is only $48 HKD/month (~$6.15 USD/month). The softphone option is great for the BYOD crowd since the Nortel core supports most SIP devices.
Prior to October 2005, most of the website was in Traditional Chinese with no English translation. If you click on the ENG button, only the menubar changes to English. If you do plan on subscribing, the best thing would be to goto the Broadband Phone->Broadband Phone Box menu selection if you want to subscribe to the service and get the Nortel ATA. If you want the softphone/BYOD route, choose the Broadband Phone->Soft Client option.
Starting in October 2005, HKBN rolled out the "2b" Softphone service. It does have English translations and no longer required a Hong Kong residential address. The "2b" service is available via the URL http://www.2b.com.hk. This service is similar to the old softphone service but with an updated Nortel softphone (it uninstalls the old version) and a different SIP proxy and SIP domain/realm. Additionally, the "2b" service has a website you can use to UN-SIP_REGISTER your softphone. This comes in handy when you need to clear your SIP REGISTER from HKBN's SIP proxy. You might need to manually do this if you switch back and forth between the softphone and an ATA like the Linksys PAP2. Access your Personal Assistant website, http://pa.2b.com.hk, login, and select the "2b Reset" option in the left-hand pane.
Update: 2006/MarAs of March 2006, HKBN no longer supports the old softphone system. All users of the old softphone were migrated to the "2b" service. For users of the old softphone accounts, you can find information about how to migrate your old softphone account to the new "2b" service by looking here.
Update: 2006/MayHKBN is doing an upgrade to their service again. If you've received an email from Tech Support to install a patch for the softphone, that means that your account has been upgraded/migrated. Once upgraded, you need to add "hk" to the end of your phone number to login. (Ex. 3500XXXXhk). They are slowly upgrading all accounts.
SIP Client HintsIf you plan going the BYOD route with HKBN, here are some facts that might facilitate the setup.
- RFC3581 ("received" and "rport") is supported. Therefore, when the SIP registry response to your SIP REGISTER command, it will return the source IP address and UDP port it saw your SIP UA used.
- SIP INVITEs from your SIP UA must provide authentication information.
- SIP INVITEs from HKBN will NOT have authentication information when sent to your SIP UA.
- Symmetric RTP is used by the Nortel Packet Voice Gateway...with a twist...read the next line for more details.
- When early media (SIP response 183) occurs as a result of an incoming INVITE from HKBN, the Packet Voice Gateway will terminate the call if the source UDP port for the RTP connection differs from the source port specified in SDP of the SIP 200 response from your SIP UA. Therefore, if your router/firewall has a tendency to re-NAT or re-PNAT the source address and/or port, you must have STUN or UPNP support on your SIP UA in order to make sure you put in the right IP address and/or port in your SDP.
- DTMF codes are inband.
- The Packet Voice Gateway is configured to only support A-law, u-law, and GSM. If you present it with any other codecs, it might not start the RTP connection to your SIP UA.
- If you subscribed to the service before October 2005, the SIP proxy should be mcs1.hkbn.net instead of s12.hkbn.net as stated in the softphone's installation guide.
- If you subscribed to the "2b" service then the SIP proxy should be s21.hkbntel.net/s22.hkbntel.net (depending on which they assigned you) but the SIP Domain/Realm should be s2hkbntel.net.
- The "2b" service uses a RTP frame size of 20 milliseconds. If your RTP frame size does not match then incoming calls will terminate as soon as you answer the call. Checkout http://forum.voxilla.com/linksys-sipura-voip-support-forum/connecting-hkbn-2b-13944-7.html#post75324|Voxilla] or BroadBandReports for more details.
An explanation of why some of you can register with HKBN but not make and/or receive callsThere has been a lot of people discovering that they can get their ATA to register with HKBN's SIP proxy and yet they still cannot make and/or receive calls. The problem might lay with the behavior of your router.
Some routers (like the D-Link DI and WBR series) do not support source-port preservation. What this means is that origination ports used by an application on machines running behind the router are not guaranteed to have that same origination number when the packet passes through the router. In the case of SIP packets, your ATA might use an origination port of UDP 5060. When the packet transverses the D-Link router, the D-Link will remap the origination port as some high number (50K - 65K) port.
Your ATA thinks the destination will see that packet coming from an origination port of UDP 5060 and so, in the SIP message, the ATA announces its availability on UDP 5060. This is not too much a problem for most VoIP Service Providers (VSP) because they have a tendency to ignore the contact info inside the SIP message and instead, use the network address and port it saw on the incoming SIP packet. So, even if your ATA is configured to use UDP 5060 as the origination port, AND your SIP REGISTERs list UDP port 5060 as your contact port, HKBN will ignore that information and instead send all SIP INVITEs to the IP and origination port it saw the SIP REGISTER come from. Since SIP REGISTER require authetication, the is no problem with sending the wrong data to the wrong person.
With the audio channels, it's different. The RTP protocol does not have any authentication information associated with it. As a matter of fact, the information about which IP address and UDP port to use is carried in the SIP INVITE and SIP replies. As a result, HKBN is very stringent about people announcing that they will originate a RTP stream from one IP and UDP port but use another IP and/or UDP port when actually sending the RTP stream. HKBN's firewall appears to look into the SIP INVITEs and replies, detect the addressing info for the RTP streams and automatically setup rules to allow the traffic into their network. It appears that they are lenient with the IP address but not the UDP port. As a result, you might give them a private network number (something your router handed to your ATA), and the RTP would still establish properly. But, they are less lenient on the UDP origination ports because they need correctness to support Symmetric RTP.
Standard RTP states that only the destination address and port are important. So, in the case of an outgoing call to 1878200 (HK Observatory) using standard RTP, my ATA would send a SIP INVITE to HKBN's SIP proxy. Within the SIP INVITE is the IP and UDP port that I will listen on for inbound audio (weather announcement when HKO answers the phone and starts speaking). HKBN, upon receiving my SIP INVITE will attempt to make the call for me. When it succeeds, it will send a SIP REPLY (200 OK) with information about which IP and port I should send my outbound audio towards HKBN (for things like my DTMF touch-tones when select HKO menu options). With standard RTP there are two separate RTP streams. This cause 2 separate rules in their firewall.
Since HKBN uses Symmetric RTP to minimize rules inside the firewall, the origination AND destination addresses are important now. The same call to HKO, under Symmetric RTP, results in only one RTP stream. The difference is that when HKBN receives the information about your ATA's listening port, it will expect that you also use that same listening port number as your origination port number for your outbound audio (the stream that will carry your voice or DTMF touch-tones). The rules inside the firewall will be set to so that if you say you are listening on UDP 16384, then it will expect you to send your audio from UDP 16384 as well.
A non-source-port preserving router screws up this whole scenario because it will ignore the fact that you want (and need) to use UDP 16384 as the origination port in order to communicate with the other end. It will just pick some arbitrary high number, use that as the origination port and blast off the packet to the destination. When that packet gets to HKBN's firewall, it will see that it doesn't have a rule associating that origination port with a current CALL and drop it. Additionally, since HKBN didn't see you start sending audio to them, it will terminate your call.
Asterisk ConfigurationHere are extracts of my sip.conf and extensions.conf I use to connect my Asterisk system to HKBN. If you are subscribed to the HKBN "2b" service, then look here. If you subscribed before October 2005, then you should look here. The Asterisk box had a Static IP and was behind a Firewall/NAT that I portforwarded the SIP port and RTP ports.
Sipura SPA or Linksys PAP2 Configuration
X-Ten X-Lite Configuration
- xten settings HKBN
- HKBN 2b Accounts
Please update this page with new information, just login and click on the "Edit" or "Discussion" tab. Get a free login here: Register Thanks! - Find us on Google+