The other end isn't sip and he ignored my question asking about what it actually is, so I was waiting on that response before providing an answer. Its hard to provide a real answer when you only know 1/2 the problem. On Aug 27, 2010, at 12:09 PM, Steven Ayre wrote:
AFAIK no, but UPDATE can renegotiate codecs so that might be able to adjust ptime.
In practice, if you're a proxy you're not handling media so you pass through the SDP unchanged. So ptime will be what the other end said it's sending and you don't need to work about ptime being different, because you won't send anything until you know what ptime you'll be using.
For a B2BUA like FreeSWITCH, it should be able to use different ptimes on different legs since each leg is a separate media stream. Converting 20ms->40ms It should queue up 40ms and then send it, and for 40ms->20ms it should send two 20ms packets for every 40ms packet. Sure you can't match leg a's ptime to leg b's, but the ptime used is left up to the client and it probably doesn't matter since it'll still work.
At least that's how I think it'd work out.
-Steve
On 27 August 2010 15:20, Johny Kadarisman Kwan <jkr888@gmail.com> wrote: Is ptime adaptable? i won't know what is the rate at the beginning of sip/sdp negotiation. But it possible to calculate how much audio once i process the upstream audio. So, is it possible to change the ptime while call in progress phase?
Btw, everything works fine now, with 20ms, 160 bytes chunk and FS just play that smoothly. Thanks for all the pointer.
JK
On Thu, Aug 26, 2010 at 12:49 PM, Michael Jerris <mike@jerris.com> wrote: If you are already getting them in larger chunks, you might as well pass along the packet size you get instead of breaking them up, just make sure to set the ptime correct. What is the source of the audio?
Mike
On Aug 26, 2010, at 10:15 AM, Johny Kadarisman Kwan wrote:
I adjust rtp timestamp to increment += 160, still no good audio. i took code that handle speex previously, timestamp was set to 320increment. seems working fine with speex/16k
still no good ulaw audio. I'm converting up stream audio that sent to me in a large chunk, do some processing and now breaking up into smaller rtp chunk. do i have to limit the rtp paket rate to freeswitch (ie. 20ms delay between them)?
Thanks again.
On Thu, Aug 26, 2010 at 10:02 AM, Brian West <brian@freeswitch.org> wrote: Its could be your timestamps too... how many are you incrementing on each time stamp? If you lie about time timestamps say send timestamps that jump by 320 but only send 160 byte payload you're still going to get the warning I'm pretty sure.
/b
On Aug 26, 2010, at 8:54 AM, Johny Kadarisman Kwan wrote:
Its excellent that FS able to auto adjust to 40ms.Sending 160 bytes payload does eliminate warning message from FS. My audio doesn't work yet, problem must be something else. At least no more issues on rtp audio framing ;)
Thanks, JK