What would be the best implementation to detect repeating SIP message?

Question

Hi,

I've wrote a SIP UAC, and I've tried a few ways to detect and ignore repeating incoming messages from the UAS, but with every approach I tried, something went wrong, my problem is that all the messages that has to do with the same call has the same signature, and to compare all of the message text is too much, so I was wondering, what parameter that compose a message should I be looking at when trying to detect these repeating messages.

UPDATE:

I had a problem with an incoming Options, which I handled with sending the server an empty Ok response. (Update: after a while of testing I noticed, that I still get every now and then I get another Options request, few every few second, so I try responding with a Bad request, and now I only get the Options request once/twice every registration/reregistration)

currently I have repeating messages of SessionInPogress, and different error messages such as busy here, and unavailable, I get so many of these, and it messes my log up, I would like to filter them.

any idea how to achieve that?

UPDATE:

I'll try your Technics before posting back, perhaps this would solve my problems

Here is what I used, it works nicely:

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;
}

Thanks, Adam.

Answer 1

I think that a message is duplicate/identical, if its ...

• Cseq
• Call-ID
• and method name (e.g. "INVITE")

... values match that of another message.

Note that a response message has the same CSeq as the request to which it's responding; and, that a single request you get several, provisional, but non-duplicate responses (e.g. RINGING followed by OK).

Answer 2

It's a bit more complicated than ChrisW's answer.

First, the transaction layer filters out most retransmissions. It does this by, for most things, comparing the received message against a list of current transactions. If a transaction's found, that transaction will mostly swallow retransmissions as per the diagrams in RFC 3261, section 17. For instance, a UAC INVITE transaction in the Proceeding state will drop a delayed retransmitted INVITE.

Matching takes place in one of two ways, depending on the remote stack. If it's an RFC 3261 stack (the branch parameter on the topmost Via starts with "z9hG4bK") then things are fairly straightforward. Section 17.2.3 covers the full details.

Matching like this will filter out duplicate/retransmitted OPTIONS (which you mention as a particular problem). OPTIONS messages don't form dialogs, so looking at CSeq won't work. In particular, if the UAS sends out five OPTIONS requests which aren't just retransmissions, you'll get five OPTIONS requests (and five non-INVITE server transactions).

Retransmitted provisional responses to a non-INVITE transaction are passed up to the Transaction-User layer, or core as it's sometimes called, but other than the first one, final responses are not. (Again, you get this simply by implementing the FSM for that transaction - a final response puts a UAC non-INVITE transaction in the Completed state, which drops any further responses.

After that, the Transaction-User layer will typically receive multiple responses for INVITE transactions.

It's perfectly normal for a UAS to send multiple 183s, at least for an INVITE. For instance it might immediately send a 100 to quench your retransmissions (over unreliable transports at least), then a few 183s, a 180, maybe some more 183s, and finally a 200 (or more, for unreliable transports).

It's important that the transaction layer hands up all these responses because proxies and user agents handle the responses differently.

At this level the responses aren't, in a way, retransmitted. I should say: a UAS doesn't use retransmission logic to send loads of provisional responses (unless it implements RFC 3262). 200 OKs to INVITEs are resent because they destroy the UAC transaction. You can avoid their retransmission by sending your ACKs timeously.