Mobicents SIP錯誤響應處理 - 重新代理的正確方式是什麼？

Mobicents SIP servlet容器似乎用於處理錯誤響應，與我使用的其他SIP容器不同。該情況是：Mobicents SIP錯誤響應處理 - 重新代理的正確方式是什麼？

在收到的邀請，應用程序句柄和代理（監督），下游（所以它可以接收到邀請的答覆）。
收到來自初始目標的錯誤響應後，應用程序將代理服務器指向新目標（以非監督方式）。

這應該防止最初的錯誤響應傳播上游（因爲事務有一個新的目標）。但是，對於Mobicents容器，即使INVITE確實代理到新目標，最初接收到的錯誤響應仍會向上遊傳播。我相信這是Mobicents實現中的一個錯誤 - 但是如何解決這個問題呢？

代碼：

public void doInvite(SipServletRequest req) { 
    req.getProxy().proxyTo(req.getRequestURI()); 
} 

public void doError(SipServletResponse res) { 
    Proxy p = res.getProxy(); 
    p.setSupervised(false); 
    p.proxyTo(...); 
    // request is proxied, but the error response still passes 
    // upstream - the retargeting of the transaction (through 
    // proxying to a new destination ought to prevent that). 
}

來源

2015-05-29 Nathan Woodhouse

其他SIP容器，您在遷移您的應用程序？你在做順序或並行代理嗎？您收到哪個錯誤響應？您正在使用哪種版本的Mobicents SIP Servlets容器？ gist.github.com或pastebin.com上有完整的日誌嗎？

來源

2015-05-31 23:01:15 jeand

感謝您的回覆。使用最新的tomcat版本的mobicents sip servlets（3.0.564）。行爲因Avaya會話管理器，ubiquity sip應用服務器，thrupoint FAS而異，我認爲另一個我不記得名字。收到的錯誤響應是486，但我不認爲這很重要（任何導致應用程序創建新傳輸目標的不成功響應都應該導致服務器在評估新目標時不向上游傳播響應）。現在沒有便利的日誌可以在平板電腦上發佈atm。 Hth，並再次感謝您的回覆。 –

有關響應處理的上下文，請參閱rfc3261,16.7，應該立即向上遊傳播哪些響應，哪些「最佳」響應應該從服務器的響應上下文中上行等。 –

謝謝。您是否可以從一個SNAPSHOT重新生成https://mobicents.ci.cloudbees.com/job/MobicentsSipServlets-Release/lastSuccessfulBuild/artifact/以查看您是否仍面臨相同的行爲。如果你這樣做，請在https://github.com/Mobicents/RestComm/issues/new上打開一個問題。 – jeand

作爲一個純粹的代理解決方案，Mobicents正在做出將錯誤響應轉發回呼叫發起方的正確行爲，因此必須在呼叫方處理順序分岔的邏輯[基於錯誤代碼]。

但是，如果你想要mobicents的這種行爲，你需要爲mobicents運行B2BUA模式，它應該給你更多的粒度控制來決定獨立於2個呼叫支路[入口/出口]的行爲。

發起者爲INVITE [入口支路]獲取183呼叫進程，而順序重試可以在出口支路上處理，而不會在入口出現初始超時風險。

來源

2015-06-01 05:03:51 Rajesh

感謝您的回覆。我理解你的觀點，即從代理服務器代理接收的內容看來，服務器看起來表現正確。然而，在這種情況下，說服務器的行爲是正確的是不正確的。代理不應該代理每條消息，這只是一個例子（因爲監督事務的應用已經給容器提供了新的事務目標來嘗試）。 –

容器行爲是錯誤的，因爲它既通過代理邀請來嘗試新目標，也阻止了這些目標成功建立會話的可能性，因爲它允許被調用來接收收到的第一個錯誤響應。指出，作爲B2bua運行可以更好地控制sip會話，但如果代理行爲已修復，則不應該有必要。感謝那個建議，儘管如此，確實是爲了迴應:-) –

Mobicents SIP錯誤響應處理 - 重新代理的正確方式是什麼？

回答

相關問題