[OpenSIPS-Users] retransmission causes new session
Douglas Lane
doug at wd.co.za
Wed May 12 21:19:40 CEST 2010
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.
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
>>
>>
>>
>
>
More information about the Users
mailing list