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
<[email protected] <mailto:[email protected]>> 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
<[email protected] <mailto:[email protected]>> 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 <[email protected]
<mailto:[email protected]>> on behalf of Ravi
Patel <[email protected] <mailto:[email protected]>>
*Reply-To: *OpenSIPS users mailling list
<[email protected] <mailto:[email protected]>>
*Date: *Friday, July 28, 2017 at 11:36 AM
*To: *Bogdan-Andrei Iancu <[email protected]
<mailto:[email protected]>>
*Cc: *OpenSIPS users mailling list <[email protected]
<mailto:[email protected]>>
*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
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
