2012-06-14 3 views

답변

1

해당 추적이 단일 호출에 대한 것이면 매우 복잡한 것입니다. 약간의 시간을 들여보고 난 후에는 하나의 호출로 생각하지 않고 대신 몇 가지 다른 호출이 섞여 있다고 생각합니다. 10.10.20.1은 B2BUA (Back to Back User Agent)이며 다른 이벤트에 대한 응답으로 통화를 시작한다는 사실 때문에 복잡합니다. 원래 유인 전송로 보이는의 일환으로 10.10.10.3에서 UAC에 의해 생성 된 것 알림 요청에 대한 귀하의 질문에 관해서는

. REFER 요청은 전송의 시작입니다. (가) 요청에 통보 무엇을 암시 가입,하는 REFER 거래에 대해 생성됩니다 (http://tools.ietf.org/html/rfc3515을보고도 암시 적 트랜잭션을 억제 다루는 http://tools.ietf.org/html/rfc4488 참조)의 일부입니다. (가)는 NOTIFY 요구를 유인 전송 용

통화 레그 엔드 포인트가 전송을 성공적으로 처리되었다는 것을 나타낼 수있다. 이 경우 10.10.10.3의 사용자 에이전트는 NOTIFY 요청에 대한 응답을 얻을 때까지 전송을 수락하지 않는 것처럼 보입니다. 일반적으로 NOTIFY 요청은 호출 흐름을 제어하지 않는 이벤트를 상담원에게 알리기 때문에 일반적으로 비정상적인 동작입니다. 10.10.10.3이 NOTIFY 요청에 대한 503 응답을 받으면 마침내 10.10.20.4로 RTP를 보내기 시작합니다. 503은 오류 조건이므로 응답이 무엇인지 신경 쓰지 않아야하며 일반적으로 오류가 발생하기를 기다리는 모든 결과가 발생합니다.

+0

10.10.10.1 및 10.10.20.1은 다른 기계를 처리하는 동일한 기계이고 findme-followme 호출을 보여주기 때문에 더 복잡합니다. 10.10.10.1이 503을 더 일찍 보내거나 10.10.10.3이 RTP 이전에 응답을 기다리지 않아야합니까? 나는 당신이 말한 것에 따르면 그것이 10.10.10.3의 잘못이라고 생각합니다. RTP보다 전에 기다려서는 안되기 때문입니다. –

+0

UA가 RTP를 보낼 때 RFC3515가 실제로 쓰이지 않습니다. REFER 트랜잭션 (REFER가 받아 들여지거나 NOTIFY가 확인 된 후). 그러나 나는 REFER가 받아 들여진 후에 항상 그것을 구현했습니다. 귀하의 경우처럼 NOTIFY에 문제가 생길 수 있으며 통화 참가자는 죽은 공기에 매달릴 수 있습니다. 내가 너라면 SIP 서버 제조업체에 추적을 보내겠다. (별표가 없길 바란다.) – sipwiz