2010-07-01 5 views
2

나는 SIP UAC를 작성했으며, UAS의 수신 메시지 반복을 감지하고 무시하는 몇 가지 방법을 시도했지만 시도한 모든 접근 방식으로 문제가 발생했다. 문제는 모든 메시지가 동일한 호출을하는 것과 동일한 서명이 있고 모든 메시지 텍스트를 비교하는 것이 너무 많아서 이러한 반복 메시지를 감지하려고 할 때 메시지를 작성하는 매개 변수가 무엇인지 궁금합니다.SIP 메시지 반복을 감지하는 가장 좋은 방법은 무엇입니까?

UPDATE :

는 내가 서버를 빈 확인 응답을 전송하여 취급 수신 옵션에 문제가 있었다. (업데이트 : 잠시 후 내가 알아 차린 테스트 중에는 여전히 옵션을 요청하고 몇 초마다 몇 번씩 옵션 요청이 나옵니다. 따라서 잘못된 요청으로 응답을 시도하고 이제는 옵션 요청을 한 두 번만받습니다. 모든 등록/재 등록)

현재 내가 SessionInPogress의 메시지를 반복하고 여기에서 바쁘거나 사용할 수없는 것과 같은 여러 가지 오류 메시지가 표시됩니다. 이러한 메시지가 너무 많아서 내 로그를 엉망으로 만들었습니다.

어떻게 그 아이디어를 얻을 수 있습니까?

UPDATE :

private boolean compare(SIPMessage message1, SIPMessage message2) { 
    if (message1.getClass() != message2.getClass()) 
     return false; 
    if (message1.getCSeq().getSeqNumber() != message2.getCSeq().getSeqNumber()) 
     return false; 
    if (!message1.getCSeq().getMethod().equals(message2.getCSeq().getMethod())) 
     return false; 
    if (!message1.getCallId().equals(message2.getCallId())) 
     return false; 
    if (message1.getClass()==SIPResponse.class) 
     if(((SIPResponse)message1).getStatusCode()!=((SIPResponse)message2).getStatusCode()) 
      return false; 
    return true; 
} 

감사 :

나는 아마이 그것을 잘 작동,

다음

내가 사용하는 것입니다 내 문제를 해결할 다시 게시하기 전에 당신의 공예를 시도 할 것이다 , Adam.

+0

어떤 종류의 메시지입니까? 임시 응답? 최종 응답? UDP를 사용하고 있습니까? RFC 2543 UAS 또는 RFC 3261 UAS와 통화하고 있습니까? –

+0

응답 또는 요청 인 경우 실제로 중요합니까? 임시 또는 최종? 모든 메시지에 공통성이 낮아서 반복적 인 메시지를 식별 할 수 있습니까? – TacB0sS

+0

글쎄, 그것은 질문에 대답하는 데 도움이 :) 요청/응답 retransmissions 다르게 처리됩니다. –

답변

2

ChrisW의 답변보다 약간 복잡합니다.

먼저 트랜잭션 계층은 대부분의 재전송을 걸러냅니다. 이는 대부분의 경우 수신 된 메시지를 현재 트랜잭션 목록과 비교합니다. 트랜잭션이 발견되면 해당 트랜잭션은 대부분 RFC 3261, section 17의 다이어그램에 따라 재전송을 삼킨다. 예를 들어, Proceeding 상태의 UAC INVITE 트랜잭션은 지연된 재전송 된 INVITE를 삭제합니다.

일치 여부는 원격 스택에 따라 두 가지 방법 중 하나로 발생합니다. 그것이 RFC 3261 스택 (최상위 비아의 분기 매개 변수가 "z9hG4bK"로 시작하는 경우)이면 매우 간단합니다. Section 17.2.3은 전체 내용을 다룹니다.

이와 같이 일치하면 중복/재전송 된 옵션 (특정 문제로 언급)을 필터링합니다.OPTIONS 메시지는 대화 상자를 형성하지 않으므로 CSeq를 보면 작동하지 않습니다. 특히 UAS가 재전송이 아닌 5 개의 OPTIONS 요청을 보내는 경우 5 개의 OPTIONS 요청 (5 개의 비 -INITE 서버 트랜잭션)을 받게됩니다.

비 INVITE 트랜잭션에 대한 재전송 된 잠정적 응답은 트랜잭션 사용자 계층 또는 코어라고도하지만 처음 호출 이외의 경우에는 최종 응답으로 전달됩니다. (다시 말하면, 해당 트랜잭션에 대한 FSM을 구현함으로써 간단히 알 수 있습니다. 최종 응답은 Completed 상태에있는 UAC 비 -INVITE 트랜잭션을 추가 응답을 삭제합니다.

그런 다음 Transaction-User 계층은 일반적으로 INVITE 트랜잭션에 대해 여러 응답 받기

UAS가 적어도 INVITE의 경우 여러 개의 183을 보내는 것이 정상입니다. 예를 들어, 적어도 재전송을 끄기 위해 100을 보낼 수 있습니다 (적어도 신뢰할 수없는 전송 이상). 183s, 180s, 183s, 마지막으로 200s (신뢰할 수없는 운송 수단의 경우)

트랜잭션 계층이 프록시와 사용자 에이전트가 응답을 다르게 처리하기 때문에 이러한 모든 응답을 올리십시오.

이 레벨에서는 응답이 재전송되지 않습니다. 나는 말해야한다 : UAS는 재전송 로직을 사용하여 잠정적 인 응답을 보낸다 (RFC 3262을 구현하지 않는 한). INVITE에 대한 200 OK는 UAC 트랜잭션을 파괴하기 때문에 다시 보내집니다. 적시에 ACK를 보내 재전송을 피할 수 있습니다.

+0

오류 응답을받은 후 UAC와 UAS 사이의 몇 가지 메시지로 내 질문을 업데이트했습니다. 4xx 및 5xx도 마찬가지입니다. – TacB0sS

+0

설명을 사용하여 구현을 시작했습니다. – TacB0sS

0

나는

(예 : "INVITE") 메시지가 중복/동일, 경우의 ...

  • CSEQ
  • 전화-ID
  • 및 방법 이름이라고 생각 ... 값은 다른 메시지의 값과 일치합니다.

    응답 메시지는 응답하는 요청과 동일한 CSeq를가집니다. 하나의 요청에 여러 개의 잠정적이지만 중복되지 않은 응답 (예 : RINGING 다음에 OK)이 표시됩니다.

+0

메시지를 반복하는 유일한 기준은 ...입니까? 색인 및 방법, 통화 ID는 어떤 요인도 아니어야합니까? – TacB0sS

+0

@ TacB0sS http://www.ietf.org/rfc/rfc3261.txt의 36 ~ 38 페이지에 따르면 CSeq는 대화 상자 내에서 고유하며 Call-ID는 메시지 그룹 (또는 대화 상자)을 식별합니다. – ChrisW

+0

그것은 그것보다 복잡합니다. 나는 RSN의 답을 얻을거야. –

관련 문제