剛巧小弟這幾天正向Sipura 反應一些問題, 其中也提到了Codec 的限制, 您的說明適時的解答了小弟的疑惑, 以下節錄自SipuraSPA User Guide:
3.4.5.3. Audio Settings
A codec resource is considered as allocated if it has been included in the SDP codec list of an active call, even though it eventually may not be the one chosen for the connection. So, if the G.729a codec is enabled and included in the codec list, that resource is tied up until the end of the call whether or not the call actually uses G.729a. If the G729a resource is already allocated and since only one G.729a resource is allowed per SPA, no other low-bit-rate codec may be allocated for subsequent calls; the only choices are G711a and G711u. On the other hand, two G.723.1/G.726 resources are available per SPA. Therefore it is important to disable the use of G.729a in order to guarantee the support of 2 simultaneous G.723/G.726 codec.
此外, SPA FAQ Section 4.2也提到,
2: Do you support G723 on both channels simultaneously?
A: Yes, you have to set "G729 enable" to No
坦白說, 這兩段小弟已經看過好幾遍, 一直到最近才有了比較深刻的體認, 或許是因為Sipura 舊產品使用了非語音專用的ESS 晶片, 受限於ESS 的運算能力, 最多只能同時支援一路G.729 加三路G.711u/a 或兩路G.723/G.726 加兩路G.711u/a, 如果兩線電話都以G.729 優先, 那麼第一通電話沒問題, 第二通電話就只能選G.711u/a, 受到此限制, 所以小弟先前才會建議Line2 不妨接傳真, 然而如果想要同時利用兩線電話, 那麼就得使用Force G723 Code "*02723" 和Force G726r16 Code "*0272616" 等專屬指令, 如此一來就不用非得預先禁用G.729 不可, 但是話說回來, 有誰會把打電話搞得這麼複雜? 也就是說除了SPA-210x 支援兩路G.729 之外, 其他系列並不適合當作兩線電話使用, 除非您的上傳頻寬夠大, 但是電話另一頭的上傳頻寬也得夠大才行
小弟再一次挖掘Codec 的協調過程, 但還是看得迷迷糊糊, 以SPA-2000 和X-Pro 為例, 雙方都支援G.729 和G.711u, 小弟令SPA-2000 以G.729 優先, X-Pro 以G.711u 優先, "Use Remote Preferred Codec as Local Preferred Codec: Yes", 則不論誰打給誰, 最終雙方都會採用G.729, 這樣的結果, 小弟實在看不出來其中的邏輯為何? 究竟最終所採用的Codec 是如何協調出來的? 觀看SPA-2000 作為被呼叫者或許還比較容易, 例如其回答是:
m=audio 48756 RTP/AVP 18 100 101
a=rtpmap:18 G729a/8000
a=rtpmap:100 NSE/8000
a=rtpmap:101 telephone-event/8000
很乾脆, 除了G.729 之外, 沒的選, 小弟不瞭解為何SPA-2000 不以X-Pro 的Codec 順序為準? RFC4566 似乎也沒有提到這一點,
5.14. Media Descriptions ("m=")
m=<media> <port>/<number of ports> <proto> <fmt> ...
If the <proto> sub-field is "RTP/AVP" or "RTP/SAVP" the <fmt> sub-fields contain RTP payload type numbers. When a list of payload type numbers is given, this implies that all of these payload formats MAY be used in the session, but the first of these formats SHOULD be used as the default format for the session.
看起來並未強調Codec 必須 "對稱(Symmetric)", 但是實務上好像是由被呼叫的一方決定最終的Preferred Codec, SipuraSPA 永遠會堅持己見, 而X-Pro 則可以配合對方, 小弟發現SipuraSPA v2.0.13g 的邏輯有一個重大缺失, 由於SipuraSPA 作為被呼叫方會決定最終的Preferred Codec, 假設Line1 已經採用G.723, Line2 便會自動剃除G.729(硬體限制), 所以原先排名第二的G.711u 反而成為Preferred Codec, 如果Line2 呼叫另一個SipuraSPA, 這時因為呼叫方不允許G.729, 因此被呼叫方的Preferred Codec 也會自動由G.711u 遞補, 所以雙方就會達成採用G.711u 的協議, 忽略了還有其他更好的選擇, 例如G.723/G.726
小弟同時也檢驗了ESS 晶片的極限, SPA-200x Line1/Line2 可以分別支援三方通話, 也就是可以有四個連線, 但是最多僅能有一路G.729 或兩路G.723/G726, 剩下的僅能支援G.711u/a, 所以三方通話必須很有技巧, 最佳情況是一線電話同時兩路G.723, 如果是一路G.729, 另一路G.711u, 那麼就得慎選通話對象, 也就是先打給距離遠連線慢者(G.729), 然後再打給距離近連線快者(G.711u), 這樣才能達到勉強可接受的效果, 如此限制重重, 只能說實在中看不中用
huangmax 兄見多識廣, 小弟孤陋寡聞, 只能在手邊有限的硬體中翻來覆去的研究, 沒想到硬體廠商竟然如此之多, 毋怪乎您會說市場才剛要興起, 原來大家已經虎視眈眈, 摩拳擦掌正要準備好好廝殺一番
書籤