[OpenSIPS-Users] retransmission causes new session

Bogdan-Andrei Iancu bogdan at voice-system.ro
Thu May 13 18:50:29 CEST 2010


Hi Doug,

Douglas Lane wrote:
> Hi Bogdan,
>
> Thanks for all the assistance on this one. I did note that in the TM 
> docs you've mentioned that calling t_newtrans will not contain any 
> changes to the message there-after. So am I correct in saying that if I 
> call t_newtrans(), and then do something of the following, that the 
> below would not be saved into the transaction? What impact would this 
> have to the service?
>
> fix_nated_contact();
> append_hf("Billing-Party: $avp(s:billing_party)\r\n");
> append_hf("P-Asserted-Identity: $avp(s:cli)\r\n");
> append_hf("Remote-Party-ID: 
> $avp(s:cli);party=caller;privacy=none;screen=yes\r\n");
>
> and the finally call t_relay();
>
> I'm just trying to understand the impact that might occur should I add 
> t_newtrans() into my route logic to combat retransmissions.
>   

Indeed, t_newtran() will create the transaction (with a copy of the 
request) containing whatever changes were done at that point. Any 
further changes will not be saved into transaction.

What will be the impact ? well, it will not impact the processing of the 
first branch (first sending out of the request) as for the first branch 
(in main route) the t_relay() will use the current request for 
forwarding and not the copy from transaction. The copy of from the 
transaction will be used only for the next branches, when doing 
t_relay() again in failure route (for serial forking).

So, in your example, nothing will be changed - you will have the same 
experience . The difference will be in failure route where you will the 
request without the changed done after t_newtran().

Regards,
Bogdan
> I look forward to your reply.
>
> Thanks
> Doug
>
>
>
>
> On 2010/05/12 12:21 PM, Bogdan-Andrei Iancu wrote:
>   
>> 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
>>>
>>>
>>>      
>>>       
>>    
>>     
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>   


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




More information about the Users mailing list