[OpenSIPS-Users] Cancel branch before failover on timeout

[Ronald Cepres]

Bogdan,

Thanks for the advice. Although it might be a long shot, I hope acc module
can handle something like this in the future. I guess I'll just try to
adjust/increase the fr_inv_timer_avp value for now to minimize this
scenario.

Cheers!


On Thu, Jul 11, 2013 at 8:24 PM, Bogdan-Andrei Iancu <bogdan at opensips.org>wrote:

> **
> Hi Ronald,
>
> I wouldn't go so far - even if you get 2 records for the transaction based
> accounting, the values will be mixed.
>
> Regards,
>
> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com
>
>
> On 07/10/2013 03:08 PM, Ronald Cepres wrote:
>
> Bogdan,
>
>  I am currently using CDR based. Does it mean that if I use transaction
> based, we will have more accurate resulting CDRs?
>
>  Thanks.
>
>
> On Mon, Jul 8, 2013 at 10:05 PM, Bogdan-Andrei Iancu <bogdan at opensips.org>wrote:
>
>>  Hi Ronald,
>>
>> I never experienced such race (with multiple 200 oks on different
>> branches)....But depending on what kind of accounting you do:
>>  - transaction based = you will get 2 START records and 2 STOP records,
>> but with different TO tags....
>>  - cdr based = you will get the values of the last 200 OK (which will
>> overwrite the values of the first one)..
>>
>> I guess the ACC module was never designed to deal with such scenarios.
>>
>> Regards,
>>
>> Bogdan-Andrei Iancu
>> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com
>>
>>
>>   On 07/06/2013 02:25 AM, Ronald Cepres wrote:
>>
>> Bogdan,
>>
>>  Understood, and thanks for the info.
>>
>>  However, I have some concerns with regards to the resulting CDR using
>> the acc and drouting modules. I think if both GWs sent 200 OK at the same
>> time, it would result in a CDR with the values of AVPs specified by
>> carrier_id_avp and gw_id_avp drouting parameters set only to GW2. Also, if
>> GW1 is the last GW in the gwlist and this type of race condition happens,
>> the value of the AVPs will be set to blank.
>>
>>
>>  On Fri, Jul 5, 2013 at 2:15 AM, Bogdan-Andrei Iancu <bogdan at opensips.org
>> > wrote:
>>
>>>  Hello Ronald,
>>>
>>> If the first GW sent any reply before the timeout, than OpenSIPS will
>>> cancel it before hitting the failure route. If no reply at all sent by GW1,
>>> OpenSIPS will hit the failure route on timeout without canceling. If after
>>> this point (call send to GW2) first GW sends a reply :
>>>     1) if a provisional reply (<200), it will be canceled on the spot
>>>     2) if a 200 ok reply -> it will be accepted and fwd to calling device
>>>         a) if the GW2 did not send a 200 OK, it will be canceled
>>>         b) if GW2 also sent a 200 OK in the same time, both 200 OK will
>>> be sent to calling device and it that device will decide what call to keep
>>>
>>> Regards,
>>>
>>> Bogdan-Andrei Iancu
>>> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com
>>>
>>>
>>>   On 07/04/2013 07:41 PM, Ronald Cepres wrote:
>>>
>>> Bogdan,
>>>
>>> Thanks for the informative reply.
>>>
>>> What I really want to solve is a problem I encounter when the first GW
>>> doesnt respond after a defined timeout then Opensips does failover to next
>>> GW. A few seconds after the call is routed to second  GW, the first GW
>>> responds with 200 OK, which may cause problems. It seems that the first GW
>>> has a slow response time.
>>>
>>> The solution I am thinking of to prevent this is to send a cancel to the
>>> first GW before doing failover to next gateway. Does this make sense or is
>>> there a better solution?
>>>
>>> Thanks.
>>>
>>> -Ronald
>>> On Jul 4, 2013 11:58 PM, "Bogdan-Andrei Iancu" <bogdan at opensips.org>
>>> wrote:
>>>
>>>>  Hello Ronald,
>>>>
>>>> When you hit the failure route, there is no ongoing branch left
>>>> (doesn't matter how many you previously created) - so you should not worry
>>>> about this.
>>>>
>>>> By SIP definition, a transaction fails (and OpenSIPS gets into failure
>>>> route) only when all branches failed.
>>>>
>>>> Regards,
>>>>
>>>> Bogdan-Andrei Iancu
>>>> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com
>>>>
>>>>
>>>> On 07/03/2013 10:43 PM, Ronald Cepres wrote:
>>>>
>>>> Hi all,
>>>>
>>>>  Is there a way I can cancel a pending branch before doing a fail-over
>>>> to next gateway (due to timeout from previous gateway)? This way I can make
>>>> sure that the call to the previous gateway will not go through anymore
>>>> after fail-over to the next gateway, thus preventing us "double-charged"
>>>> situations if the previous gateway and the new gateway both answered the
>>>> call.
>>>>
>>>>  Thanks in advance.
>>>>
>>>>
>>>>  --
>>>>
>>>> Regards,
>>>>
>>>>  Ronald
>>>>
>>>>
>>>> _______________________________________________
>>>> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>
>>>>
>>
>>
>>  --
>>
>> Regards,
>>
>>  Ronald Cepres
>>
>>
>
>
>  --
>
> Ronald Cepres
> Network Operations Center
> Net Voip Communications, Inc.
>
>
> This message contains confidential information and is intended only
> for the individual named. If you are not the named addressee you
> should not disseminate, distribute or copy this e-mail. Please notify
> the sender immediately by e-mail if you have received this e-mail by
> mistake and delete this e-mail from your system. E-mail transmission
> cannot be guaranteed to be secure or error-free as information could
> be intercepted, corrupted, lost, destroyed, arrive late or incomplete,
> or contain viruses. The sender therefore does not accept liability for
> any errors or omissions in the contents of this message, which arise
> as a result of e-mail transmission. If verification is required please
> request a hard-copy version. Net Voip Communications, Inc., 2721
> Forsyth Rd #256, Winter park, FL 32792. www.netvoipcommunications.com
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>


-- 

Regards,

Ronald Cepres
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20130712/f6bb4f82/attachment.htm>