[OpenSIPS-Users] retransmission causes new session

[Douglas Lane]

Hi Bogdan,

My proxy auth code on the INVITE looks like this:

                         if(!proxy_authorize("", "subscriber"))
                         {

                                 xlog("L_INFO", "Proxy authentication 
failed - M=$rm RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n");
                                 proxy_challenge("", "0");
                                 exit;
                         }

                         if(!db_check_from())
                         {

                                 xlog("L_INFO", "Spoofed From-URI 
detected - M=$rm RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n");
                                 sl_send_reply("603", "Spoofed From-URI 
Detected");
                                 exit;
                         }

So could I be correct in saying that is I add t_newtran()  before the 
if(!proxy_authorize(...)) call, it should fix up the retransmission issues?

Also would the same apply for a REGISTER attempt?

Thanks
Doug


On 2010/05/12 10:50 AM, Bogdan-Andrei Iancu wrote:
> 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
>>
>>
>>      
>
>