[OpenSIPS-Users] retransmission causes new session

[Douglas Lane]

Hi Guys,

I've been looking into my CDRTool issue of late with a customer, and 
I've noticed a trend to incorrectly captured billing.

What currently happens is the following:

Customer ------- (INVITE) -----------------> OpenSIPS (CSeq 102)
Customer <----- (100 Trying) ---------------- OpenSIPS
Customer <----- (407 Proxy Auth) ---------- OpenSIPS
Customer ------- (ACK) ---------------------> OpenSIPS
Customer ------- (INVITE with Auth) ----> OpenSIPS (CSeq 103)
Customer <----- (100 Trying) ---------------- OpenSIPS
Customer <----- (183 Session Progress) ---- OpenSIPS

And then this happens:

Customer ------- (INVITE with Auth) ----> OpenSIPS (CSeq 103)

According to Wireshark, this frame is an exact copy of the previous 
INVITE with Auth frame - so I can only assume its a retransmission from 
the customer's point of view (maybe our trying and session progress 
didn't get to them).

Anyway, then this causes a whole load of trouble, as our OpenSIPS will 
then do the following:

Customer <----- (100 Trying) ---------------- OpenSIPS
Customer <----- (407 Proxy Auth) ---------- OpenSIPS
Customer ------- (ACK) ---------------------> OpenSIPS
Customer ------- (INVITE with Auth) ----> OpenSIPS (CSeq 104)
Customer <----- (100 Trying) ---------------- OpenSIPS

The next two frames are relayied from our Asterisk server that is doing 
the PSTN connectivity
Customer <----- (491 Request Pending) ---- OpenSIPS (CSeq 104)
Customer <----- (491 Request Pending) ---- OpenSIPS (Retransmission of 
the above according to wireshark)
Customer ------- (ACK) ---------------------> OpenSIPS

Now the disaster is the fact that the first intial invite sets up the 
mediaproxy server for the relay, on CSeq 103. Then CSeq 104 comes in, 
and mediaproxy updates itself, however, the 491 cancels this 
transaction, and then mediaproxy ignores any updates for CSeq 103 - 
including when our Asterisk server receives an ANSWER and sends down the 
200 OK to the customer

While our radius server gets the billing information correctly, 
call-control sees the call as being cancelled, and then calls 
DebitBalance for a sum of 0 (as the call was not answered)m meanwhile 
radius is busy ticking over with rating.

Anyway, what I don't understand is I was under the impression OpenSIPS 
should be able to notice the difference between a new invite, and a 
retransmission and handle it accordingly. I'm assuming there is 
something wrong with my logic, so I was hoping someone could point me in 
the right direction of where to look and start debugging.

I look forward to your assistance.

Thanks
Doug