On Tue, Aug 17, 2010 at 5:18 AM, Jeff Brower <jbrower at signalogic.com> wrote: > Rob- > >> Hi all, need some guidance on where in PJSUA/SIP/MEDIA to look. >> >> Here is the situation: We have a perfectly (well almost) working client - >> which only supports G711 u law. We often make a call to various PSTN phones >> via different SIP gateways. The call flows of those gateways is almost the >> same - they send 100, then 183, then 200. However, when we test against a >> specific gateway, for some reason, our client crashes. >> >> When we analyzed why, we observed that when PJSIP receives their 183, it >> tries and creates an audio playback stream assuming it will receive packets >> in 100 millisecond intervals and 800 samples per frame (that's what our >> dev_create_stream callback logs ?reports). ?However, the gateway is actually >> sending packets at 20ms @ 160 samples per second. I validated this by >> analyzing the RTP stream. >> >> This is causing my app to crash (my target platform which is android, only >> works with 20ms @ 160 samples per second). I am trying to figure out >> where/which function within PJSIP is making this decision so I can set logs >> and figure out. Any pointer? I am trying to find the root function that >> starts this chain. > > It sounds like the gateway in question and pjsip are not negotiating "packet time"; i.e. interval of voice time > represented by each packet. ?Suggest to read about the "ptime" parameter in pjsip... ?As a work-around you might be > able to program pjsip to handle it correctly. ?The general solution is for both sides to not rely on default values > and negotiate this along with other rtp session parameters. > As receiver, client is required to be able to decode any packet length (within reasonable limit), hence the ptime is not necessary for decoding, and that's what pjsip does. The 100ms frame interval may have come from the ptime setting in pjsua_media_config, which I assume your app has changed it to 100. -benny
