Alexander Chemeris wrote:
> Hello,
>
> On 2/11/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>   
>>  Does it make sense to use SipPimClient at all? Given the problems that
>> Adrzej described I think it's more reasonable to find a library for icq,
>> aim, jabber, msn in C or C++ and use that instead of the code in
>> sipxstacklib. How many softphones will understand your messages?
>>     
> All softphones compliant to RFC 3428.
>
>   
>> If you use icq your softphone can connect to icq server and users that have
>> plain icq client without a phone will be able to see you and chat with you.
>>     
> 1) ICQ is proprietary protocol. Alternate clients are not supported and may
>      get brocken in a sec. As an active icq user I remember a bunch of such
>      incidents.
> 2) It require internet connection. There is no intranet icq version (icqcorp
>      stop its progress in '98).
> 3) Ok, you've said jabber. Yes, it solve 1) and 2). But why should I maintain
>      jabber server in addition to SIP server, if SIP fulfil all my 
> requirements?
>      Moreover if it could be done with one library.
>
> What I want to say - do not forgot about corporate users, and do not forget
> that if something could be done easy way, it have to be done this way.
>
>   

The number of users using ICQ/MSN/Jabber/AIM clients (without phone) is 
much higher than the number of users using RFC 3428 compliant clients. A 
Softphone supporting these protocols is in a slight advantage if the 
interface is intuitive and offers similar functionality as comparable 
messaging clients. I think even the disadvantage of having to update the 
messaging libraries due to protocol changes outweigh the downsides. If 
softphone supports autoupdate then it's not so bad.

It depends on what kind of softphone he is trying to produce. If its 
aimed at intranet users then he should implement SIP instant messaging. 
But if it's aimed at internet users then it's a waste of time.

Also consider that people might be using different softphones that 
aren't compliant to RFC 3428 and won't abandon them just because this 
single feature is missing.

Jaro

_______________________________________________
sipxtapi-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/

Reply via email to