[OpenSIPS-Users] OpenSIPS reseting issue with $T_fr_inv_timeout while forwarding
Răzvan Crainea
razvan at opensips.org
Fri Sep 1 04:55:01 EDT 2017
Hi, Ravi!
What do you mean "main route"? - the main route should be called only
once, when the INVITE comes from 1111. Are you looping the message back
to you?
PS: your message was detected to be too large - when you receive back
errors related to this, please revise them and then send the message in
a reasonable format.
Best regards,
Răzvan Crainea
OpenSIPS Developer
www.opensips-solutions.com
On 08/22/2017 05:15 PM, Ravi Patel wrote:
> Dear Bogdan,
>
> Apologize for the late reply.
>
> I was checking my logic and your suggestions in lab.
>
> Finally what my observation is,
> 1)
> I set an avp variable in main route. say for example: $avp(test)=0
>
> that I found it in failure_route and I am incrementing it by 1 and
> call forwarded to OpenSIPS again.
> Now in main route I am not able to get that variable, but yes when
> call went again to failure_route on failure case , I got its value 1
> and able to increment it by 1.
>
>
> 2)
> Second thing I found is:
>
> Say for example my call scenarios is:
> 1111 --> 2222 --Forward on No Answer--> 3333 --Foraward on No
> Answer--> 4444
>
> -----------------------
>
> 1111 -> 2222 : 2222 did not answer.
> in Failure_route, I set append_hf("test: 1\r\n"); and call forwarded
> to OpenSIPS again with $rU=3333.
>
> 2222 -> 3333 :
> In Main Route I am able to get its value.
> ***** Now I use remove_hf("test"); before forwarding call to 3333.
> 3333 did not pick up the call.
> call lands on failure_route.
> in Failure_route, I set append_hf("test: 2\r\n"); and call forwarded
> to OpenSIPS again with $rU=4444.
>
> 3333 -> 4444 :
> In Main Route when I fetch $hdr(test), I got the value 1 instead of 2.
> When I check its SIP trace, I found two headers with name "test" with
> values 1 and 2.
>
> ------------------
>
> So, remove_hf at ***** removes it from the OutBound SIP packet, but it
> is not removed at failure_route.
>
>
> I hope I explained well(It is a bit complex).
>
> Let me know if you need anything else to debug it.
>
> Regards,
> Ravi Patel
>
> On Wed, Aug 2, 2017 at 7:23 PM, Bogdan-Andrei Iancu
> <bogdan at opensips.org <mailto:bogdan at opensips.org>> wrote:
>
> Hi Ravi,
>
> I have to admit I did not understand your whole scenario, but you
> can read SIP headers in failure route, for sure. I think you are
> more fighting how the changes are done per-branch in OpenSIPS -
> whatever you change in request route (as changes) will be
> inherited by all branches/forks of that transaction. What you
> change in failure route will propagate only for that new branch.
>
> IF you want to count the number of serial forking attempts, better
> use an $avp(_name_) variable - you can init it to 0 in request
> route and increment it each time you do a new t_relay().
>
> Regards,
>
> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developer
> http://www.opensips-solutions.com <http://www.opensips-solutions.com>
>
> OpenSIPS Bootcamp 2017, Houston, US
> http://opensips.org/training/OpenSIPS_Bootcamp_2017.html
> <http://opensips.org/training/OpenSIPS_Bootcamp_2017.html>
>
> On 08/02/2017 11:46 AM, Ravi Patel wrote:
>> Dear Bogdan and Ben,
>> Thanks for your replies.
>>
>> Previously, I set t_on_failure() when forwarded call came back to
>> OpenSIPS(not in failure_route) , Now after your suggestion I set
>> *t_on_failure()* before *t_relay()* in *failure_route*.
>>
>> That Indeed solved the issue of forwarding and timeout, but faced
>> another issue after this change.
>>
>> Here is the brief of issue:
>>
>> in failure_route, I fetched some *headers* from *SIP Message,*
>> that checks the number of forwarding and if not exceeded max
>> count, it proceed to forward the call(t_relay()).
>> Now in this logic I added *t_on_failure()* before *t_relay()* ,
>> now here I am not able to get the headers from SIP Message in
>> failure_route where I am checking the max forwarding count.
>>
>> Is there any way to get the headers in failure_route after using
>> t_on_failure in failure_route ??
>>
>> Hope I explained well.
>>
>> Let me know If you need anything else from my side.
>>
>> Regards,
>> Ravi Patel
>>
>> On Fri, Jul 28, 2017 at 9:09 PM, Ben Newlin
>> <Ben.Newlin at genesys.com <mailto:Ben.Newlin at genesys.com>> wrote:
>>
>> Ravi,
>>
>> Are you sure you are arming the failure route after each step
>> using t_on_failure? It sounds like you are only doing this on
>> the call to 2222, which allows you to failover to 3333. But
>> when you send to 3333 you have to arm the failure route again.
>>
>> Ben Newlin
>>
>> *From: *Users <users-bounces at lists.opensips.org
>> <mailto:users-bounces at lists.opensips.org>> on behalf of Ravi
>> Patel <ravi.patel at ecosmob.com <mailto:ravi.patel at ecosmob.com>>
>> *Reply-To: *OpenSIPS users mailling list
>> <users at lists.opensips.org <mailto:users at lists.opensips.org>>
>> *Date: *Friday, July 28, 2017 at 11:36 AM
>> *To: *Bogdan-Andrei Iancu <bogdan at opensips.org
>> <mailto:bogdan at opensips.org>>
>> *Cc: *OpenSIPS users mailling list <users at lists.opensips.org
>> <mailto:users at lists.opensips.org>>
>> *Subject: *Re: [OpenSIPS-Users] OpenSIPS reseting issue with
>> $T_fr_inv_timeout while forwarding
>>
>> Dear Bogdan,
>>
>> I am Grateful for your reply.
>>
>> I applied *$T_fr_inv_timeout* before doing each *t_relay().*
>> by applying it , I am able to achieve it at 1st forwarding
>> but unfortunately not working for 2nd forwarding.
>>
>> The scenario is:
>> 1111
>> 2222 (fr_inv_timeout 10 sec)
>> 3333 (fr_inv_timeout 5 sec)
>> 4444 (fr_inv_timeout 20 sec)
>>
>> when 1111 calls 2222 : OpenSIPS generates CANCEL at 10 secs
>> and forwards call to 3333.
>> now --> 3333 : OpenSIPS generates CANCEL at 5 secs**but does
>> not forward call to 4444 instead it sends *408 to
>> Caller(1111)* and drops call.
>>
>> I am attaching packets where sip.client.com
>> <http://sip.client.com> refers to the SIP clients and
>> sip.server.com <http://sip.server.com> refers to the OpenSIPS
>> Server.
>>
>> Also find the attached snapshots of the call flow.
>>
>> Please guide what can be done or where I am doing wrong ?
>>
>> Let me know if you need any other information.
>>
>> Best Regards,
>>
>> Ravi Patel
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20170901/4d5289bc/attachment-0001.html>
More information about the Users
mailing list