[Freeswitch-dev] FS complained on RTP packet.

[Steven Ayre]

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 at 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 at 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 at 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 at 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 at 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 at 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 at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
> http://www.freeswitch.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20100827/7d1accf5/attachment-0001.html