-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, today I finylly got a working Ekiga Softphone version which is able to use high quality celt codec with FS :) On my way to get it work with FS I found that Ekiga currently uses codec code 95 in SDP while FS uses 114. Changing FS to 95 made it works so I'm now able to listen to my PBX-based MP3-Player on Windows Desktop instead of using Ubuntu. veeeeeerrry cool work of FS team !!!!! Concerning the codec code 95, 114 or whatever I found the link below, which states that every codec code between 96 and 127 is OK but it seems they prefer 97 ... http://tools.ietf.org/html/draft-valin-celt-rtp-profile-02#section-5 You can get windows Ekiga 3.2.5 (with celt 0.5.1) here: http://wwwuser.gwdg.de/~mrickma/ekiga/ekiga-setup-3.2.5-release.exe regards Helmut -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) iD8DBQFKbyPL4tZeNddg3dwRAiDMAKChqgWeirYklgra5nN7NGwZSpK6wQCgjYox Q/okubHauhgjtoiogzFM9mI= =Ml4q -----END PGP SIGNATURE-----
On Jul 28, 2009, at 11:14 AM, Helmut Kuper wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hello,
today I finylly got a working Ekiga Softphone version which is able to use high quality celt codec with FS :)
On my way to get it work with FS I found that Ekiga currently uses codec code 95 in SDP while FS uses 114. Changing FS to 95 made it works so I'm now able to listen to my PBX-based MP3-Player on Windows Desktop instead of using Ubuntu.
It should work if they use different codec numbers.... I suspect we are sending on 114 and receiving on 95 which is what should take place. This is one of those areas most people fail to implement properly. We send the remote our RTP map they send us theirs... Can you get a packet capture of this taking place so I can verify who is at fault? /b
veeeeeerrry cool work of FS team !!!!!
Concerning the codec code 95, 114 or whatever I found the link below, which states that every codec code between 96 and 127 is OK but it seems they prefer 97 ...
http://tools.ietf.org/html/draft-valin-celt-rtp-profile-02#section-5
You can get windows Ekiga 3.2.5 (with celt 0.5.1) here: http://wwwuser.gwdg.de/~mrickma/ekiga/ekiga-setup-3.2.5-release.exe
using 95 is wrong. That is not part of the dynamic range for unassigned codecs. This needs to be fixed on their side. MIke On Jul 28, 2009, at 12:23 PM, Brian West wrote:
On Jul 28, 2009, at 11:14 AM, Helmut Kuper wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hello,
today I finylly got a working Ekiga Softphone version which is able to use high quality celt codec with FS :)
On my way to get it work with FS I found that Ekiga currently uses codec code 95 in SDP while FS uses 114. Changing FS to 95 made it works so I'm now able to listen to my PBX-based MP3-Player on Windows Desktop instead of using Ubuntu.
It should work if they use different codec numbers.... I suspect we are sending on 114 and receiving on 95 which is what should take place. This is one of those areas most people fail to implement properly. We send the remote our RTP map they send us theirs... Can you get a packet capture of this taking place so I can verify who is at fault?
/b
veeeeeerrry cool work of FS team !!!!!
Concerning the codec code 95, 114 or whatever I found the link below, which states that every codec code between 96 and 127 is OK but it seems they prefer 97 ...
http://tools.ietf.org/html/draft-valin-celt-rtp-profile-02#section-5
You can get windows Ekiga 3.2.5 (with celt 0.5.1) here: http://wwwuser.gwdg.de/~mrickma/ekiga/ekiga-setup-3.2.5-release.exe
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Brian West wrote:
I totally missed this at first... but 95 wouldn't dynamically work because its not 96-127
/b
The way to CELT plugin registers should be ok, the code is based on the Speex plugin. Opal tries to assign a number in the dynamic range first and if nothing is free in that area, goes backwards starting at 95 to find an empty spot (opal/mediafmt.cxx - OpalMediaFormatInternal::OpalMediaFormatInternal()). Maybe some of the other codecs is registering a lot of formats without the shared flag set and using up all dynamic IDs, or there's a problem somewhere in the ID handling code.
participants (4)
-
Brian West
-
Helmut Kuper
-
Michael Jerris
-
Stefan Knoblich