[sip-comm-dev] How to affect the DELAY, PACKET LOSS and JITTER in SC


#1

Hello all,

I work on a project of the Hanover technical
college in which the SIP Communicator is used as a user agent for

a connection<A[connection|combination]> with
an asterisk server. In this case must be examined the quality parameters and
also tried to build

up a Unidirectional Connection<A[Connection|Combination]> (simplex).

My questions:

1. It is possibly to affect the
parameters packet loss, delay and jitter in SIP Communicator?

2. It is possible to set up a
unidirectional connection (simplex)?

I hope somebody has experience with
these topics and can help me.
Best Regards

Nikolay Velichkov


#2

Hello Nikolay,

Nikolay Velichkov wrote:

1. It is possibly to affect the parameters packet loss, delay and jitter
in SIP Communicator?

Not sure I understand. What do you mean by affect, and what do you mean
by possible? Do you mean introducing packet loss or rather handling it?
Same question for delay and jitter.

2. It is possible to set up a unidirectional connection (simplex)?

Again, not sure I understand what you mean by unidirectional connection.
Is it a connection where audio is streamed in one direction only? If yes
then which direction would that be? If you want to connect to a service
where you will only be sending data and won't be receiving anything then
that would work. If you want it to be the other way around then the
service would have to send an SDP description that declares all streams
as sendonly.

Hope this helps. Let me know if I misunderstood anything.

Cheers
Emil

···

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


#3

Hello Emil, hello all,

first: delay und packet loss

Not sure I understand. What do you mean by affect, and what do you mean
by possible? Do you mean introducing packet loss or rather handling it?
Same question for delay and jitter.

I mean introducing and than handling it. First I will try only whit delay and packet loss. I thing Jitter is something complex for me.

I would like to produce an larger delay by introducing changes in the source code of SC. That means for example - the voice packets will be transmitted after 50, 100,500 ms or more from SC, not immediately. I would like examining how the delay exactly affects the quality. I mean the same with packet loss. I would like to modify the source code so, that every 3, 5, 10, 15 data packet will be not send.

second: uni direction

Is it a connection where audio is streamed in one direction only?

exactly

If yes then which direction would that be?

user A-->B and from user B-->A, and not like duplex A<=>B

If you want it to be the other way around then the
service would have to send at SDP description that declares all streams
as sendonly.

at which place in the source code am I supposed to declares sendonly from SDP

Thank You for the help

and Cheers

Nikolay

···

________________________________
Von: Emil Ivov <emcho@sip-communicator.org>
An: dev@sip-communicator.dev.java.net
Gesendet: Mittwoch, den 1. Juli 2009, 17:49:15 Uhr
Betreff: Re: [sip-comm-dev] How to affect the DELAY, PACKET LOSS and JITTER in SC

Hello Nikolay,

Nikolay Velichkov wrote:

1. It is possibly to affect the parameters packet loss, delay and jitter
in SIP Communicator?

Not sure I understand. What do you mean by affect, and what do you mean
by possible? Do you mean introducing packet loss or rather handling it?
Same question for delay and jitter.

2. It is possible to set up a unidirectional connection (simplex)?

Again, not sure I understand what you mean by unidirectional connection.
Is it a connection where audio is streamed in one direction only? If yes
then which direction would that be? If you want to connect to a service
where you will only be sending data and won't be receiving anything then
that would work. If you want it to be the other way around then the
service would have to send an SDP description that declares all streams
as sendonly.

Hope this helps. Let me know if I misunderstood anything.

Cheers
Emil

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


#4

Nikolay Velichkov wrote:

I would like to produce an larger delay by introducing changes in the
source code of SC. That means for example - the voice packets will be
transmitted after 50, 100,500 ms or more from SC, not immediately. I
would like examining how the delay exactly affects the quality. I mean
the same with packet loss. I would like to modify the source code so,
that every 3, 5, 10, 15 data packet will be not send.

You can do that with an RTP connector that would intercept all packets
before sending them. Our SRTP/ZRTP implementations do that so you can
have a look at their code for inspiration. Try starting here:

net.java.sip.communicator.impl.media.transform.TransformConnector

In your case you won't actually be modifying them but you could still
use the connector to delay and drop individual packets.

user A-->B and from user B-->A, and not like duplex A<=>B

Sounds complicated. It is fairly simple to start a session where you
know that only A would be streaming data. You simply need to declare
your stream as sendonly (this is currently done bye the methods that
create SDP in net.java.sip.communicator.impl.media.CallSessionImpl).

From a signaling perspective this is exactly the same as putting a call

on hold. The only difference is that you want be putting your local
streams on pause.

However, if you still want both parties to be able to transmit, only not
in the same time, then this is a completely different scenario. How you
implement this would depend on why exactly you want to do it and what
your actual constraints are. The easiest thing that comes to mind would
be to have a mechanism that operates like "push to talk". Every time one
of the parties wants to transmit it could send an invite that puts the
other one on hold. The invite can be triggered by the user (that's the
case that really looks like push to talk) or by some kind of sound
activity detection. You may also want to implement a way for the remote
party to reject such a request in order to avoid collisions.

Hope this helps!
Emil

···

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