[OpenSIPS-Users] retransmission causes new session

[Bogdan-Andrei Iancu]

Hi Douglas,

yes, that is correct - but first also check disabling the auth option - 
just a POC that my assumption is right.

Regards,
Bogdan

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


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