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? 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. 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...)? 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
