[SIPForum-discussion] Incorrect RTCP reports being generated.

[Herve Jourdain]

Hi,

 

In theory, it might be allowed in conjunction with Marker bit - that you
have - and in case of VAD, which doesn't seem to be the case here.

Else I don't think it should change the sequence number.

BUT interoperability tests show a tendency in various devices to use Marker
bit to "resynchronize" the RTP flow, and therefore resetting the sequence
number.

This usually happens when the remote is "lost" in its synchronization, or
when the remote internally switches from one source stream to another source
stream.

 

As to the impact on the RTCP stack, I'm not sure exactly what it can have, I
guess it's implementation dependant also, and if your RTP/RTCP stack
resynchronizes itself on the Marker bit or not.

 

Regards,

 

Herve

 

  _____  

From: discussion-bounces at sipforum.org
[mailto:discussion-bounces at sipforum.org] On Behalf Of usman chaudhry
Sent: jeudi 9 octobre 2008 12:06
To: Beith, Gordon; discussion at sipforum.org
Subject: Re: [SIPForum-discussion] Incorrect RTCP reports being generated.

 

Hello All,

    I have noticed that the RTP stream that is coming from the MGW to the
CPE has its sequence number being reset twice. Can this be the reason for
the incorrect RTCP Senders Reports generated by the CPE. Refer to the
attached JPEG, where 192.168.1.4 is the MGW and 10.11.128.126 is the CPE.
Note that the Seq Number changes but the SSRC remains the same. Is this
allowed as per RFC 1889; its not very clear.
   

Regards
Usman.

  <file:///D:\Profiles\ADMINI~1\LOCALS~1\Temp\moz-screenshot.jpg>
<file:///D:\Profiles\ADMINI~1\LOCALS~1\Temp\moz-screenshot-1.jpg> 

 

----- Original Message ----
From: "Beith, Gordon" <GBeith at empirix.com>
To: usman chaudhry <usman_chaudhry at yahoo.com>
Sent: Wednesday, October 8, 2008 10:47:40 PM
Subject: RE: [SIPForum-discussion] Incorrect RTCP reports being generated.

Sounds wrong to me. Seems that the Sip UA has an odd implementation.

/Gordon

 

  _____  

From: discussion-bounces at sipforum.org
[mailto:discussion-bounces at sipforum.org] On Behalf Of usman chaudhry
Sent: Wednesday, October 08, 2008 3:01 AM
To: discussion at sipforum.org
Subject: [SIPForum-discussion] Incorrect RTCP reports being generated.

 

Hello All,

    I have a peculiar issue where for a SIP --> PSTN call the RTCP reports
(i.e. Sender Reports) generated by SIP UA (i.e. xlite) count all RTP packets
that come before the 200 OK as lost. These RTCP reports are then used to
calculate the MoS for the call and since the SIP UA reports these packets as
lost the MoS value is abysmally low (i.e. 1.0 - 2.0) whereas in reality the
call quality is all right . Note that these RTP packets (highlighted in RED)
are sent by the MGW to playback the Ring tone generated by the PSTN; and as
far as I know this is the correct call flow for a SIP-->PSTN Call. Following
is the basic call flow.

SIP (UA)                                    MGW
PSTN

 

----------------------INVITE---------------------->

<---------------- 100 Trying --------------------


                                                         ------------------
IAM --------------------->

                                                         <----------------
ACM --------------------

                                                         <--------- PSTN
Ringing Tone ------

<------------Ring Tone (RTP) -----------------

<-------- 183 Session In Progress --------

                                                        <----------------
ANM --------------------

<---------------- 200 OK ------------------------

 

<------------------------------------ Voice Path complete
----------------------------------> 

 

    Now I have the following question with this regard
1) Is this the correct behavior by the SIP UA (i.e. xlite) to report these
RTP packets as dropped. Note that the SIP UA uses these packets to playback
the ringtone.
2) Is there any standard which specifies  how to generate RTCP reports for
this particular call flow. Note that network uses RFC 1889 for RTP/RTCP
traffic

Rgds
Usman.

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sipforum.org/pipermail/discussion/attachments/20081010/c693df60/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3100 bytes
Desc: not available
URL: <http://sipforum.org/pipermail/discussion/attachments/20081010/c693df60/attachment-0002.bin>