Bugfix: hold/reinvite can reset the RTP sequence number

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

 



PJSUA-LIB takes pains to preserve the RTP transmit sequence number for a
given call, across multiple sessions. However, a specific scenario
breaks its attempts:

   1. Peer A calls peer B
   2. Peer B answers; peer B creates a new media session with a
      bidirectional stream
   3. Peer A puts call on hold; peer B creates a new media session with
      a receive-only stream
   4. Peer A reinvites peer B; peer B creates a new media session with a
      bidirectional stream

Between steps 3 and 4, B forgets the transmit sequence number. This is
because the initial sequence number is stored in the encoder channel of
stream #0 when the session is created, but before the session is
destroyed, the current sequence number is read from the RTCP statistics
of stream #0. A receive-only stream never updates the RTCP transmit
statistics, so the sequence number is initialized to zero at step 3 when
the session is created, and never updated between steps 3 and 4. When
peer B retrieves the sequence number to set in the new session, it
retrieves zero, and mistakenly restarts the sequence.
My patch fixes the issue by initializing RTCP transmit statistics to
meaningful values
-- 
 
KHAMSA SA

Michele Cicciotti
Research & Development

Mobile:   + 39 339 3206609
E-mail:    m.cicciotti at khamsalabs.net <mailto:m.cicciotti at khamsalabs.net>

KHAMSA SA
Via Giacometti 1 - 6900 Lugano - Switzerland
Web:   www.khamsa.net <http://www.khamsa.net>

Technical Support CH:  + 41 (0)91 2206457
Technical Support IT:   + 39 02 911930891
E-mail:  support at khamsa.ch <mailto:support at khamsa.ch>

Monday to Friday 10.00 - 12.00 and 14.00 - 16.00

..........................................................................................................................................................................................


This e-mail (including attachments) is intended only for the
recipient(s) named above. It may contain confidential or privileged
information and should not be read, copied or otherwise used by any
other person.
If you are not the named recipient, please contact us immediately and
delete the e-mail from your system.

Le informazioni contenute in questo messaggio sono riservate e
confidenziali ed ? vietata la diffusione in qualunque modo
eseguita. Qualora Lei non fosse la persona a cui il presente messaggio ?
destinato, La invitiamo ad eliminarlo e a non leggerlo,
dandocene gentilmente comunicazione.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20090922/49553eb5/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: khamsa.png
Type: image/png
Size: 2534 bytes
Desc: not available
URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20090922/49553eb5/attachment.png>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: hold-reinvite.patch
URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20090922/49553eb5/attachment.patch>


[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