HKBN 2B Obi110 or OBi100 settings
baor:
Quote from: obi-support2 on April 12, 2011, 09:28:59 am
baor,
To answer your question regarding why bridging HKBN and GV has no audio...
From you previous HKBN call status, you were using G729 with HKBN.
However GV can only do G711U. To make this work, make sure your call to
HKBN is using G711U (you have to force it by disabling G729 and G726 codecs in the
codec profile). If HKBN indeed does not support G7111U codec at all, then there
is not way to bridge it with GV at the moment.
About the call has no audio on both ends (in your words "dead" or "cutoff") after 10 min, I cannot figure it out yet. All I can see is the OBi still sending out packets (tx packets increasing), but
no packets are coming from the server (rx packets not increasing). You can try hook flash, and hook flash again to see if the incoming packets will resume.
Again, a complete debug log will help with SIP Debug Options enabled will help us diagnose the problem further. If there is a size limit in posting, please email to support@obihai.com.
Not all call can be done at G711U. I dunno why. Some calls were using G711U. Most of them were 711A or 729. If disabling 711A and 729, "503 error" would result.
Can this be fixed in future firmware result, ie bridging to CODEC other than 711U?
obi-support2:
baor,
Fundamentally, the OBi110 cannot solve this problem completely b/c transcoding btw different codecs may be prohibitedly complex in general. And IMO, it's also unlikely GV will support g729 in the near future.
I have put in a request to add support for G711A for GV; and hopefully that will alleviate this situation.
baor:
Quote from: obi-support2 on April 14, 2011, 01:58:23 pm
baor,
Fundamentally, the OBi110 cannot solve this problem completely b/c transcoding btw different codecs may be prohibitedly complex in general. And IMO, it's also unlikely GV will support g729 in the near future.
I have put in a request to add support for G711A for GV; and hopefully that will alleviate this situation.
That means your bridging function is unpredictable......
There are 2 ends here.
1. Calling to Obi1x0
2. Obi1x0 bridging to Receiving end
Is route 1 fixed in what codec is used?
obi-support2:
Quite the contrary. The unit will try to match both call-legs wherever possible.
You just picked a case that is not possible to match at the moment.
baor:
Quote from: obi-support2 on April 14, 2011, 08:56:19 pm
Quite the contrary. The unit will try to match both call-legs wherever possible.
You just picked a case that is not possible to match at the moment.
Good to hear it is still possible.
Thanks!
Can I request a function?
Can the call history retain those call status information, e.g. codec, packet tx/rx, packet loss, etc???
Navigation
[0] Message Index
[#] Next page
[*] Previous page