We have made every attempt to make our projects compliant with the SIP standards so that you can use SIP-compliant SIP phones with SipExchange and Jiplet Container. But we are finding out that not all SIP phones are working because either early versions of our projects had some limitations or more likely, the SIP phones do not comply to standards fully. So we have decided to try out SipExchange and Jiplet Container (with the Jiplet Reference Application installed) with various SIP phones to verify their level of interoperability.
Click any of these links to see our experience with these phones:
NOTES for configuring any of the SIP phones:
1) You’ll be required to enter the network address information of a SIP server with which the phone will register. The SIP server can be SipExchange or Jiplet Container with the Jiplet Reference Application installed. Both of these provide SIP registration, proxy and presence functionality that the client phone can use. The phone client configuration screen may call it “server”, “proxy”, or “registrar”. The value to enter for it is the IP address or hostname where the SIP server is running. Append “:port#” to the value you enter if the server is using a port other than the default 5060 for SIP (this would be specified in the SIP server’s configuration server.xml file, connector, jip-ports parameter). For example, you can enter the value: 192.168.112.1:4000.
2) You’ll be required to enter a user or authorization name and password while configuring the phone, along with a domain name. Each SIP user is associated with a ‘domain’, and the domain is the part of a user’s SIP address after the ‘@’, such as “email@example.com”. The SIP phone will register with the SIP server using this information, which must be pre-configured on the SIP server. If your SIP server is the Jiplet Container with the Jiplet Reference Application, you can configure your phone with already pre-defined users “amit” or “becky” and password = a1b2c3d4, and use domain = cafesip.org. If your SIP server is SipExchange, you will need to have defined a domain and a subscriber assigned to that domain as part of SipExchange post-installation, and use that information when configuring the SIP phone.
From Counterpath (formerly XTen) http://www.counterpath.com/x-lite.html
This is a very nice phone and we have used this phone from the very beginning to test out our SIP projects. The Windows version works very well with SipExchange and the Jiplet Container running the Jiplet Reference Application, but we have not tried the Linux version yet. The phone supports voice calls, IM and presence operations (buddy list) and all of these functions seem to work well with our projects.
Counterpath offers non-free SIP soft phones that are full-featured – supports voice, video, buddy list and the works. We have not tested the server with these phones though.
Note on presence behavior:
When the X-Lite user logs in and a contact in the buddy list is off-line, the phone starts a subscription but it is immediately dropped because the SUBSCRIBE response has no Contact Header (the contact is offline). When the contact later comes online, the X-Lite phone does not pick up the status change immediately due to the dropped subscription. However, after some time, the X-Lite phone re-subscribes and then shows the contact’s online status.
From Counterpath (formerly XTen) http://www.counterpath.com/
This is a very nice phone that works on PDAs running Windows Mobile operating system. The phone works very well with SipExchange. As with most PDA applications, the phone supports only basic functionalities compared to the offerings on a full-blown operating system. The phone supports voice calls only and does not support presence operations and instant messaging.
NOTE: It appears that Counterpath is not offering this software for sale any longer. It is a pity because the phone worked well.
Please see the common configuration notes.
From the bottom-level menu, select System Settings -> Sip Proxies.
Setup the Username, Password and Domain as described in Note 2 above.
For the SIP Proxy and Outb Proxy entries, enter the SIP server address information (see Note 1 above).
From PhonerLite http://www.phonerlite.de/index_en.htm
This phone works well with our projects. The voice and the IM work well. The phone does not provide video capability yet. Unfortunately, the presence functionality offered by this phone is not supported by SipExchange yet.
Please see the common configuration notes.
From the top-level menu, select Options->Configuration.
On the Server sub-tab, enter the SIP server address information (see Note 1 above). Also, checkmark the ‘Register’ box. For the Domain/Realm, enter the domain name described in Note 2 above.
On the User sub-tab, enter the User name and Authentication name (typically the same) and Password as described in Note 2 above.
From VNET-CORP http://vnet-corp.com/iSip.htm
This phone has promise. We have tried it out on iPod with the server running on Windows.
So far we have been successful in registering the iSip phone and having it receive a call from another registered user.
We did have to turn off the windows firewall completely. Just having a firewall exception for udp/5060 wasn’t enough, the iSip couldn’t register until the firewall was off.
We have not yet been able to complete a call to another registered user from iSip.
This needs investigation.
From Microsoft Corp.
We test with Version 5.1.0680, pre-Microsoft Office Live Communications Server. Later versions do not work as they are less compliant to SIP RFC standards.
We were not able to make the messenger send or receive instant messages. However, you should be able to establish voice and video calls.
We have not been able to make messenger work when TCP/IP is selected as the transport protocol.
The messenger cannot handle an auth challenge when the user signs out. It keeps re-sending the un-REGISTER message and we keep challenging. We are not sure if it is a bug in the messenger or design intent. As a work-around, in the server.xml file, modify the <realms> element and modify the attribute “auth-on-logout” to be “false”. Please read the comments on this in that file with regards to the security implications.
If you want to check out the presence/buddylist operation, you must set the “auth-on-logout” (see above) to false; otherwise your other users won’t be able to see the online/offline status change of the messenger user. But even with this setting, when you logout with messenger it will continue sending unregister messages for some period of time even after the messenger login page pops back up. If you log back in with messenger too soon, your other users will show the messenger user as offline even though you have logged back in. The reason for this is because after the re-login REGISTER message has been processed by the server (and the online status sent to watchers), if an un-REGISTER message from the previous logout is received at the server, the server will notify the watcher(s) that the messenger user has gone offline. As a work-around, be sure to wait enough time after logout (40-50 seconds) before logging back in with messenger, otherwise your other users may not have the correct status information for the messenger user.