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

From: Roni Even <[email-masked]>
Date: Mon, 21 Feb 2011 15:56:41 +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

> -----Original Message-----
> From: Sambasiva Rao Manchili
> [mailto:[email-masked]]
> Sent: Monday, February 21, 2011 1:05 PM
> To: Roni Even; [email-masked]; [email-masked]
> Cc: Antonio Gambin; Ralf Kühl; Markus Locher
> Subject: RE: [payload] RTP Timestamping in Control messages of IuCS
> interface.
> 
> 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
> 
> > -----Original Message-----
> > From: Sambasiva Rao Manchili
> > [mailto:[email-masked]]
> > Sent: Sunday, February 20, 2011 9:51 AM
> > To: Roni Even; [email-masked]; [email-masked]
> > Cc: Antonio Gambin; Ralf Kühl; Markus Locher
> > 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]
> > Cc: Antonio Gambin; Ralf Kühl; Markus Locher
> > Subject: RE: [payload] RTP Timestamping in Control messages of IuCS
> > interface.
> >
> > 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.
> > > 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.
> > >
> > > _______________________________________________
> > > payload mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/payload
> >
> >
> >
> > 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.
> 
> 
> 
> 
> 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.