[sip-comm-dev] Audio codecs fail when testing SIP Communicator compatibility with X-Lite


#1

Hi all,

I and a co-worker have been testing SIP calls between SC and several other
clients, and we ran into some serious audio codec problems a week or two ago
when using SC with X-Lite (http://www.counterpath.com/x-lite.html). Even
though we could see RTP media being sent in both directions in Wireshark, no
audio could be heard at the SC endpoint. Suspecting a codec support problem,
we decided to start testing each codec SC offers. I will attempt to
summarize our findings thus far, and in the process I'm sure I will reveal
how little I know about codecs. This is not by any means a complete test,
but there is, I hope, enough information here to illustrate the problem for
our codec experts :o)

We tested with Windows XP and SC nightly build 1897 (this was the current
version of SC when we tested). I had similar experiences with X-Lite several
months ago but never got to do any detailed testing, so I believe this is
not a new problem.

*1) Calls placed with all codecs enabled:*

Calls placed from SC to XL: Wireshark shows RTP media flows in both
directions. Audio can be heard at XL endpoint. *No* audio can be heard at SC
endpoint.

Calls placed from XL to SC: Same behavior as above.

*2) Both clients set to force u-law:*

Calls placed from SC to XL: Wireshark shows RTP media flows in both
directions. Audio can be heard at XL endpoint. *No* audio can be heard at SC
endpoint.

Calls placed from XL to SC: Same behavior.

*3) Set to force a-law:*

Calls placed from SC to XL: Wireshark shows RTP media flows in both
directions. Audio can be heard at XL endpoint. *No* audio can be heard at SC
endpoint.

Calls placed from XL to SC: Same behavior.

*4) Set to force** ilbc:*

Calls placed from SC to XL: Wireshark shows that SC tries to send u-law
media, but it is rejected as ICMP destination unreachable, and it never
reaches a Wireshark running on the XL endpoint. No media reaches XL
endpoint. SC endpoint appears to recieve media from XL, but no audio is
heard at the SC endpoint.

Calls placed from XL to SC: Calls fail. Closer inspection shows that media
negotiation failed.

I don't know enough about ilbc to know what this means, but SC is using
codec #97, while XL is using #98 and #101. XL responds to this conflict by
offering it's default codec of u-law. In contrast, SC simply abandons the
call (actually, SC sent an SDP offering only the video codecs).

*5) XL does not support g-723 codec.* No tests conducted.

*6) Set to force **GSM:*

Calls placed from SC to XL: Wireshark shows RTP media flows in both
directions, but no audio can be heard at either end.

Calls placed from XL to SC: Wireshark shows RTP media flows in both
directions. Audio can be heard at XL endpoint. *No* audio can be heard at SC
endpoint.

Using the GSM codec seems to consistently and violently crash XL (so the
problem may not be on SC's end).

*7) Set to force DVI:*

Calls placed from SC to XL: SC cannot call out using either DVI codec
offered in the SC media config window. It gets as far as 100 (Trying), then
the call fails.

Calls placed from XL to SC: No audio heard on either end. XL offers Codec 5
(DVI), and Codec 101, but SC doesn't accept either one in its response.

Using the dvi codecs sometimes made XL crash.

*Other Observations:*

- The SC media configuration window seemed to be unstable. The preferred
order for the codecs seemed to be randomly shuffled every time a change to
the enabled codecs was made and the client was restarted, and this didn't
give me, as a user, a high degree of confidence that my preferences were
actually being stored properly or honored. I believe this is a known issue?

- Both DVI codecs in the SC media configuration window have an identical
label, and with the randomization of the list, it was impossible to keep
track of which one I was testing.

- X-Lite and SC both seem to work fine with our Polycom PVX softclients.
However, I haven't tried testing the enforcement of specific codecs between
SC and PVX yet. That is another experiment I can/will try at some point.

Please let me know if you need any more information, or want me to carry out
any specific tests. I am hoping to carry out some more tests the next chance
I get, and I will update you when I have more information to share.

Thanks!

-Alan


#2

Hi Alan,

Thank you for the feedback!

- The SC media configuration window seemed to be unstable. The preferred
order for the codecs seemed to be randomly shuffled every time a change to
the enabled codecs was made and the client was restarted, and this didn't
give me, as a user, a high degree of confidence that my preferences were
actually being stored properly or honored. I believe this is a known issue?

I haven't noticed so much as random shuffling but rather that disabled
codecs move at the bottom of the list bellow the enabled codecs. I
think it's inherent of our way of storing the codec preferences
because we remember the codec and its priority with a special priority
value for disabled codecs i.e. we don't have separate fields for
priorty and enabled state so disabled codecs are with the lowest
priority and when sorted according to the priority in the Media
configuration form, move after the enabled codecs.

Anyway, we could certainly improve here so if we don't already have it
in our issue tracker, could you please create a new issue for it so
that we can prioritize and schedule it accordingly?

Regards,
Lubomir

···

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


#3

Hi Lubomir,

Hi Alan,

Thank you for the feedback!

You're welcome :slight_smile:

> - The SC media configuration window seemed to be unstable. The preferred
> order for the codecs seemed to be randomly shuffled every time a change
to
> the enabled codecs was made and the client was restarted, and this didn't
> give me, as a user, a high degree of confidence that my preferences were
> actually being stored properly or honored. I believe this is a known
issue?

I haven't noticed so much as random shuffling but rather that disabled
codecs move at the bottom of the list bellow the enabled codecs. I
think it's inherent of our way of storing the codec preferences
because we remember the codec and its priority with a special priority
value for disabled codecs i.e. we don't have separate fields for
priorty and enabled state so disabled codecs are with the lowest
priority and when sorted according to the priority in the Media
configuration form, move after the enabled codecs.

Ah, that's right, I investigated the priority field a few weeks ago before I
left town, but I didn't write that part down so I forgot about that part
when I got back. There definitely seemed to be some confusion arising from
the same variable being used for priority and for enabling/disabling of the
form. I just had another look at the media config window (in r5840 from the
1.0 branch).

Observations:
- The codecs retain their proper, user-selected order when all are enabled.
- If you disable a codec, it is dropped to the end of the list the next time
the client is started.
- If you disable all but one codec, the disabled codecs re-order themselves
into the order in which they were disabled the next time the client is
started (yielding the impression that they shuffled randomly).
- If you then disable the remaining codec, and enable another codec, the
list seems to scramble itself.

It might be preferable to a) have the en/disabled status stored as a
separate variable from the priority and/or b) have the codecs drop in the
list immediately, instead of on restart. Or then again, maybe I'm being a
perfectionist :slight_smile:

Anyway, we could certainly improve here so if we don't already have it

in our issue tracker, could you please create a new issue for it so
that we can prioritize and schedule it accordingly?

Will do. I thought I saw an issue for this previously but I can't find it
now.

Also, while looking through the issue tracker, I noticed the following issue
(695) in regards to the media configuration form, and I couldn't help
wondering if it doesn't explain part of the audio problem I was
experiencing. Apparently, changing the codec preferences is leading to
invalid SDPs being sent until you re-start the client. I will investigate
this early next week if time permits.

https://sip-communicator.dev.java.net/issues/show_bug.cgi?id=695

-Alan

···

On Thu, Aug 20, 2009 at 4:20 PM, Lubomir Marinov <lubomir.marinov@gmail.com>wrote:


#4

Opened as Issue #716.

···

On Thu, Aug 20, 2009 at 5:39 PM, Alan Kelly <akoriolesfan@gmail.com> wrote:

Hi Lubomir,

On Thu, Aug 20, 2009 at 4:20 PM, Lubomir Marinov < > lubomir.marinov@gmail.com> wrote:

Hi Alan,

Thank you for the feedback!

You're welcome :slight_smile:

> - The SC media configuration window seemed to be unstable. The
preferred
> order for the codecs seemed to be randomly shuffled every time a change
to
> the enabled codecs was made and the client was restarted, and this
didn't
> give me, as a user, a high degree of confidence that my preferences were
> actually being stored properly or honored. I believe this is a known
issue?

I haven't noticed so much as random shuffling but rather that disabled
codecs move at the bottom of the list bellow the enabled codecs. I
think it's inherent of our way of storing the codec preferences
because we remember the codec and its priority with a special priority
value for disabled codecs i.e. we don't have separate fields for
priorty and enabled state so disabled codecs are with the lowest
priority and when sorted according to the priority in the Media
configuration form, move after the enabled codecs.

Ah, that's right, I investigated the priority field a few weeks ago before
I left town, but I didn't write that part down so I forgot about that part
when I got back. There definitely seemed to be some confusion arising from
the same variable being used for priority and for enabling/disabling of the
form. I just had another look at the media config window (in r5840 from the
1.0 branch).

Observations:
- The codecs retain their proper, user-selected order when all are enabled.
- If you disable a codec, it is dropped to the end of the list the next
time the client is started.
- If you disable all but one codec, the disabled codecs re-order themselves
into the order in which they were disabled the next time the client is
started (yielding the impression that they shuffled randomly).
- If you then disable the remaining codec, and enable another codec, the
list seems to scramble itself.

It might be preferable to a) have the en/disabled status stored as a
separate variable from the priority and/or b) have the codecs drop in the
list immediately, instead of on restart. Or then again, maybe I'm being a
perfectionist :slight_smile:

Anyway, we could certainly improve here so if we don't already have it

in our issue tracker, could you please create a new issue for it so
that we can prioritize and schedule it accordingly?

Will do. I thought I saw an issue for this previously but I can't find it
now.

Also, while looking through the issue tracker, I noticed the following
issue (695) in regards to the media configuration form, and I couldn't help
wondering if it doesn't explain part of the audio problem I was
experiencing. Apparently, changing the codec preferences is leading to
invalid SDPs being sent until you re-start the client. I will investigate
this early next week if time permits.

https://sip-communicator.dev.java.net/issues/show_bug.cgi?id=695

-Alan


#5

Hi Lubomir,

Are there any specific tests you would like me to try in order to debug
what's going on here? I'm not too familiar with dealing with codec problems.

Thanks.

-Alan

···

On Fri, Aug 21, 2009 at 1:03 PM, Alan Kelly <akoriolesfan@gmail.com> wrote:

Opened as Issue #716.

On Thu, Aug 20, 2009 at 5:39 PM, Alan Kelly <akoriolesfan@gmail.com>wrote:

Hi Lubomir,

On Thu, Aug 20, 2009 at 4:20 PM, Lubomir Marinov < >> lubomir.marinov@gmail.com> wrote:

Hi Alan,

Thank you for the feedback!

You're welcome :slight_smile:

> - The SC media configuration window seemed to be unstable. The
preferred
> order for the codecs seemed to be randomly shuffled every time a change
to
> the enabled codecs was made and the client was restarted, and this
didn't
> give me, as a user, a high degree of confidence that my preferences
were
> actually being stored properly or honored. I believe this is a known
issue?

I haven't noticed so much as random shuffling but rather that disabled
codecs move at the bottom of the list bellow the enabled codecs. I
think it's inherent of our way of storing the codec preferences
because we remember the codec and its priority with a special priority
value for disabled codecs i.e. we don't have separate fields for
priorty and enabled state so disabled codecs are with the lowest
priority and when sorted according to the priority in the Media
configuration form, move after the enabled codecs.

Ah, that's right, I investigated the priority field a few weeks ago before
I left town, but I didn't write that part down so I forgot about that part
when I got back. There definitely seemed to be some confusion arising from
the same variable being used for priority and for enabling/disabling of the
form. I just had another look at the media config window (in r5840 from the
1.0 branch).

Observations:
- The codecs retain their proper, user-selected order when all are
enabled.
- If you disable a codec, it is dropped to the end of the list the next
time the client is started.
- If you disable all but one codec, the disabled codecs re-order
themselves into the order in which they were disabled the next time the
client is started (yielding the impression that they shuffled randomly).
- If you then disable the remaining codec, and enable another codec, the
list seems to scramble itself.

It might be preferable to a) have the en/disabled status stored as a
separate variable from the priority and/or b) have the codecs drop in the
list immediately, instead of on restart. Or then again, maybe I'm being a
perfectionist :slight_smile:

Anyway, we could certainly improve here so if we don't already have it

in our issue tracker, could you please create a new issue for it so
that we can prioritize and schedule it accordingly?

Will do. I thought I saw an issue for this previously but I can't find it
now.

Also, while looking through the issue tracker, I noticed the following
issue (695) in regards to the media configuration form, and I couldn't help
wondering if it doesn't explain part of the audio problem I was
experiencing. Apparently, changing the codec preferences is leading to
invalid SDPs being sent until you re-start the client. I will investigate
this early next week if time permits.

https://sip-communicator.dev.java.net/issues/show_bug.cgi?id=695

-Alan


#6

Hi Alan,

Thank you for opening issue #716! I still haven't talked to anyone about its priority but I think it's a good task for new contributors because it's relatively simple in the sense that it doesn't require detailed knowledge of our media service architecture, JMF, etc. and it's mostly about Swing and general data structures. Anyway, it may have to wait a bit for the media service redesign to be finished.

As to the other problems that you described, I'm afraid me being on the "our codec experts" list may be considered an exaggeration :wink:

> I don't know enough about ilbc to know what this means, but SC is using
> codec #97, while XL is using #98 and #101. XL responds to this conflict
> by offering it's default codec of u-law. In contrast, SC simply abandons
> the call (actually, SC sent an SDP offering only the video codecs).

It may be wildly unrelated but it reminds me of the dynamic payload types and their negotiation in SDP which we do not currently support in SIP Communicator. Our Google Summer of Code 2009 project "DTMF with RTP" brought up the subject in private conversations and I was left with the impression that it is understood as necessary and is in the task queue being preceded because of higher priorities including the media service redesign.

Best regards,
Lubomir

Alan Kelly написа:

···

Hi Lubomir,

Are there any specific tests you would like me to try in order to debug what's going on here? I'm not too familiar with dealing with codec problems.

Thanks.

-Alan

On Fri, Aug 21, 2009 at 1:03 PM, Alan Kelly <akoriolesfan@gmail.com > <mailto:akoriolesfan@gmail.com>> wrote:

    Opened as Issue #716.

    On Thu, Aug 20, 2009 at 5:39 PM, Alan Kelly <akoriolesfan@gmail.com > <mailto:akoriolesfan@gmail.com>> wrote:

        Hi Lubomir,

        On Thu, Aug 20, 2009 at 4:20 PM, Lubomir Marinov > <lubomir.marinov@gmail.com <mailto:lubomir.marinov@gmail.com>> > wrote:

            Hi Alan,

            Thank you for the feedback!

        You're welcome :slight_smile:
         
             > - The SC media configuration window seemed to be
            unstable. The preferred
             > order for the codecs seemed to be randomly shuffled every
            time a change to
             > the enabled codecs was made and the client was restarted,
            and this didn't
             > give me, as a user, a high degree of confidence that my
            preferences were
             > actually being stored properly or honored. I believe this
            is a known issue?

            I haven't noticed so much as random shuffling but rather
            that disabled
            codecs move at the bottom of the list bellow the enabled
            codecs. I
            think it's inherent of our way of storing the codec preferences
            because we remember the codec and its priority with a
            special priority
            value for disabled codecs i.e. we don't have separate fields for
            priorty and enabled state so disabled codecs are with the lowest
            priority and when sorted according to the priority in the Media
            configuration form, move after the enabled codecs.

        Ah, that's right, I investigated the priority field a few weeks
        ago before I left town, but I didn't write that part down so I
        forgot about that part when I got back. There definitely seemed
        to be some confusion arising from the same variable being used
        for priority and for enabling/disabling of the form. I just had
        another look at the media config window (in r5840 from the 1.0
        branch).

        Observations:
        - The codecs retain their proper, user-selected order when all
        are enabled.
        - If you disable a codec, it is dropped to the end of the list
        the next time the client is started.
        - If you disable all but one codec, the disabled codecs re-order
        themselves into the order in which they were disabled the next
        time the client is started (yielding the impression that they
        shuffled randomly).
        - If you then disable the remaining codec, and enable another
        codec, the list seems to scramble itself.

        It might be preferable to a) have the en/disabled status stored
        as a separate variable from the priority and/or b) have the
        codecs drop in the list immediately, instead of on restart. Or
        then again, maybe I'm being a perfectionist :slight_smile:

            Anyway, we could certainly improve here so if we don't
            already have it
            in our issue tracker, could you please create a new issue
            for it so
            that we can prioritize and schedule it accordingly?

        Will do. I thought I saw an issue for this previously but I
        can't find it now.

        Also, while looking through the issue tracker, I noticed the
        following issue (695) in regards to the media configuration
        form, and I couldn't help wondering if it doesn't explain part
        of the audio problem I was experiencing. Apparently, changing
        the codec preferences is leading to invalid SDPs being sent
        until you re-start the client. I will investigate this early
        next week if time permits.

        https://sip-communicator.dev.java.net/issues/show_bug.cgi?id=695

        -Alan

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