[sip-comm-dev] [PATCH] ProtocolProviderServiceImpl and standard getProtocolDisplayName


#1

It's considered a usability improvement to have the ability to register a Google Talk account without explicit knowledge that the underlying protocol is Jabber. In practice, it means there's a need for an account registration wizard visually identifying itself with wording and imagery specific to Google Talk.

While investigating the possible approaches to achieving the above goal, it was discovered that the Jabber protocol implementation doesn't support customizing its display protocol name (ProtocolProviderService#getProtocolDisplayName) in contrast to the desire to such support in all protocol implementations.

Consequently, the idea was born and discussed to have ProtocolProviderService#getProtocolDisplayName implemented once and reused. Afterwards, duplications were noted in the ProtocolProviderService implementations. Thus it was suggested to have an abstract ProtocolProviderService implementation which could serve as "standard" base for protocol implementations that don't deviate too much from the other (in the parts that're to be implemented by the base in question).

The attached patch defines net.java.sip.communicator.impl.protocol.ProtocolProviderServiceImpl and uses it as the base for the existing protocol implementations (with the exception of MockProvider).

Additionally, it contains an attempt to generally ensure that the additional protocol-specific information can override the default protocol name (in a fashion similar to the existing support for the SIP protocol).

Regards,
Lubo

ProtocolProviderServiceImpl-and-standard-getProtocolDisplayName.patch (68.2 KB)


#2

Hello to all

I installed the latest debian distribuition from debian.org
After, I successfully installed alsa-oss, and the java-virtual-achine.

Then I successfully installed the sip-communicator_1.0-alpha2_i386.deb
package.

When I tried to lauch it for the first time I got this error:

maint@station03:~$ sip-communicator
WARNING: error instantiating 'java.util.logging.FileHandler,' referenced
by handlers, class not found
java.lang.ClassNotFoundException: java.util.logging.FileHandler,
   <<No stacktrace available>>
Exception during runtime initialization
java.lang.ExceptionInInitializerError
   <<No stacktrace available>>
Caused by: java.lang.NullPointerException
   <<No stacktrace available>>
maint@station03:~$

I have the following java installed:

maint@station03:~$ java -version
java version "1.4.2"
gij (GNU libgcj) version 4.1.2 20061115 (prerelease) (Debian 4.1.1-20)

Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
maint@station03:~$

Can anyone help me pass this error?
Thanks

Carlos

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#3

Hey Lubomir,

As discussed offline, I agree this is a good idea. A couple of quick
comments though:

Your ProtocolProviderServiceImpl would be needed by most of the protocol
implementations. You've left it inside the impl hierarchy, which makes
some sense since it is a semi-implementation, but which bundle is it
going in? Personally I'd prefer to see it inside the service.protocol
package.

Then, the Impl suffix is probably not very appropriate here since this
is not a protocol implementation of the service. How about using
AbstractProtocolProviderService instead? I believe a similar naming
convention is commonly used inside the JRE.

WDYT?

Emil

Lubomir Marinov написа:

···

It's considered a usability improvement to have the ability to register a
Google Talk account without explicit knowledge that the underlying protocol
is Jabber. In practice, it means there's a need for an account registration
wizard visually identifying itself with wording and imagery specific to
Google Talk.

While investigating the possible approaches to achieving the above goal, it
was discovered that the Jabber protocol implementation doesn't support
customizing its display protocol name
(ProtocolProviderService#getProtocolDisplayName) in contrast to the desire
to such support in all protocol implementations.

Consequently, the idea was born and discussed to have
ProtocolProviderService#getProtocolDisplayName implemented once and reused.
Afterwards, duplications were noted in the ProtocolProviderService
implementations. Thus it was suggested to have an abstract
ProtocolProviderService implementation which could serve as "standard" base
for protocol implementations that don't deviate too much from the other (in
the parts that're to be implemented by the base in question).

The attached patch defines
net.java.sip.communicator.impl.protocol.ProtocolProviderServiceImpl and uses
it as the base for the existing protocol implementations (with the exception
of MockProvider).

Additionally, it contains an attempt to generally ensure that the additional
protocol-specific information can override the default protocol name (in a
fashion similar to the existing support for the SIP protocol).

Regards,
Lubo

------------------------------------------------------------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#4

You're using GCJ. Assuming you've installed sun-java6, the next step would
be to use update-alternatives to use it instead. I'm using Ubuntu so the
exact steps probably aren't the same but it looks like
this<http://www.crazysquirrel.com/computing/debian/java.jspx>is what
you need. -Damian

···

On Thu, Jun 19, 2008 at 10:21 AM, Carlos Alexandre <Carlos.Alexandre@nav.pt> wrote:

Hello to all

I installed the latest debian distribuition from debian.org
After, I successfully installed alsa-oss, and the java-virtual-achine.

Then I successfully installed the sip-communicator_1.0-alpha2_i386.deb
package.

When I tried to lauch it for the first time I got this error:

maint@station03:~$ sip-communicator
WARNING: error instantiating 'java.util.logging.FileHandler,' referenced
by handlers, class not found
java.lang.ClassNotFoundException: java.util.logging.FileHandler,
  <<No stacktrace available>>
Exception during runtime initialization
java.lang.ExceptionInInitializerError
  <<No stacktrace available>>
Caused by: java.lang.NullPointerException
  <<No stacktrace available>>
maint@station03:~$

I have the following java installed:

maint@station03:~$ java -version
java version "1.4.2"
gij (GNU libgcj) version 4.1.2 20061115 (prerelease) (Debian 4.1.1-20)

Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
maint@station03:~$

Can anyone help me pass this error?
Thanks

Carlos

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#5

Dear Emil,

Thank you for your attention!

Your comments certainly make sense and I hope the patch attached to
this letter is in accord with them.

Your ProtocolProviderServiceImpl would be needed by most of the protocol
implementations. You've left it inside the impl hierarchy, which makes
some sense since it is a semi-implementation, but which bundle is it
going in? Personally I'd prefer to see it inside the service.protocol
package.

The previous patch used to place ProtocolProviderServiceImpl in the
bundle containing ProtocolProviderService. The one attached to this
letter moves the class in the service.protocol package.

Then, the Impl suffix is probably not very appropriate here since this
is not a protocol implementation of the service. How about using
AbstractProtocolProviderService instead? I believe a similar naming
convention is commonly used inside the JRE.

The patch attached to this letter does the renaming from
ProtocolProviderServiceImpl to AbstractProtocolProviderService.

On a side node, there're similar classes in the SIP Communicator
source code with the name pattern Abstract[Interface]Impl in contrast
to the Abstract[Interface] convention you referred me to.

Thank you,
Lubo

ProtocolProviderServiceImpl-and-standard-getProtocolDisplayName.patch (56.8 KB)

···

On Fri, Jun 20, 2008 at 11:40 AM, Emil Ivov <emcho@sip-communicator.org> wrote:

Hey Lubomir,

As discussed offline, I agree this is a good idea. A couple of quick
comments though:

Your ProtocolProviderServiceImpl would be needed by most of the protocol
implementations. You've left it inside the impl hierarchy, which makes
some sense since it is a semi-implementation, but which bundle is it
going in? Personally I'd prefer to see it inside the service.protocol
package.

Then, the Impl suffix is probably not very appropriate here since this
is not a protocol implementation of the service. How about using
AbstractProtocolProviderService instead? I believe a similar naming
convention is commonly used inside the JRE.

WDYT?

Emil

Lubomir Marinov написа:

It's considered a usability improvement to have the ability to register a
Google Talk account without explicit knowledge that the underlying protocol
is Jabber. In practice, it means there's a need for an account registration
wizard visually identifying itself with wording and imagery specific to
Google Talk.

While investigating the possible approaches to achieving the above goal, it
was discovered that the Jabber protocol implementation doesn't support
customizing its display protocol name
(ProtocolProviderService#getProtocolDisplayName) in contrast to the desire
to such support in all protocol implementations.

Consequently, the idea was born and discussed to have
ProtocolProviderService#getProtocolDisplayName implemented once and reused.
Afterwards, duplications were noted in the ProtocolProviderService
implementations. Thus it was suggested to have an abstract
ProtocolProviderService implementation which could serve as "standard" base
for protocol implementations that don't deviate too much from the other (in
the parts that're to be implemented by the base in question).

The attached patch defines
net.java.sip.communicator.impl.protocol.ProtocolProviderServiceImpl and uses
it as the base for the existing protocol implementations (with the exception
of MockProvider).

Additionally, it contains an attempt to generally ensure that the additional
protocol-specific information can override the default protocol name (in a
fashion similar to the existing support for the SIP protocol).

Regards,
Lubo

------------------------------------------------------------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#6

Hello to all
Thanks in advance for your help.
When I place a call to /from my SIPCommunicator to another phone,
everything works fine until I locally or remotely answer the call.

Then the Gui presents a failed message and I have these Severe log
messages (see below)

Has anyone have a clue ?
Thanks you

Carlos

...
RTPSessMgr not match : ULAW/rtp, 32000.0 Hz, 8-bit, Mono, FrameSize=8
bits - ilbc/rtp, Unknown Sample Rate
RTPSessMgr not match : ULAW/rtp, 32000.0 Hz, 8-bit, Mono, FrameSize=8
bits - ALAW/rtp, Unknown Sample Rate
RTPSessMgr not match : ULAW/rtp, 32000.0 Hz, 8-bit, Mono, FrameSize=8
bits - speex/rtp, Unknown Sample Rate
RTPSessMgr not match : ALAW/rtp, 32000.0 Hz, 8-bit, Mono, FrameSize=8
bits - ilbc/rtp, Unknown Sample Rate
RTPSessMgr not match : ULAW/rtp, 48000.0 Hz, 8-bit, Mono, FrameSize=8
bits - ilbc/rtp, Unknown Sample Rate
RTPSessMgr not match : ULAW/rtp, 48000.0 Hz, 8-bit, Mono, FrameSize=8
bits - ALAW/rtp, Unknown Sample Rate
RTPSessMgr not match : ULAW/rtp, 48000.0 Hz, 8-bit, Mono, FrameSize=8
bits - speex/rtp, Unknown Sample Rate
RTPSessMgr not match : ALAW/rtp, 48000.0 Hz, 8-bit, Mono, FrameSize=8
bits - ilbc/rtp, Unknown Sample Rate
RTPSessMgr not match : ALAW/rtp, 44100.0 Hz, 8-bit, Mono, FrameSize=8
bits - ilbc/rtp, Unknown Sample Rate
RTPSessMgr not match : ALAW/rtp, 44100.0 Hz, 8-bit, Mono, FrameSize=8
bits - ilbc/rtp, Unknown Sample Rate
16:50:14.172 SEVERE:
impl.protocol.sip.OperationSetBasicTelephonySipImpl.answerCallParticipan
t().1788 No sdp data was provided for the ok response to an INVITE
request!
net.java.sip.communicator.service.media.MediaException: Failed to create
an RTP send stream for format ALAW/rtp, 44100.0 Hz, 8-bit, Mono,
FrameSize=8 bits
        at
net.java.sip.communicator.impl.media.CallSessionImpl.createSendStreams(C
allSessionImpl.java:659)
        at
net.java.sip.communicator.impl.media.CallSessionImpl.processSdpOffer(Cal
lSessionImpl.java:596)
        at
net.java.sip.communicator.impl.protocol.sip.OperationSetBasicTelephonySi
pImpl.answerCallParticipant(OperationSetBasicTelephonySipImpl.java:1773)
        at
net.java.sip.communicator.impl.gui.main.call.CallManager$AnswerCallThrea
d.run(CallManager.java:891)
Caused by: javax.media.format.UnsupportedFormatException: Format of
Stream not supported in RTP Session Manager
        at
com.sun.media.rtp.RTPSessionMgr.createSendStream(RTPSessionMgr.java:1130
)
        at
com.sun.media.rtp.RTPSessionMgr.createSendStream(RTPSessionMgr.java:1281
)
        at
net.java.sip.communicator.impl.media.CallSessionImpl.createSendStreams(C
allSessionImpl.java:652)
        ... 3 more
16:50:14.173 SEVERE: impl.gui.main.call.CallManager.run().895 Could not
answer to : analog 1 <"analog 1" <sip:7001@TestDomain>>;status=Failed
caused by the following exception:
net.java.sip.communicator.service.protocol.OperationFailedException:
Failed to created an SDP description for an ok response to an INVITE
request!
16:50:28.232 SEVERE:
impl.gui.main.login.LoginManager.registrationStateChanged().378 null
maint@station03:~$

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#7

Hey Lubo,

Lubomir Marinov написа:

The patch attached to this letter does the renaming from
ProtocolProviderServiceImpl to AbstractProtocolProviderService.

Thanks! Just committed.

On a side node, there're similar classes in the SIP Communicator
source code with the name pattern Abstract[Interface]Impl in contrast
to the Abstract[Interface] convention you referred me to.

I imagine you refer to the AbstractContractGroupXxxImpl classes. Indeed
it would probably have made more sense if their names did not contain
the Abstract part. I can easily see why the implementors didn't get rid
of it though. Guess they simply added Impl to everything that comes from
the service hierarchy which is not entirely senseless either.

Oh well, you'll get to fix that when you become a developer :wink:

Cheers
Emil

···

Thank you,
Lubo

On Fri, Jun 20, 2008 at 11:40 AM, Emil Ivov <emcho@sip-communicator.org> wrote:

Hey Lubomir,

As discussed offline, I agree this is a good idea. A couple of quick
comments though:

Your ProtocolProviderServiceImpl would be needed by most of the protocol
implementations. You've left it inside the impl hierarchy, which makes
some sense since it is a semi-implementation, but which bundle is it
going in? Personally I'd prefer to see it inside the service.protocol
package.

Then, the Impl suffix is probably not very appropriate here since this
is not a protocol implementation of the service. How about using
AbstractProtocolProviderService instead? I believe a similar naming
convention is commonly used inside the JRE.

WDYT?

Emil

Lubomir Marinov написа:

It's considered a usability improvement to have the ability to register a
Google Talk account without explicit knowledge that the underlying protocol
is Jabber. In practice, it means there's a need for an account registration
wizard visually identifying itself with wording and imagery specific to
Google Talk.

While investigating the possible approaches to achieving the above goal, it
was discovered that the Jabber protocol implementation doesn't support
customizing its display protocol name
(ProtocolProviderService#getProtocolDisplayName) in contrast to the desire
to such support in all protocol implementations.

Consequently, the idea was born and discussed to have
ProtocolProviderService#getProtocolDisplayName implemented once and reused.
Afterwards, duplications were noted in the ProtocolProviderService
implementations. Thus it was suggested to have an abstract
ProtocolProviderService implementation which could serve as "standard" base
for protocol implementations that don't deviate too much from the other (in
the parts that're to be implemented by the base in question).

The attached patch defines
net.java.sip.communicator.impl.protocol.ProtocolProviderServiceImpl and uses
it as the base for the existing protocol implementations (with the exception
of MockProvider).

Additionally, it contains an attempt to generally ensure that the additional
protocol-specific information can override the default protocol name (in a
fashion similar to the existing support for the SIP protocol).

Regards,
Lubo

------------------------------------------------------------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

------------------------------------------------------------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#8

Hello to all
Thanks in advance for your help.
When I place a call to /from my SIPCommunicator to another phone,
everything works fine until I locally or remotely answer the call.

Then the Gui presents a failed message and I have these Severe log
messages (see below)

Has anyone have a clue ?
Thanks you

Carlos

...
RTPSessMgr not match : ULAW/rtp, 32000.0 Hz, 8-bit, Mono, FrameSize=8
bits - ilbc/rtp, Unknown Sample Rate
RTPSessMgr not match : ULAW/rtp, 32000.0 Hz, 8-bit, Mono, FrameSize=8
bits - ALAW/rtp, Unknown Sample Rate
RTPSessMgr not match : ULAW/rtp, 32000.0 Hz, 8-bit, Mono, FrameSize=8
bits - speex/rtp, Unknown Sample Rate
RTPSessMgr not match : ALAW/rtp, 32000.0 Hz, 8-bit, Mono, FrameSize=8
bits - ilbc/rtp, Unknown Sample Rate
RTPSessMgr not match : ULAW/rtp, 48000.0 Hz, 8-bit, Mono, FrameSize=8
bits - ilbc/rtp, Unknown Sample Rate
RTPSessMgr not match : ULAW/rtp, 48000.0 Hz, 8-bit, Mono, FrameSize=8
bits - ALAW/rtp, Unknown Sample Rate
RTPSessMgr not match : ULAW/rtp, 48000.0 Hz, 8-bit, Mono, FrameSize=8
bits - speex/rtp, Unknown Sample Rate
RTPSessMgr not match : ALAW/rtp, 48000.0 Hz, 8-bit, Mono, FrameSize=8
bits - ilbc/rtp, Unknown Sample Rate
RTPSessMgr not match : ALAW/rtp, 44100.0 Hz, 8-bit, Mono, FrameSize=8
bits - ilbc/rtp, Unknown Sample Rate
RTPSessMgr not match : ALAW/rtp, 44100.0 Hz, 8-bit, Mono, FrameSize=8
bits - ilbc/rtp, Unknown Sample Rate
16:50:14.172 SEVERE:
impl.protocol.sip.OperationSetBasicTelephonySipImpl.answerCallParticipan
t().1788 No sdp data was provided for the ok response to an INVITE
request!
net.java.sip.communicator.service.media.MediaException: Failed to create
an RTP send stream for format ALAW/rtp, 44100.0 Hz, 8-bit, Mono,
FrameSize=8 bits
        at
net.java.sip.communicator.impl.media.CallSessionImpl.createSendStreams(C
allSessionImpl.java:659)
        at
net.java.sip.communicator.impl.media.CallSessionImpl.processSdpOffer(Cal
lSessionImpl.java:596)
        at
net.java.sip.communicator.impl.protocol.sip.OperationSetBasicTelephonySi
pImpl.answerCallParticipant(OperationSetBasicTelephonySipImpl.java:1773)
        at
net.java.sip.communicator.impl.gui.main.call.CallManager$AnswerCallThrea
d.run(CallManager.java:891)
Caused by: javax.media.format.UnsupportedFormatException: Format of
Stream not supported in RTP Session Manager
        at
com.sun.media.rtp.RTPSessionMgr.createSendStream(RTPSessionMgr.java:1130
)
        at
com.sun.media.rtp.RTPSessionMgr.createSendStream(RTPSessionMgr.java:1281
)
        at
net.java.sip.communicator.impl.media.CallSessionImpl.createSendStreams(C
allSessionImpl.java:652)
        ... 3 more
16:50:14.173 SEVERE: impl.gui.main.call.CallManager.run().895 Could not
answer to : analog 1 <"analog 1" <sip:7001@TestDomain>>;status=Failed
caused by the following exception:
net.java.sip.communicator.service.protocol.OperationFailedException:
Failed to created an SDP description for an ok response to an INVITE
request!
16:50:28.232 SEVERE:
impl.gui.main.login.LoginManager.registrationStateChanged().378 null
maint@station03:~$

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#9

In accord with the goal of the introduction of AbstractProtocolProviderService, the attached patch provides a standard isRegistered implementation which seems to be the same in all current AbstractProtocolProviderService extenders anyway.

Best regards,
Lubo

Emil Ivov wrote:

AbstractProtocolProviderService-isRegistered.patch (10.9 KB)

···

Hey Lubo,

Lubomir Marinov ������:

The patch attached to this letter does the renaming from
ProtocolProviderServiceImpl to AbstractProtocolProviderService.

Thanks! Just committed.

On a side node, there're similar classes in the SIP Communicator
source code with the name pattern Abstract[Interface]Impl in contrast
to the Abstract[Interface] convention you referred me to.

I imagine you refer to the AbstractContractGroupXxxImpl classes. Indeed
it would probably have made more sense if their names did not contain
the Abstract part. I can easily see why the implementors didn't get rid
of it though. Guess they simply added Impl to everything that comes from
the service hierarchy which is not entirely senseless either.

Oh well, you'll get to fix that when you become a developer :wink:

Cheers
Emil

Thank you,
Lubo

On Fri, Jun 20, 2008 at 11:40 AM, Emil Ivov<emcho@sip-communicator.org> wrote:

Hey Lubomir,

As discussed offline, I agree this is a good idea. A couple of quick
comments though:

Your ProtocolProviderServiceImpl would be needed by most of the protocol
implementations. You've left it inside the impl hierarchy, which makes
some sense since it is a semi-implementation, but which bundle is it
going in? Personally I'd prefer to see it inside the service.protocol
package.

Then, the Impl suffix is probably not very appropriate here since this
is not a protocol implementation of the service. How about using
AbstractProtocolProviderService instead? I believe a similar naming
convention is commonly used inside the JRE.

WDYT?

Emil

Lubomir Marinov ������:

It's considered a usability improvement to have the ability to register a
Google Talk account without explicit knowledge that the underlying protocol
is Jabber. In practice, it means there's a need for an account registration
wizard visually identifying itself with wording and imagery specific to
Google Talk.

While investigating the possible approaches to achieving the above goal, it
was discovered that the Jabber protocol implementation doesn't support
customizing its display protocol name
(ProtocolProviderService#getProtocolDisplayName) in contrast to the desire
to such support in all protocol implementations.

Consequently, the idea was born and discussed to have
ProtocolProviderService#getProtocolDisplayName implemented once and reused.
Afterwards, duplications were noted in the ProtocolProviderService
implementations. Thus it was suggested to have an abstract
ProtocolProviderService implementation which could serve as "standard" base
for protocol implementations that don't deviate too much from the other (in
the parts that're to be implemented by the base in question).

The attached patch defines
net.java.sip.communicator.impl.protocol.ProtocolProviderServiceImpl and uses
it as the base for the existing protocol implementations (with the exception
of MockProvider).

Additionally, it contains an attempt to generally ensure that the additional
protocol-specific information can override the default protocol name (in a
fashion similar to the existing support for the SIP protocol).

Regards,
Lubo

------------------------------------------------------------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

------------------------------------------------------------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#10

Hello to all

I installed SipCommunicator on debian, and the installation was very
smooth, as well as of all the dependencies.

I launched SipCommunicator and it registered fine on my asterisk
registrar.

The problem is that it seems that SIP Communicator doesn support any
codec.

When answering a call, I get this SEVERE warning that format ALAW/rtp,
44100.0 Hz, 8-bit, Mono is not supported.

Do I need to install anything else on debian ? Ive been using
SIP-Communicator on Windows for a while and this never happened.

Thankyou very much

Carlos

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#11

Hello again Carlos,

you may want to try one of the latest nightly builds. I believe that this problem has been fixed recently and we'd be happy to have your feedback.
As answered in another mail, you shouldn't need to install anything else.

Cheers,
Martin

Carlos Alexandre wrote:

···

Hello to all

I installed SipCommunicator on debian, and the installation was very
smooth, as well as of all the dependencies.

I launched SipCommunicator and it registered fine on my asterisk
registrar.

The problem is that it seems that SIP Communicator doesn support any
codec.

When answering a call, I get this SEVERE warning that format ALAW/rtp,
44100.0 Hz, 8-bit, Mono is not supported.

Do I need to install anything else on debian ? Ive been using
SIP-Communicator on Windows for a while and this never happened.

Thankyou very much

Carlos

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net