Subject: [payload] RTP Timestamping in Control messages of IuCS interface.

From: Sambasiva Rao Manchili <[email-masked]>
Date: Sat, 19 Feb 2011 18:07:51 +0100

Hallo,

Can some one in IETF list, please help me to clarify the point w.r.t the Time stamping in RTP header for Audio Stream AMR 5.9.
I hope I am addressing to right group.

Our implementation of RTP is not accepting the two control messages belonging to the UPP(User plane protocol above RTP) if the two consecutive control packets arrived has same time stamp with different sequence numbers.
The two control messages are UPP_INIT_ACK and Rate Control Message which belongs to UPP layer on IuCS user plane stack.
Our implementation expects the time stamp of second packet to be 320ms greater than the time stamp arrived in 1st Control message of RTP header.

Our counter part RTP stack says their implementation is right and can have the same time stamp in the RTP header of these control messages.

 RFC 3350 tells about equal timestamps for Video stream belonging to same frame, but does not specifically tell about the control messages of its upper layer.
We have read the RFC 3550 , section 5.1 does NOT prevent RTP packets
from having equal timestamps but rather explicitly allows for it:

      Several consecutive RTP packets will have equal timestamps if
      they are (logically) generated at once, e.g., belong to the same
      video frame.  Consecutive RTP packets MAY contain timestamps that
      are not monotonic if the data is not transmitted in the order it
      was sampled, as in the case of MPEG interpolated video frames.
      (The sequence numbers of the packets as transmitted will still be
      monotonic.)

May I kindly ask the RTP experts in Audio Stream area(or specific to IuCS ) can please clarify me.

Thank you very much for your time.

Best Regads,
Samba.

This email and any attachment may contain confidential information which is intended for use only by the addressee(s) named above. If you received this email by mistake, please notify the sender immediately, and delete the email from your system. You are prohibited from copying, disseminating or otherwise using the email or any attachment.

---

From: Roni Even <[email-masked]>
Date: Sat, 19 Feb 2011 23:34:38 +0200

Hi,
I am not that familiar with the AMR control message but the general
definition for time stamp is the RTP timestamp corresponds to the sampling
instant of the first sample encoded for the first frame-block in the packet.
So if there is no speech information in the second packet it should have the
same timestamp as the previous one.

Roni Even

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Sambasiva Rao Manchili
> Sent: Saturday, February 19, 2011 7:08 PM
> To: [email-masked]; [email-masked]; [email-masked]; [email-masked]
> Cc: Antonio Gambin; Ralf Kühl; Markus Locher
> Subject: [payload] RTP Timestamping in Control messages of IuCS
> interface.
> 
> Hallo,
> 
> Can some one in IETF list, please help me to clarify the point w.r.t
> the Time stamping in RTP header for Audio Stream AMR 5.9.
> Our implementation of RTP is not accepting the two control messages
> belonging to the UPP(User plane protocol above RTP) if the two
> consecutive control packets arrived has same time stamp with different
> sequence numbers.
> The two control messages are UPP_INIT_ACK and Rate Control Message
> which belongs to UPP layer on IuCS user plane stack.
> Our implementation expects the time stamp of second packet to be 320ms
> greater than the time stamp arrived in 1st Control message of RTP
> header.
> 
> Our counter part RTP stack says their implementation is right and can
> have the same time stamp in the RTP header of these control messages.
> 
>  RFC 3350 tells about equal timestamps for Video stream belonging to
> same frame, but does not specifically tell about the control messages
> of its upper layer.
> This email and any attachment may contain confidential information
> which is intended for use only by the addressee(s) named above. If you
> received this email by mistake, please notify the sender immediately,
> and delete the email from your system. You are prohibited from copying,
> disseminating or otherwise using the email or any attachment.
> 
> _______________________________________________
> payload mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/payload

---

From: Roni Even <[email-masked]>
Date: Sun, 20 Feb 2011 10:16:18 +0200

Hi,
These mailing lists are the right ones for RTP issues.
As for your question, the timestamp is the sample timestamp so if there is
no speech in the packet than the time stamp will not progress.
For example consider a case where you have an RTP packet with control and
speech data followed by a packet with only control and a packet with speech
and control.
If you will advance the timestamp for the control only packet what will you
do with the next one who has the next sampled speech frame.

With my limited knowledge of AMR payload, the RTP layer has the table of
content which need to know if there is a speech or control frame in the
packet, am I wrong? 

Roni

> From: Sambasiva Rao Manchili
> [mailto:[email-masked]]
> Sent: Sunday, February 20, 2011 9:51 AM
> To: Roni Even; [email-masked]; [email-masked]
> Subject: RE: [payload] RTP Timestamping in Control messages of IuCS
> interface.
> 
> Hi Roni,
> Thank you very much for the writing to me over the weekend.
> Yes, the RTP timestamp corresponds to the sampling.  In this case it is
> 16 samples per milli second for speech.
> It is uncertain for us about the timestmamp of these two consecutive
> control messages which are exchanged before real speech transmit on
> channel. These are first messages exchanged over RTP.
> These both control messages are to be acked before real speech
> transmits. Currently we discard one control message as both have same
> timestamp and speech will not be transmitted as one control message is
> discarded.
> 
> When we capture on wireshark we see difference of 2.5 ms in wireshark
> timestamp between these two control packets but RTP header timestamp
> remains same but sequence number increases.
> If I understood you right as long as there exists no real speech
> encoded in the packet then such packets can carry same timestamps.
> But then the question comes is it responsibility of RTP to see the
> content of bytes belonging to upper layer and decide if this has speech
> or normal control message and then evaluate timestamp of RTP header ?
> 
> Can you please lead me to group who are experts in AMR Iu UP Control
> messages (If I had not put the right group in my mailing list)?
> Thank you,
> Samba.
> 
> ________________________________________
> From: Roni Even [[email-masked]]
> Sent: Saturday, February 19, 2011 10:34 PM
> To: Sambasiva Rao Manchili; [email-masked]; [email-masked]
> Subject: RE: [payload] RTP Timestamping in Control messages of IuCS
> interface.
> 
> Hi,

---

From: Sambasiva Rao Manchili <[email-masked]>
Date: Sun, 20 Feb 2011 08:50:37 +0100

Hi Roni,
Thank you very much for the writing to me over the weekend.
Yes, the RTP timestamp corresponds to the sampling.  In this case it is 16 samples per milli second for speech.
It is uncertain for us about the timestmamp of these two consecutive control messages which are exchanged before real speech transmit on channel. These are first messages exchanged over RTP.
These both control messages are to be acked before real speech transmits. Currently we discard one control message as both have same timestamp and speech will not be transmitted as one control message is discarded.

When we capture on wireshark we see difference of 2.5 ms in wireshark timestamp between these two control packets but RTP header timestamp remains same but sequence number increases.
If I understood you right as long as there exists no real speech encoded in the packet then such packets can carry same timestamps.
But then the question comes is it responsibility of RTP to see the content of bytes belonging to upper layer and decide if this has speech or normal control message and then evaluate timestamp of RTP header ?

Can you please lead me to group who are experts in AMR Iu UP Control messages (If I had not put the right group in my mailing list)?
Thank you,
Samba.

Subject: RE: [payload] RTP Timestamping in Control messages of IuCS interface.

Hi,

Roni Even

---

From: Sambasiva Rao Manchili <[email-masked]>
Date: Mon, 21 Feb 2011 12:04:49 +0100

Hi Roni,
Sorry for late reply.
Since these are control messages of Upper layer(IuUP Protocol) all the messages from upper layer should be treated same at RTP layer. This as per Layered prorotocl architecture princples.

To my knowledge RTP layer has no table of  contents which differentiates it as Speech or control frame of upper layer.
All messages either Control message or Speech message of Upper layer of RTP  belonging to a paricular subscriber will be sent with same RTP Session number (Sync Source Identifier)

The payload type of RTP may be able to do this, but specification also tells in Section 5 of RFC 3550 that
"An RTP source MAY change the payload type during a session, but this field SHOULD NOT be used for multiplexing separate media streams"

Here the Payload type we use on IuCS interface for all type of messages is 96.

Thank you,
Samba.

-----Original Message-----
From: Roni Even [mailto:[email-masked]]
Sent: Sunday, 20. February, 2011 09:16
To: Sambasiva Rao Manchili; [email-masked]; [email-masked]
Cc: Antonio Gambin; Ralf Kühl; Markus Locher
Subject: RE: [payload] RTP Timestamping in Control messages of IuCS interface.

Hi,
These mailing lists are the right ones for RTP issues.
As for your question, the timestamp is the sample timestamp so if there is no speech in the packet than the time stamp will not progress.
For example consider a case where you have an RTP packet with control and speech data followed by a packet with only control and a packet with speech and control.
If you will advance the timestamp for the control only packet what will you do with the next one who has the next sampled speech frame.

With my limited knowledge of AMR payload, the RTP layer has the table of content which need to know if there is a speech or control frame in the packet, am I wrong?

Roni

> content of bytes belonging to upper layer and decide if this has
> speech or normal control message and then evaluate timestamp of RTP header ?
>
> definition for time stamp is the RTP timestamp corresponds to the
> sampling instant of the first sample encoded for the first frame-block
> in the packet.
> So if there is no speech information in the second packet it should
> have the same timestamp as the previous one.
>
> Roni Even
>
> > Our counter part RTP stack says their implementation is right and
> > can have the same time stamp in the RTP header of these control messages.
> >
> > same frame, but does not specifically tell about the control
> > messages of its upper layer.
> > received this email by mistake, please notify the sender
> > immediately, and delete the email from your system. You are
> > prohibited from
> copying,
> and delete the email from your system. You are prohibited from
> copying, disseminating or otherwise using the email or any attachment.

---

From: Roni Even <[email-masked]>
Date: Mon, 21 Feb 2011 15:44:34 +0200

Hi,
I am not sure if you read RFC4867 (http://tools.ietf.org/html/rfc4867) which
is the RTP payload specification for AMR

Roni Even

> Sent: Monday, February 21, 2011 1:05 PM
> Since these are control messages of Upper layer(IuUP Protocol) all the
> messages from upper layer should be treated same at RTP layer. This as
> per Layered prorotocl architecture princples.
> 
> To my knowledge RTP layer has no table of  contents which
> differentiates it as Speech or control frame of upper layer.
> All messages either Control message or Speech message of Upper layer of
> RTP  belonging to a paricular subscriber will be sent with same RTP
> Session number (Sync Source Identifier)
> 
> "An RTP source MAY change the payload type during a session, but this
> field SHOULD NOT be used for multiplexing separate media streams"
> 
> As for your question, the timestamp is the sample timestamp so if there
> is no speech in the packet than the time stamp will not progress.
> For example consider a case where you have an RTP packet with control
> and speech data followed by a packet with only control and a packet
> with speech and control.
> If you will advance the timestamp for the control only packet what will
> you do with the next one who has the next sampled speech frame.
> 
> With my limited knowledge of AMR payload, the RTP layer has the table
> of content which need to know if there is a speech or control frame in
> the packet, am I wrong?
> 
> Roni
> 
> > >       (The sequence numbers of the packets as transmitted will
> still
> > be
> > >       monotonic.)
> > >
> > > May I kindly ask the RTP experts in Audio Stream area(or specific
> to
> > > IuCS ) can please clarify me.
> > >

---

From: Roni Even <[email-masked]>
Date: Mon, 21 Feb 2011 15:56:41 +0200

Hi,

Roni Even