出租車jt/t 905協議，是jt/t 808協議的一個變種，設計者將部標808協議拿過來，並不是單純的增加網約車相關的指令集，而且對原有的指令如定位0×0200指令也進行了修改，經過一通劇烈的修改，面目全非，協議已經與808協議本身並不兼容，這是比較失敗的地方，保持兼容性，才能使協議更加讓硬件和網約車平台接受和開發推廣，沒有經驗的協議設計者和標准制定者高高在上不考慮兼容性，給硬件廠家和平台開發人員造成很大的麻煩，也增加了成本。
部標1078協議是在部標808協議的基礎上，繼續增加指令，並不修改原有的指令，這樣也使得協議更加容易讓人接受和推廣。
在部標1078視頻協議推出后，部標905終端就相對比較尷尬，以前的jt/t905協議本身沒有視頻指令和功能，很多廠家就集成基於私有協議的視頻模塊，五花八門，現在部標視頻標准一出，就面臨一個視頻標准統一的問題，原有的私有協議需要拋棄掉，修改成1078協議。但是1078協議是基於808協議的指令集，並不是基於905協議的指令集，本質上不是為905協議終端設備設計的。這就需要硬件和平台后端都需要做一定的工作，才能讓一個部標905網約車平台具備1078視頻功能。
一種比較理想的方案是深度集成，將1078協議中的指令集添加到905的指令集中，這樣使得jt905協協議賦予了視頻指令交互的能力，這種方案好的地方在於它仍然保持了一個指令通道，一個視頻數據通道，但是需要硬件開發人員一定的工作量。
另一種方案就是粗暴簡單，905模塊和1078模塊，分別與平台后端建立獨立的指令交互的連接，基於jt/t905的連接只交互905的指令，1078的連接只交互1078的指令，各自為戰，這種方案的優勢在於硬件拿來即用，不需要過多的開發，但是后遺症很多，苦了平台開發人員，設計兩個指令網關，一個是905指令網關，一個是1078指令網關，在平台上下發指令的時候，需要判斷指令類型，來決定指令的走向，是下給905網關，還是下給1078網關。
還有一個麻煩的地方，就是上線和離線不同步，比如1078連接斷開了，而905的連接還是正常，這就在前端界面的上線狀態上給用戶容易造成困惑，有時候905明明在線，但是視頻指令卻下發失敗，無法看到視頻。
在上級平台對接方面，也是麻煩，首先要基於905協議第四部分中數據交互與共享單元中的數據交換協議（是809協議的變種，做了修改，不兼容809），開發轉發服務器，將數據轉發給出租車監管平台。
但是還要基於原有的809協議，開發轉發服務器，將數據轉發給省級監管平台。
這樣開放下來，一個網約車后端，就有N多的服務器模塊了，主要有：
1）905協議網關；
2）1078協議網關；
3）基於905協議數據交換部分的上級平台轉發服務器；
4）基於809協議的轉發服務器；
5）基於905 UDP升級協議的的升級服務器；
