On Tue, Feb 10, 2009 at 12:22 AM, D. S. <[email protected]> wrote: > On Sun, Feb 8, 2009 at 9:28 PM, Alexander Chemeris > <[email protected]> wrote: >> On Fri, Feb 6, 2009 at 11:52 PM, D. S. <[email protected]> wrote: >>> As it stands, G.722 sessions will not connect using Recon with sipXtapi. >>> The reason is that G.722 sessions are negotiated with 8000 as the >>> sample rate even though it actually operates at 16000. >>> See sec. 4.5.2 in RFC3551 and the following link: >>> http://en.wikipedia.org/wiki/G.722 >> >> Yes, this is a known problem, and it's already workarounded in >> sipXtapi. Look at following lines: >> sipXtackLib\src\net\SdpBody.cpp:1272 >> sipXtackLib\src\net\SdpBody.cpp:1778 >> sipXtackLib\src\net\SdpHelper.cpp:220 >> >> So if it does not work with recon, it's a problem with recon I guess. >> I recall I tested this with some phones and it worked. > > Thank you for pointing me to this. > This would require Recon to hack the sample rate passed to sipXsdpLib > because Recon uses Resiprocate for the SIP stack. > IMHO, it would be better to make changes to the static tables in > SdpDefaultCodecFactory.cpp and plgg722.c because it would be handled > by the SDP library itself for all calling SIP stacks. > Static data changes are simpler than coded if-thens. > Of course, your mileage may vary if something depends on this somehow > and breaks.
Yeah, I recall it was a deliberate decision. I recall value from the SDP is used to determine how to handle this codec in flowgraph. E.g. if reported codec samplerate differs from a flowgraph samplerate, data will be automatically up/downscaled by decoder/encoder resource. (you need to compile with Speex support enabled for this). So, it's a bug in specs and it should be handled as a bug. I.e. it should introduce as small confusion as possible. My hacks are small enough, and I hope recon can be hacked the same way. - Regards, Alexander Chemeris. SIPez LLC. SIP VoIP, IM and Presence Consulting http://www.SIPez.com tel: +1 (617) 273-4000 _______________________________________________ sipxtapi-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
