[OpenSIPS-Users] retransmission causes new session

[Bogdan-Andrei Iancu]

Hi Douglas,

The issue may be related to the fact you have the nonce reusage check 
enabled but you do not process the auth requests in a stateful manner 
(like not doing t_newtran ) before auth part.

What is happening is that the the retransmission (due stateless 
processing in your script) hits again the auth code - here the auth is 
denied as the nonce was already used when doing auth for the original 
INVITE; so the retransmission will be differently handled than the 
original request.

Solutions:
    1) force statefull processing before auth code, so that TM will 
automatically handle retransmissions (use t_newtran)
    2) disable the nonce reusage check (this will reduce the security on 
the system) - see http://www.opensips.org/html/docs/modules/1.6.x/auth.html

Regards,
Bogdan

Douglas Lane wrote:
> 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
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>   


-- 
Bogdan-Andrei Iancu
www.voice-system.ro