Hi Meir Leshem, Please find my understanding for your questions under *<sachin> </sachin>*tag. Please correct my understanding if anyone think otherwise.
Best Regards Sachin Rastogi On Fri, Nov 27, 2009 at 2:55 PM, Meir Leshem <[email protected]>wrote: > Hi all! > I didn't understood the meaning of "must accept the offered ptime" and > "official ptimes for > For each coder". There are no official ptimes for codecs. G.711 and > G.729 can work in any multiple of 10 ms. G.723 can work in any multiple > of 30 ms. In mobile networks G.711 works in 5 ms. > So I have several questions never answered in the standards clearly: > > 1. Do I declare on the ptime I am sending or the ptime I am expecting to > receive? > *<sachin>*It is refer to what I am expecting to receive As per rfc 3264 section 5.1 ============================ If the ptime attribute is present for a stream, it indicates the desired packetization interval that the offerer would like to receive. The ptime attribute MUST be greater than zero. as per section 6.1 of rfc 3264 =============================== The answerer MAY include a non-zero ptime attribute for any media stream; this indicates the packetization interval that the answerer would like to receive. There is no requirement that the packetization interval be the same in each direction for a particular stream. The above discuss two paragraphs are valid for *Unicast streams* but for Multicast streams, section 6.2 of rfc 3264 says The ptime and bandwidth attributes in the answer MUST equal the ones in the offer, if present. If not present, a non-zero ptime MAY be added to the answer. *</sachin>* > 2. When I propose several codecs (e.g. G.711 and G.723) and expect the > peer to select one of them what is the purpose of ptime (is it related > to the first codec?). BTW - CiscoSip doesn't send ptime with a list of > codecs because of this ambiguity. > *<sachin>* It is a media-level attribute i.e. It is associated with a 'm line'. So if a 'm line' contains multiple codecs then 'ptime' will be same for all codecs. *</sachin>* > 3. If I receive a not supported ptime for the proposed codec(s) what > should I do - reject the request or propose my supported ptime (you said > there is no negotiation so it is probably useless...)? > *<sachin>* As per my understanding,Call should be terminated by sending 'BYE'. *</sachin>* > I will appreciate the forum answers to these unsolved long-time > questions > > Regards > --------------------------------------- > Meir Leshem > Veraz Networks > Tel: +972-3-9709107 > Fax: +972-3-9709442 > Mobile: +972-54-9709107 > --------------------------------------- > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of > Manoj Priyankara [TG] > Sent: Friday, November 27, 2009 6:29 AM > To: Paulo Borelli; [email protected]; > [email protected] > Subject: Re: [Sip-implementors] ptime > > Thanks Paulo! > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of > Paulo Borelli > Sent: Friday, November 27, 2009 4:52 AM > To: Manoj Priyankara [TG]; [email protected]; > [email protected] > Subject: Re: [Sip-implementors] ptime > > Hi Manoj, > > As per my knowledge, yes. It's mandatory to support the official ptimes > for > each coder your implementation supports. > > Regards > Paulo Borelli > > -------------------------------------------------- > From: "Manoj Priyankara [TG]" <[email protected]> > Sent: Wednesday, November 25, 2009 12:49 PM > To: "Paulo Borelli" <[email protected]>; > <[email protected]>; > <[email protected]> > Subject: Re: [Sip-implementors] ptime > > > Thanks paulo/sunil. > > I also agree with paulo. When i tested two end points having different > > > ptimes, they worked fine. > > According to paulo's comment, there's no negotiation of ptime and two > end > > points can work with diffirent ptimes in the same session . Is that > right? > > br, > > Manoj > > --- original message --- > > From: "Paulo Borelli" <[email protected]> > > Subject: Re: [Sip-implementors] ptime > > Date: 26th November 2009 > > Time: 6:39:08 pm > > > > Hi, > > > > ptime does not need to match the other side. The remote side must > accept > > what is offered. ptime may be assymetrical between the two media > > endpoints. > > One may send G.729 @ 20 ms while the other sends G.729 @ 40 ms. Both > must > > be > > able to decode the flow from the other side. When you configure a > media > > endpoint to "work" with "x" ms, you are really telling it to > *generate* at > > "x" ms. But it should be able to accept/decode different ptimes in the > > receiving side. > > > > Regards > > Paulo Borelli > > > > -------------------------------------------------- > > From: <[email protected]> > > Sent: Thursday, November 26, 2009 11:29 AM > > To: <[email protected]>; <[email protected]> > > Subject: Re: [Sip-implementors] ptime > > > >> Hi, > >> > >> Ptime or Packetization time is useful for audio sessions. As per my > >> understanding, it should not affect signaling. However if two end > points > >> settle on different packetization time, then actual voice call would > >> have a problem. > >> > >> ptime tells amount of media which can be encapsulated in each packet. > >> Difference in ptime would result in breakage of voice and the audio > call > >> established will not be clear. > >> > >> Regards, > >> Sunil > >> > >> -----Original Message----- > >> From: [email protected] > >> [mailto:[email protected]] On Behalf Of > >> Manoj Priyankara [TG] > >> Sent: Thursday, November 26, 2009 11:46 AM > >> To: [email protected] > >> Subject: [Sip-implementors] ptime > >> > >> Dear All, > >> > >> Can anyone explain how ptime affects in call setups? > >> Should all the UA's include ptime in the SDP of the INVITE? > >> If it is included, and does not match with the packet time of the > other > >> party what would happen? > >> > >> Little information could be found in RFC 2327. Pls help > >> > >> Thanks > >> BR, > >> Manoj > >> > >> > >> _______________________________________________ > >> Sip-implementors mailing list > >> [email protected] > >> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > >> > >> Please do not print this email unless it is absolutely necessary. > >> > >> The information contained in this electronic message and any > attachments > >> to this message are intended for the exclusive use of the > addressee(s) > >> and > >> may contain proprietary, confidential or privileged information. If > you > >> are not the intended recipient, you should not disseminate, > distribute or > >> copy this e-mail. Please notify the sender immediately and destroy > all > >> copies of this message and any attachments. > >> > >> WARNING: Computer viruses can be transmitted via email. The recipient > >> should check this email and any attachments for the presence of > viruses. > >> The company accepts no liability for any damage caused by any virus > >> transmitted by this email. > >> > >> www.wipro.com > >> > >> _______________________________________________ > >> Sip-implementors mailing list > >> [email protected] > >> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > >> > > > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
