[jitsi-users] audio stuttering


#1

Hi all again,

after following the advice of using a registrar, I applied
for an account and I'm now able to start a call.

Unfortunately there are some issues:

1) audio is stuttering a lot, it seems, I estimate, only
around 5%-10% of the RTP packets arrive. So it is unusable.

2) chat, especially when audio is running, reports a lot
of "error 408 timeout".

3) video and desktop sharing is out of question, meaning
it does not work at all.

Now, does this situation somehow belong to known problems
or, otherwise, how could it be possible to debug it?

Thanks a lot in advance,

bye,

···

--

piergiorgio


#2

На 10/4/2011 9:13 PM, Piergiorgio Sartor написа:

1) audio is stuttering a lot, it seems, I estimate, only
around 5%-10% of the RTP packets arrive. So it is unusable.

We'll need Wireshark dumps in order to confirm that lost RTP packets are causing the stutter. You'd better start by sending us the Jitsi logs as described at http://jitsi.org/index.php/Documentation/FAQ#logs.

2) chat, especially when audio is running, reports a lot
of "error 408 timeout".

Which registrar are we talking about? I suggest you do send us the Jitsi logs so that we can gather and examine the details, try to reproduce the issue, etc.

3) video and desktop sharing is out of question, meaning
it does not work at all.

If the audio is stuttering because a lot of the RTP packets are lost, it'd seem reasonable to expect that the RTP packet loss will break the video (which includes desktop sharing). Let's focus on the audio at first.


#3

Hi,

one thing I forgot...

The ZRTP authentication does not happen at all.

The connection is, consequently, not encrypted.

На 10/4/2011 9:13 PM, Piergiorgio Sartor написа:
>1) audio is stuttering a lot, it seems, I estimate, only
>around 5%-10% of the RTP packets arrive. So it is unusable.

We'll need Wireshark dumps in order to confirm that lost RTP packets

I noticed wireshark can capture SIP/RTP traffic, I can have a
look to that too.

are causing the stutter. You'd better start by sending us the Jitsi
logs as described at
http://jitsi.org/index.php/Documentation/FAQ#logs.

OK, I'll try to collect clean data.

···

On Tue, Oct 04, 2011 at 10:52:54PM +0300, Lyubomir Marinov wrote:

>2) chat, especially when audio is running, reports a lot
>of "error 408 timeout".

Which registrar are we talking about? I suggest you do send us the
Jitsi logs so that we can gather and examine the details, try to
reproduce the issue, etc.

>3) video and desktop sharing is out of question, meaning
>it does not work at all.

If the audio is stuttering because a lot of the RTP packets are
lost, it'd seem reasonable to expect that the RTP packet loss will
break the video (which includes desktop sharing). Let's focus on the
audio at first.

--

piergiorgio


#4

Hi again,

so, in the end, we figured out that the network
connection, on the other side, was really s**t.

After changing the connection, the call were
working quite OK, audio and video.

Thanks anyway Lyubomir, I appreciated a lot the
quick response,

bye,

pg

···

On Tue, Oct 04, 2011 at 10:52:54PM +0300, Lyubomir Marinov wrote:

На 10/4/2011 9:13 PM, Piergiorgio Sartor написа:
>1) audio is stuttering a lot, it seems, I estimate, only
>around 5%-10% of the RTP packets arrive. So it is unusable.

We'll need Wireshark dumps in order to confirm that lost RTP packets
are causing the stutter. You'd better start by sending us the Jitsi
logs as described at
http://jitsi.org/index.php/Documentation/FAQ#logs.

>2) chat, especially when audio is running, reports a lot
>of "error 408 timeout".

Which registrar are we talking about? I suggest you do send us the
Jitsi logs so that we can gather and examine the details, try to
reproduce the issue, etc.

>3) video and desktop sharing is out of question, meaning
>it does not work at all.

If the audio is stuttering because a lot of the RTP packets are
lost, it'd seem reasonable to expect that the RTP packet loss will
break the video (which includes desktop sharing). Let's focus on the
audio at first.

--

piergiorgio


#5

wireshark shows that jitsi is using this kind of url when it tries to
get my oma_status-icon from xcap server:

GET /xcap-root/oma_status-icon/users/sip:jh@test.fi/sip_communicator

there is no such auid as oma_status-icon. according to
OMA-TS-Presence-SIMPLE_Content_XDM-V1_0-20081223-C auid
org.openmobilealliance.pres-content is used and the above GET should be
like this:

GET /xcap-root/org.openmobilealliance.pres-content/users/sip:jh@test.fi/oma_status-icon/icon_document

could you please fix the url that jitsi is using.

-- juha


#6

Hi,

I'm not sure whether we should change just the icon request URL or we have
to implement all OMA spec. Even if we change just the request URL people
that have used the old method will lose their icons, isn't that true?
Maybe we should put an option in account configuration when enabling xcap to
choose OMA or non-OMA documents specification to be used.
WDYT?
You can file a feature request for implementing OMA specs into Jitsi.

Regards
damencho

···

On Wed, Oct 5, 2011 at 9:27 AM, Juha Heinanen <jh@tutpro.com> wrote:

wireshark shows that jitsi is using this kind of url when it tries to
get my oma_status-icon from xcap server:

GET /xcap-root/oma_status-icon/users/sip:jh@test.fi/sip_communicator

there is no such auid as oma_status-icon. according to
OMA-TS-Presence-SIMPLE_Content_XDM-V1_0-20081223-C auid
org.openmobilealliance.pres-content is used and the above GET should be
like this:

GET /xcap-root/org.openmobilealliance.pres-content/users/
sip:jh@test.fi/oma_status-icon/icon_document

could you please fix the url that jitsi is using.

-- juha


#7

i have jitsi user jh@test.fi and it has one contact test@test.fi. when
i start jitsi 2.2, jh@test.fi sends subscribe to test@test.fi and gets back
notify where status of the contact is open. still the dot next to the
contact remains gray. i would expect it to turn green.

is this a bug or something else? could it be that jitsi gets confused
because of the escaped chars in body of notify?

pcap from jitsi log is below.

-- juha

No. Time Source Destination Protocol Length Info
      8 08:02:40.201000 192.98.102.10 192.98.102.10 SIP 791 Request: SUBSCRIBE sip:test@test.fi

Frame 8: 791 bytes on wire (6328 bits), 791 bytes captured (6328 bits)
Ethernet II, Src: 00:00:00_00:00:00 (00:00:00:00:00:00), Dst: 00:00:00_00:00:00 (00:00:00:00:00:00)
Internet Protocol Version 4, Src: 192.98.102.10 (192.98.102.10), Dst: 192.98.102.10 (192.98.102.10)
Transmission Control Protocol, Src Port: 39018 (39018), Dst Port: sip (5060), Seq: 1714, Ack: 1122, Len: 725
Session Initiation Protocol
    Request-Line: SUBSCRIBE sip:test@test.fi SIP/2.0
    Message Header
        Call-ID: da6beb0852c9112179b8327724cdfddc@0:0:0:0:0:0:0:0
        CSeq: 2 SUBSCRIBE
        Max-Forwards: 70
        Contact: "Juha" <sip:jh@192.98.102.10:39018;transport=tcp;registering_acc=test_fi>
        User-Agent: Jitsi2.2.4603.9615Linux
        Event: presence
        Accept: application/pidf+xml
        Expires: 240
        Via: SIP/2.0/TCP 192.98.102.10:39018;branch=z9hG4bK-383236-a73327234ae68a861be2f9d50d79be00
        Content-Length: 0

No. Time Source Destination Protocol Length Info
     12 08:02:40.269000 192.98.102.10 192.98.102.10 SIP 614 Status: 202 OK

Frame 12: 614 bytes on wire (4912 bits), 614 bytes captured (4912 bits)
Ethernet II, Src: 00:00:00_00:00:00 (00:00:00:00:00:00), Dst: 00:00:00_00:00:00 (00:00:00:00:00:00)
Internet Protocol Version 4, Src: 192.98.102.10 (192.98.102.10), Dst: 192.98.102.10 (192.98.102.10)
Transmission Control Protocol, Src Port: sip (5060), Dst Port: 39018 (39018), Seq: 1651, Ack: 4204, Len: 548
Session Initiation Protocol
    Status-Line: SIP/2.0 202 OK
    Message Header
        Record-Route: <sip:192.98.102.10:5070;transport=tcp;r2=on;lr>,<sip:192.98.102.10;transport=tcp;r2=on;lr>
        Call-ID: da6beb0852c9112179b8327724cdfddc@0:0:0:0:0:0:0:0
        CSeq: 2 SUBSCRIBE
        Via: SIP/2.0/TCP 192.98.102.10:39018;branch=z9hG4bK-383236-a73327234ae68a861be2f9d50d79be00
        Expires: 240
        Contact: <sip:192.98.102.10:5080;transport=tcp>
        Server: OpenXg Presence/XCAP Server (4.0.1 (x86_64/linux))
        Content-Length: 0

No. Time Source Destination Protocol Length Info
     13 08:02:40.315000 192.98.102.10 192.98.102.10 SIP/XML 2017 Request: NOTIFY sip:jh@192.98.102.10:39018;transport=tcp;registering_acc=test_fi

Frame 13: 2017 bytes on wire (16136 bits), 2017 bytes captured (16136 bits)
Ethernet II, Src: 00:00:00_00:00:00 (00:00:00:00:00:00), Dst: 00:00:00_00:00:00 (00:00:00:00:00:00)
Internet Protocol Version 4, Src: 192.98.102.10 (192.98.102.10), Dst: 192.98.102.10 (192.98.102.10)
Transmission Control Protocol, Src Port: sip (5060), Dst Port: 39018 (39018), Seq: 2199, Ack: 4204, Len: 1951
Session Initiation Protocol
    Request-Line: NOTIFY sip:jh@192.98.102.10:39018;transport=tcp;registering_acc=test_fi SIP/2.0
    Message Header
        Record-Route: <sip:192.98.102.10;transport=tcp;r2=on;lr>,<sip:192.98.102.10:5070;transport=tcp;r2=on;lr>
        Via: SIP/2.0/TCP 192.98.102.10;branch=z9hG4bKad5.167788a615c1bffa565b0e11eb00900a.0;i=d5;rport=5060,SIP/2.0/TCP 192.98.102.10:5080;branch=z9hG4bKad5.5338e971000000000000000000000000.0
        CSeq: 2 NOTIFY
        Call-ID: da6beb0852c9112179b8327724cdfddc@0:0:0:0:0:0:0:0
        User-Agent: OpenXg Presence/XCAP Server (4.0.1 (x86_64/linux))
        Max-Forwards: 16
        Event: presence
        Contact: <sip:192.98.102.10:5080;alias=192.98.102.10~33266~2;transport=tcp>
        Subscription-State: active;expires=240
        Content-Type: application/pidf+xml
        Content-Length: 1124
    Message Body
        eXtensible Markup Language
            <?xml
            <presence
                xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid"
                xmlns:agp-pidf="urn:ag-projects:xml:ns:pidf"
                xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
                xmlns="urn:ietf:params:xml:ns:pidf"
                entity="test%40test.fi">
                <tuple
                    id="ID-2e4eae00-c2c7-4136-a74e-2336177a0ae0">
                    <status>
                        <basic>
                            open
                            </basic>
                        <agp-pidf:extended>
                            available
                            </agp-pidf:extended>
                        </status>
                    <agp-pidf:device-info
                        id="urn:uuid:2e4eae00-c2c7-4136-a74e-2336177a0ae0"/>
                    <contact
                        priority="0.0">
                        sip%3Atest%40test.fi%3Bgr%3Durn%3Auuid%3A2e4eae00-c2c7-4136-a74e-2336177a0ae0
                        </contact>
                    <timestamp>
                        2013-05-05T07:59:03.315638+03:00
                        </timestamp>
                    </tuple>
                <dm:person
                    id="ID-bef633c87f520ffed3bc0bd6ef1675fa">
                    <rpid:time-offset>
                        180
                        </rpid:time-offset>
                    <dm:timestamp>
                        2013-05-05T07:58:32.893489+03:00
                        </dm:timestamp>
                    </dm:person>
                <dm:device
                    id="sqqypdkp">
                    <dm:deviceID>
                        urn:uuid:2e4eae00-c2c7-4136-a74e-2336177a0ae0
                        </dm:deviceID>
                    <dm:note
                        xml:lang="en">
                        Powered by sipsimple 0.34.0
                        </dm:note>
                    <dm:timestamp>
                        2013-05-05T07:58:32.895225+03:00
                        </dm:timestamp>
                    </dm:device>
                </presence>

No. Time Source Destination Protocol Length Info
     14 08:02:40.358000 192.98.102.10 192.98.102.10 SIP 587 Status: 200 OK

Frame 14: 587 bytes on wire (4696 bits), 587 bytes captured (4696 bits)
Ethernet II, Src: 00:00:00_00:00:00 (00:00:00:00:00:00), Dst: 00:00:00_00:00:00 (00:00:00:00:00:00)
Internet Protocol Version 4, Src: 192.98.102.10 (192.98.102.10), Dst: 192.98.102.10 (192.98.102.10)
Transmission Control Protocol, Src Port: 39018 (39018), Dst Port: sip (5060), Seq: 4204, Ack: 4150, Len: 521
Session Initiation Protocol
    Status-Line: SIP/2.0 200 OK
    Message Header
        Via: SIP/2.0/TCP 192.98.102.10;branch=z9hG4bKad5.167788a615c1bffa565b0e11eb00900a.0;i=d5;rport=5060,SIP/2.0/TCP 192.98.102.10:5080;branch=z9hG4bKad5.5338e971000000000000000000000000.0
        CSeq: 2 NOTIFY
        Call-ID: da6beb0852c9112179b8327724cdfddc@0:0:0:0:0:0:0:0
        Contact: "Juha" <sip:jh@192.98.102.10:39018;transport=tcp;registering_acc=test_fi>
        User-Agent: Jitsi2.2.4603.9615Linux
        Content-Length: 0

···

From: "Juha" <sip:jh@test.fi>;tag=8c087ea4
        To: <sip:test@test.fi>
        From: "Juha" <sip:jh@test.fi>;tag=8c087ea4
        To: <sip:test@test.fi>;tag=2c15998813993a5f2698a8693042e46f-0069
        To: <sip:jh@test.fi>;tag=8c087ea4
        From: <sip:test@test.fi>;tag=2c15998813993a5f2698a8693042e46f-0069
        To: <sip:jh@test.fi>;tag=8c087ea4
        From: <sip:test@test.fi>;tag=2c15998813993a5f2698a8693042e46f-0069


#8

Damian Minkov writes:

I'm not sure whether we should change just the icon request URL or we have
to implement all OMA spec. Even if we change just the request URL people
that have used the old method will lose their icons, isn't that true?

yes.

Maybe we should put an option in account configuration when enabling xcap to
choose OMA or non-OMA documents specification to be used.

that would be a good backwards compatible solution.

You can file a feature request for implementing OMA specs into Jitsi.

i can do that although whole oma might be a big task. sip router xcap
server currently implements these two oma auid's:

urn:oma:xml:xdm:user-profile
urn:oma:xml:prs:pres-content

-- juha


#9

Juha Heinanen writes:

is this a bug or something else? could it be that jitsi gets confused
because of the escaped chars in body of notify?

perhaps jitsi didn't understand which presentity the notify was for,
because it has wrongly formatted entity uri:

    Request-Line: NOTIFY sip:jh@192.98.102.10:39018;transport=tcp;registering_acc=test_fi SIP/2.0

      ...

    Message Body
        eXtensible Markup Language
            <?xml
            <presence
                xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid"
                xmlns:agp-pidf="urn:ag-projects:xml:ns:pidf"
                xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
                xmlns="urn:ietf:params:xml:ns:pidf"
                entity="test%40test.fi">

uri scheme 'pres:' is missing from it. if that is the case, then jitsi
should have replied something else than 200 ok.

-- juha