Hi Michele, Just FYI, there was a different fix (in pjsua-lib level) for similar problem in r2996[1]. The patch attached will also fix the problem, however I think the problem was in pjsua, also perhaps better to leave the stream transmit statistics as is (let the zero/initial values there, as the session actually never transmits any RTP packet). Thanks for the report and patch. ---- [1] http://trac.pjsip.org/repos/changeset/2996 BR, nanang On Tue, Sep 22, 2009 at 8:43 PM, Michele Cicciotti <m.cicciotti at khamsalabs.net> wrote: > > 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: > > Peer A calls peer B > Peer B answers; peer B creates a new media session with a bidirectional stream > Peer A puts call on hold; peer B creates a new media session with a receive-only stream > 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 > -- > > > Michele Cicciotti > Research & Development > > Mobile:???+ 39 339 3206609 > E-mail:??? m.cicciotti at khamsalabs.net > > KHAMSA SA > Via Giacometti 1 - 6900 Lugano - Switzerland > Web:?? www.khamsa.net > > Technical Support CH:??+ 41 (0)91 2206457 > Technical Support IT:???+ 39 02 911930891 > E-mail:??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. > > > > Index: pjmedia/src/pjmedia/stream.c > =================================================================== > @@ -1892,15 +1892,7 @@ > ? ? ? ? ? ? ? ? ? ? ?stream->port.info.samples_per_frame, > ? ? ? ? ? ? ? ? ? ? ?info->ssrc); > ?#endif > + ? ?/* Initialize RTCP statistics, because a call put on hold will not > + ? ? * transmit anything and the fields would stay empty. > + ? ? */ > + ? ?if (info->rtp_seq_ts_set & 1) > + ? ? ? stream->rtcp.stat.rtp_tx_last_seq = info->rtp_seq; > > + ? ?if (info->rtp_seq_ts_set & (1 << 1)) > + ? ? ? stream->rtcp.stat.rtp_tx_last_ts = info->rtp_ts; > + > ? ? /* Init jitter buffer parameters: */ > ? ? if (info->jb_max >= stream->codec_param.info.frm_ptime) > ? ? ? ?jb_max = (info->jb_max + stream->codec_param.info.frm_ptime - 1) / > > _______________________________________________ > 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 >
