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 _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
