RTP Silence Suppression

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Nanang

So of course the Conference bridge allows two streams, one ingoing and one
outgoing:

A ----in--------> B
   <---out------

What I mean by removing A from B's conference bridge is to end both streams

status = pjsua_conf_disconnect(info.slot_id,0);
status = pjsua_conf_disconnect(0,info.slot_id);

On the RTP Level, i thought that this corresponds to a "manual" silence
supression, both clients set the "s" bit in the rtp packets.
Or how are those RTP Streams still maintained, since  with every SIP Call a
RTP stream is generated.

So as you said this obviously should save me some bandwidth. My question
also is where can I see those packets exchanged between those two clients,
which loglevel should i use, or is there any other way like wireshark to
caputre those packets? or maybe is the "dq function of pjsua already enough
to measure this somehow?

Cheers
Thomas


2008/4/22 Nanang Izzuddin <nanang at pjsip.org>:

> Hi Thomas,
>
> "Removing A from the B's conference bridge" is a bit ambiguous
> sentence though :)
> Assumed in the B side, the conference bridge only has 2 ports (sound
> port is port 0 and stream port is port 1) then issuing command:
> - "cd 0 1" will make B stop sending RTP to A (this will save traffic,
> but NAT session may be gone)
> - "cd 1 0" will not save traffic.
> These scenarios don't seem to involve silence suppression.
>
> You can test the silence suppression by not talking or muting mic (to
> make it safe from keyboard stroke sound :D), then you can check the
> traffic by using command 'dq' periodically in pjsua. Please make sure
> the VAD is enabled (just don't put --no-vad in the pjsua's param).
>
>
> Regards,
> nanang
>
>
> On 22/04/2008, Thomas Plotkowiak <plotti at gmx.net> wrote:
> > Scenario with Psjua:
> >
> > A initiates SIP call with B.
> >
> > B adds A to the conference bridge.
> > B is able to hear A.
> > --> In RTP protocoll audio is transmitted from A to B.
> >
> > What if i now remove A from the conference bridge and still have the
> call.
> >  Does this lead to silence supresssion on B or A side? Do I save traffic
> by
> > doing this?
> >
> > How could I prove that I am saving traffic with this? Can I see it
> somewhere
> > happening in the logs?
> >
> > Any comments or info about this topic would be appreciated.
> >
> >
> > Cheers
> > Thomas
> >
> >
> > RFC3389 on Silence Suppression: RTP allows discontinuous transmission
> > (silence suppression) on any audio payload format. The receiver can
> detect
> > silence suppression on the first packet received after the silence by
> > observing that the RTP timestamp is not contiguous with the end of the
> > interval covered by the previous packet even though the RTP sequence
> number
> > has incremented only by one. The RTP marker bit is also normally set on
> such
> > a packet.
> > _______________________________________________
> >  Visit our blog: http://blog.pjsip.org
> >
> >  pjsip mailing list
> >  pjsip at lists.pjsip.org
> > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
> >
> >
>
> _______________________________________________
> Visit our blog: http://blog.pjsip.org
>
> pjsip mailing list
> pjsip at lists.pjsip.org
> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20080423/9bec87a1/attachment-0001.html 


[Index of Archives]     [Asterisk Users]     [Asterisk App Development]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [Linux API]
  Powered by Linux