Has anyone tried the IP 6000 conference phone? I need to purchase in the next while, and am weighing vs the IP 4000.
Supposedly the advantages of the IP 6000 are:
- longer mic range (12ft rather than 10ft)
- PoE built-in (rather than use $100 add-on)
- "Polycom HD voice" - same feature on IP 650/660.
Does anyone hear a difference with this "HD voice", or is it just hype?
Thanks,
Ross
HD voice is a wideband CODEC named g.722. Conventional TDM ulaw CODEC is 3.3Khz wide (300-3000Hz). G.722 is 7Khz wide and has expanded dynamic range (difference between the loudest and softest sounds).
Let me put this simply. G.722 is the difference between AM and FM, it is outstanding. On conference calls and even general speech the amount of information that can be obtained by subtle cues in voice is very tangible.
To my knowledge no provider supports g.722. It would be meaningless anyway since it was simply be transcoded down to traditional TDM 3.3Khz voice.
Where this technology shines is two remote offices with g.722 conference phones. You will be blown away.
Asterisk 1.4 (the current build for trix 2.6.x) supports g.722 between endpoints. It will not transcode g.722 to another codec. If the entire call path does not support g.722 then another codec will be negotiated.
Sounds complicated but it isn't. In the extension config and in any IAX trunks simply have allow=g.722 and you are off to the races.
Let me know what you think and I can fill you in on some subtle points that are required to interoperate peacefully with non-g.7ss capable endpoints.
Scott
Scott
aka "Skyking"
Very interesting. Trained as an EE, I can understand the benefits of a higher sampling rate, although 7kHz is a bit of overkill given the typical range of voice.
As to whether g.722 will be useful for my particular office, it's hard to forecast.
Question: OK, so I'm using a conference phone that is g.722 capable (IP 6000), in a conference call with phones over TDM plus inter-office phones (e.g. IP 650) that are also g.722 capable. Do the g.722 users get the benefits of hearing each other in g.722 while ulaw users hear others and are heard by others in ulaw? Or would it be ulaw for everyone all around?
I ask, because our conferences may consist of many home office users, but somebody is inevitably on a cell.
Also, getting back to the original question: is the IP 6000 supported or usable with trixbox CE?
Question: OK, so I'm using a conference phone that is g.722 capable (IP 6000), in a conference call with phones over TDM plus inter-office phones (e.g. IP 650) that are also g.722 capable. Do the g.722 users get the benefits of hearing each other in g.722 while ulaw users hear others and are heard by others in ulaw? Or would it be ulaw for everyone all around?
No that does not work today, until Asterisk (more importantly channel_sip) can transcode g.722 we are stuck.
It's actually worse than that, Asterisk will not reinvite participants who offered this CODEC so you can't even originate the call in g.722. You have to setup a separate extension as another line appearance with uLaw for calls to non g.722 users.
I am sure this will change, when is anyone's guess.
Scott
Scott
aka "Skyking"
Let me know what you think and I can fill you in on some subtle points that are required to interoperate peacefully with non-g.7ss capable endpoints.
OK, I'll bite. What are some subtle points?
The subtle point I brought out was in the second posting. You have to have two line appearances on each phone. One for calling non g.722 capable endpoints and the other for g.722 endpoints.
Scott
aka "Skyking"
Even for non-conferencing?
Yes, unless you turn off g.722.
Asterisk can not transcode (convert) g.722
Scott
aka "Skyking"
So, even for non-conference use, I have to configure a separate call appearance on every g.722-capable extension with allow=g.722.
Thers is still something I don't understand then from one of your previous posts:
If the entire call path does not support g.722 then another codec will be negotiated.
If codecs can be negotiated, for non-conferencing purposes why can't I just configure a single call appearance on the g.722-capable phone, and allow * to negotiate ulaw when necessary?
If codecs can be negotiated, for non-conferencing purposes why can't I just configure a single call appearance on the g.722-capable phone, and allow * to negotiate ulaw when necessary?
I don't have the time to do a SIP call flow for you so the best I can do is talk you through it. Let me know if this makes sense.
A two party call on Asterisk has two call legs. Asterisk is "in the middle". If the CODEC's are different Asterisk transcodes as needed.
So:
Scott
aka "Skyking"
OK, so then in your example, can UA one automatically request a different codec? e.g. g.711
OK, so then in your example, can UA one automatically request a different codec? e.g. g.711
Yes and that is what you define in the second line appearance. So you have two line appearances, one with g.722 as the preferred CODEC for calling other g.722 UA's the othe g.711 for everything else.
That is why I limit it to conference to conference facility only. It is too much to ask users to remember the capabilities of the people they are calling.
Scott
Scott
aka "Skyking"
Sorry if I seem dense, but there is something I still don't get:
If switching codecs is *automatic*, then why is the second line appearance necessary?
Wait: is it because each line appearance can only be associated with a single codec, and auto-switching line appearances is a proxy for auto-switching codecs?
Sorry if I seem dense, but there is something I still don't get:
No it's because Asterisk does not poll the other UA's for their CODEC capability before initiating the media stream then invite based on the lowest common denominator.
Scott
aka "Skyking"
So negotiating the codec is NOT automatic. Correct?
If so, then there really is no negotiation in the usual sense of the word.
I think the IP6000 should be cheaper than the 4000. It looks better too. http://www.zipdx.com offers 722/HD conferencing.
You should buy the IP6000 for future planning as Polycom will stop selling and supporting the 4000 before the 6000. You can easily turn off the 722 until the world is ready for it. The 4000 is pretty old school now.
A) Why would the upgraded model be cheaper? From what I've seen, it costs about $900, or $250 more than the IP 4000.
B) In the big scheme of things, I'm fine with paying a little extra for future capability. The issue for me though is: will it work with trixbox?
C) Regarding ZipDX, I'm not sure I understand what they offer that I can't do with IAX trunking. I understand that trixbox doesn't do call-out, which is a shame. Also, if you're conferencing with ad hoc parties, ZipDX saves you from having to set up IAX trunking each time.
So negotiating the codec is NOT automatic. Correct?
...Removing splinters from my head from beating against wall
Asterisk negotiates the CODEC's individually for each leg of the call
UA 1 Asterisk UA 2
Session 1 Session 2
Each session is independent. Only the audio is connected via the RTP crossbar. G.722 is a "pass through" only CODEC so if both US's don't support it Asterisk can't bridge the audio.
B) In the big scheme of things, I'm fine with paying a little extra for future capability. The issue for me though is: will it work with trixbox?
This is a good strategy. You can use the device with the primary line appearance as g.711. If you happen to purchase a second one you can create a separate extension to play with the g.722. Once Asterisk supports g.722 fully you can then make that your preferred CODEC.
Scott
aka "Skyking"
a. Yes the MSRP is cheaper on the IP6000. The IP7000 is really the "upgraded" model as it will have more features. The 6000 is just an updated 4000. Right now the internet prices may be better for the 4000 as they have been around longer and demand is lower. The MSRP for the 4000 is 1099 and the 6000 is 899
b. I don't see any reason it won't work with TB as long as you are running the proper version of Polycom software (which should be out real soon) You won't be able to get the 6000 until late May I think.
c. ZIP DX can do hosted 722 conferencing. I'm not sure what you can do with a IAX trunk in comparison, but they offer full 722 3rd party conferencing.
Each session is independent. Only the audio is connected via the RTP crossbar. G.722 is a "pass through" only CODEC so if both US's don't support it Asterisk can't bridge the audio.
I get that part. What I want to know is: what happens next? Does Asterisk do nothing, even though it has failed (and it should know it fails, so this would be a pretty big flaw)? Or does it automatically negotiate another codec?
If the former is true, I see why a second call appearance configured with another codec is necessary. We'd effectively be using a 2nd call appearance as a proxy for selecting another codec, as I said earlier.
If the latter is true, and Asterisk nicely connects everyone with g.711 in the 2nd attempt, I don't see why having users manually select a 2nd call appearance for g.711 is necessary, since Asterisk does the work for them by falling back automatically.
Thanks for your patience,
Ross
Asterisk clearly does not support g.722 except for pass through mode. It is not going to store all the legs of the call, tear them all down then reinvite them back with the next CODEC in the list.
It could do anything from nothing to a kernel panic.
SInce I have not tried I can't tell you what it would do.
Scott
Scott
aka "Skyking"
Ross, I banged my head against Asterisk codec negotiation very severely a year ago. I was trying to get phones *inside* a high-speed local network to use ulaw and use G729 when they left the network. In theory, this is possible. In practice the Asterisk codec negotiation is deeply flawed. This is somewhat analogous to what should "obviously" happen here (though this has the added twist that Asterisk _can't_ transcode even if it wanted to. I wrote about this back here: http://www.trixbox.org/forums/trixbox-forums/open-discussion/code... in case you'd like to get splinters also.
Fwiw, I did eventually find a long bug/ticket/enhancement request on this topic in the Asterisk database. It confirmed my assumptions in my post above. Unfortunately I don't still have the reference - I'd love to know if codec negotiation has improved. It was particularly frustrating to read the ticket because a solution kept getting contributed and updated with each release, but never quite in time to be adopted. It is of course a big change ... but much needed imho.
cheers, michael
Mike,
That thread is old, I am surprised nobody responded.
If you deny all codec accept g.711 on the extensions and do the same on the trunk except for g.729 and set canreinvite=no you will have exactly what you are looking for.
Scott
Scott
aka "Skyking"
I just wanted to take the time to thank Scott for diligently responding until I understood the issue, even when we seemed to be talking past one another.
Not a problem, the only way I learn is by helping others.
Gives me a bit of clarity and a break from my insane schedule.
Scott
Scott
aka "Skyking"
Thanks for the reply Scott. I'm intrigued ... Do you know if this new behaviour works only with Asterisk 1.4 or 1.2 also? (All my installations are 1.2 only, but this might be enough have me upgrade a couple of them...)
cheers, michael
g.722 is only supported in the 1.4 channel_sip
Scott
aka "Skyking"
I've realized G.722 to G.711 call at asterisk. I have realized G.722 to G.711, G.722 to G.722(NAT), G.722 conference, But with polycom HD voice still have some issue. The sound is choppy when G.722 to E1, I think polycom must have some private codec. When I use other company's phone with G.722 codec, everything is ok. No problem.
Member Since:
2007-12-23