[Freeswitch-dev] FS complained on RTP packet.
I'm trying to convert a proprietary audio stream into sip/rtp compatible. At this point, i'm able to pass sip negotiation with FS, and trying to stream PCMU/8000 codec. But something not right on my end, and FS complained about the ptime settings. I'm sending 320 bytes ulaw payload on every rtp packet. Is that the right amount? appreciate if anyone could point some info on these topics. Thanks, JK =============== *2010-08-25 16:36:58.142328 [WARNING] mod_sofia.c:1013 We were told to use ptime 20 but what they meant to say was 40* *This issue has so far been identified to happen on the following broken platforms/devices:* *Linksys/Sipura aka Cisco* *ShoreTel* *Sonus/L3* *We will try to fix it but some of the devices on this list are so broken,* *who knows what will happen..* *===================*
20 ms of ulaw would be 160 bytes, not 320. Mike On Aug 25, 2010, at 4:46 PM, Johny Kadarisman Kwan wrote:
I'm trying to convert a proprietary audio stream into sip/rtp compatible. At this point, i'm able to pass sip negotiation with FS, and trying to stream PCMU/8000 codec. But something not right on my end, and FS complained about the ptime settings. I'm sending 320 bytes ulaw payload on every rtp packet. Is that the right amount? appreciate if anyone could point some info on these topics.
Thanks, JK
=============== 2010-08-25 16:36:58.142328 [WARNING] mod_sofia.c:1013 We were told to use ptime 20 but what they meant to say was 40 This issue has so far been identified to happen on the following broken platforms/devices: Linksys/Sipura aka Cisco ShoreTel Sonus/L3 We will try to fix it but some of the devices on this list are so broken, who knows what will happen.. ===================
Which is 40ms... which is what FS tells you. FS will look at the amount *actually* received, instead of the amount the client claimed it will sent. It auto-adjusts to that amount, and displays the warning message because your client is either misconfigured or broken (some SIP phone implementations lie). Because it auto-adjusts it shouldn't be an issue, but it could also affect quality so a warning is given just in case so that you can fix the problem on the client. -Steve On 26 August 2010 04:30, Michael Jerris <mike@jerris.com> wrote:
20 ms of ulaw would be 160 bytes, not 320.
Mike
On Aug 25, 2010, at 4:46 PM, Johny Kadarisman Kwan wrote:
I'm trying to convert a proprietary audio stream into sip/rtp compatible. At this point, i'm able to pass sip negotiation with FS, and trying to stream PCMU/8000 codec. But something not right on my end, and FS complained about the ptime settings. I'm sending 320 bytes ulaw payload on every rtp packet. Is that the right amount? appreciate if anyone could point some info on these topics.
Thanks, JK
=============== *2010-08-25 16:36:58.142328 [WARNING] mod_sofia.c:1013 We were told to use ptime 20 but what they meant to say was 40* *This issue has so far been identified to happen on the following broken platforms/devices:* *Linksys/Sipura aka Cisco* *ShoreTel* *Sonus/L3* *We will try to fix it but some of the devices on this list are so broken, * *who knows what will happen..* *===================*
_______________________________________________ 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
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 On Thu, Aug 26, 2010 at 4:13 AM, Steven Ayre <steveayre@gmail.com> wrote:
Which is 40ms... which is what FS tells you. FS will look at the amount *actually* received, instead of the amount the client claimed it will sent. It auto-adjusts to that amount, and displays the warning message because your client is either misconfigured or broken (some SIP phone implementations lie).
Because it auto-adjusts it shouldn't be an issue, but it could also affect quality so a warning is given just in case so that you can fix the problem on the client.
-Steve
On 26 August 2010 04:30, Michael Jerris <mike@jerris.com> wrote:
20 ms of ulaw would be 160 bytes, not 320.
Mike
On Aug 25, 2010, at 4:46 PM, Johny Kadarisman Kwan wrote:
I'm trying to convert a proprietary audio stream into sip/rtp compatible. At this point, i'm able to pass sip negotiation with FS, and trying to stream PCMU/8000 codec. But something not right on my end, and FS complained about the ptime settings. I'm sending 320 bytes ulaw payload on every rtp packet. Is that the right amount? appreciate if anyone could point some info on these topics.
Thanks, JK
=============== *2010-08-25 16:36:58.142328 [WARNING] mod_sofia.c:1013 We were told to use ptime 20 but what they meant to say was 40* *This issue has so far been identified to happen on the following broken platforms/devices:* *Linksys/Sipura aka Cisco* *ShoreTel* *Sonus/L3* *We will try to fix it but some of the devices on this list are so broken,* *who knows what will happen..* *===================*
_______________________________________________ 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
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
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
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
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
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
_______________________________________________ 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
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
participants (4)
-
Brian West
-
Johny Kadarisman Kwan
-
Michael Jerris
-
Steven Ayre