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



_______________________________________________
FreeSWITCH-dev mailing list
FreeSWITCH-dev@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
http://www.freeswitch.org


_______________________________________________
FreeSWITCH-dev mailing list
FreeSWITCH-dev@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
http://www.freeswitch.org



_______________________________________________
FreeSWITCH-dev mailing list
FreeSWITCH-dev@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
http://www.freeswitch.org