For our three-party conference test, we made a call from the PSTN through BroadSoft's gateway, and attempted to transfer the call to every other phone.
How We Tested
click to enlarge
|
For our message waiting indicator test, we left voicemail messages and then read them to see if the indicator turned on and off correctly. We also tested each phone's ability to check BroadSoft's voice-mail product.
Finally, for our call-pickup test, we put all the phones in a "call pickup group" using BroadSoft's Web-based provisioning software. We then called one phone in the group and attempted to pick up the call from each of the other phones by dialing the associated call-pickup *98 feature code.
Network Address Translation presents a number of problems for SIP and VoIP, stemming from the fact that NAT addresses are not routable on the Internet.
This doesn't stop clients with NAT addresses from accessing a Web server using a simple protocol like HTTP, for example, because the NAT device substitutes its own external, routable return address before transmitting to the Web server. The Web server then sends a response to the NAT device's external address. Because the NAT device keeps track of the initial request, it knows to which internal NAT address to forward the packet when it arrives.
The same process, however, does not work for SIP, because of the way SIP deals with IP addresses. When a SIP client initiates a session with another client or server, it puts its IP address in the application layer of its initial request. This is because SIP is designed so that it can reroute responses to different paths than the requests (see "It's Time To Take a Look at SIP," for an in-depth explanation of the SIP protocol). When the receiver is sending back its response, it uses this return IP address (which it gleans from the application layer of the initial request) as the destination address of the IP packet that it sends back.