Re: [OpenSIPS-Users] Intercepting a 302 response and dispatching an INVITE to a new destination set

2017-10-13 Thread Ben Newlin 
It’s also important to note that the onreply_route you are using is the global 
reply route that is always called for all replies. This is why it is being 
called even though you did not arm a reply route using t_on_reply. If you don’t 
wish to do any processing at that stage, simply do not implement the route. If 
you implement it, it will always be called.

Ben Newlin

From: Users  on behalf of Bogdan-Andrei Iancu 

Reply-To: OpenSIPS users mailling list 
Date: Friday, October 13, 2017 at 10:08 AM
To: OpenSIPS users mailling list , Blagovest 
Buyukliev 
Subject: Re: [OpenSIPS-Users] Intercepting a 302 response and dispatching an 
INVITE to a new destination set

Hi,

As Alex said, in failure_route (for calls via dispatcher) test for a 3xx reply 
and if the case simply set a new RURI (as you normally do when routing 
requests) and do t_relay() again - by sending the call out to a new 
destination, the received 3xx will be automatically discarded.

Regards,


Bogdan-Andrei Iancu

  OpenSIPS Founder and Developer

  http://www.opensips-solutions.com
On 09/07/2017 08:34 PM, Blagovest Buyukliev wrote:
The onreply_route is never armed, but gets executed.

The failure_route[initial_request] is armed via t_on_failure("initial_request") 
and actually gets executed after the onreply_route (as per my last test).

Can we stop the propagation of the 302 from within failure_route, or is it 
considered already sent after the execution of onreply_route?

On Sep 7, 2017, at 8:12 PM, Alex Balashov 
> wrote:

Don't arm the onreply_route. Doesn't the failure_route get called?

On September 7, 2017 1:08:55 PM EDT, Blagovest Buyukliev 
> wrote:

Which functions need to be used for that?

The current routing logic is roughly what's listed below and the
problematic issues are commented.

How can it be modified to accomplish what you've described?

route {
  ...
  loose_route();
  record_route();
  t_on_failure("initial_request");
  t_relay();

  # We are okay here, the initial INVITE is passed to a local server.
}

onreply_route {
  if ($rs == 302) {
# The 302 is caught here, but we are pretty much handicapped to do
anything in this block.
# The response is passed back to the external network, which is
undesired.
  }
}

failure_route[initial_request] {
# How can we arrive here right upon the receipt of the 302, not in
onreply_route?
}


On Sep 5, 2017, at 4:54 PM, Alex Balashov 
>
wrote:


Yes, failure_route is the answer to all your objectives here. You can
intercept the 302, extract what you want from it, create a new branch
and fork the call elsewhere.

--
Alex Balashov | Principal | Evariste Systems LLC

Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, 
http://www.csrpswitch.com/

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

-- Alex

--
Sent via mobile, please forgive typos and brevity.

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users





___

Users mailing list

Users@lists.opensips.org

http://lists.opensips.org/cgi-bin/mailman/listinfo/users


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Intercepting a 302 response and dispatching an INVITE to a new destination set

2017-10-13 Thread Bogdan-Andrei Iancu 

Hi,

As Alex said, in failure_route (for calls via dispatcher) test for a 3xx 
reply and if the case simply set a new RURI (as you normally do when 
routing requests) and do t_relay() again - by sending the call out to a 
new destination, the received 3xx will be automatically discarded.


Regards,

Bogdan-Andrei Iancu
  OpenSIPS Founder and Developer
  http://www.opensips-solutions.com

On 09/07/2017 08:34 PM, Blagovest Buyukliev wrote:

The onreply_route is never armed, but gets executed.

The failure_route[initial_request] is armed via 
t_on_failure("initial_request") and actually gets executed after the 
onreply_route (as per my last test).


Can we stop the propagation of the 302 from within failure_route, or 
is it considered already sent after the execution of onreply_route?


On Sep 7, 2017, at 8:12 PM, Alex Balashov > wrote:


Don't arm the onreply_route. Doesn't the failure_route get called?

On September 7, 2017 1:08:55 PM EDT, Blagovest Buyukliev 
> wrote:

Which functions need to be used for that?

The current routing logic is roughly what's listed below and the
problematic issues are commented.

How can it be modified to accomplish what you've described?

route {
  ...
  loose_route();
  record_route();
  t_on_failure("initial_request");
  t_relay();

  # We are okay here, the initial INVITE is passed to a local server.
}

onreply_route {
  if ($rs == 302) {
# The 302 is caught here, but we are pretty much handicapped to do
anything in this block.
# The response is passed back to the external network, which is
undesired.
  }
}

failure_route[initial_request] {
# How can we arrive here right upon the receipt of the 302, not in
onreply_route?
}

On Sep 5, 2017, at 4:54 PM, Alex Balashov 
>

wrote:


Yes, failure_route is the answer to all your objectives here. You can
intercept the 302, extract what you want from it, create a new branch
and fork the call elsewhere.

--
Alex Balashov | Principal | Evariste Systems LLC

Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/

___
Users mailing list
Users@lists.opensips.org 
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


-- Alex

--
Sent via mobile, please forgive typos and brevity.

___
Users mailing list
Users@lists.opensips.org 
http://lists.opensips.org/cgi-bin/mailman/listinfo/users




___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Intercepting a 302 response and dispatching an INVITE to a new destination set

2017-09-07 Thread Blagovest Buyukliev 
The onreply_route is never armed, but gets executed.

The failure_route[initial_request] is armed via t_on_failure("initial_request") 
and actually gets executed after the onreply_route (as per my last test).

Can we stop the propagation of the 302 from within failure_route, or is it 
considered already sent after the execution of onreply_route?

> On Sep 7, 2017, at 8:12 PM, Alex Balashov  wrote:
> 
> Don't arm the onreply_route. Doesn't the failure_route get called?
> 
> On September 7, 2017 1:08:55 PM EDT, Blagovest Buyukliev 
>  wrote:
>> Which functions need to be used for that?
>> 
>> The current routing logic is roughly what's listed below and the
>> problematic issues are commented.
>> 
>> How can it be modified to accomplish what you've described?
>> 
>> route {
>>   ...
>>   loose_route();
>>   record_route();
>>   t_on_failure("initial_request");
>>   t_relay();
>> 
>>   # We are okay here, the initial INVITE is passed to a local server.
>> }
>> 
>> onreply_route {
>>   if ($rs == 302) {
>> # The 302 is caught here, but we are pretty much handicapped to do
>> anything in this block.
>> # The response is passed back to the external network, which is
>> undesired.
>>   }
>> }
>> 
>> failure_route[initial_request] {
>> # How can we arrive here right upon the receipt of the 302, not in
>> onreply_route?
>> }
>> 
>>> On Sep 5, 2017, at 4:54 PM, Alex Balashov 
>> wrote:
>>> 
>>> Yes, failure_route is the answer to all your objectives here. You can
>>> intercept the 302, extract what you want from it, create a new branch
>>> and fork the call elsewhere.
>>> 
>>> -- 
>>> Alex Balashov | Principal | Evariste Systems LLC
>>> 
>>> Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) 
>>> Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
>>> 
>>> ___
>>> Users mailing list
>>> Users@lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> 
> -- Alex
> 
> --
> Sent via mobile, please forgive typos and brevity. 
> 
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Intercepting a 302 response and dispatching an INVITE to a new destination set

2017-09-07 Thread Alex Balashov 
Don't arm the onreply_route. Doesn't the failure_route get called?

On September 7, 2017 1:08:55 PM EDT, Blagovest Buyukliev 
 wrote:
>Which functions need to be used for that?
>
>The current routing logic is roughly what's listed below and the
>problematic issues are commented.
>
>How can it be modified to accomplish what you've described?
>
>route {
>...
>loose_route();
>record_route();
>t_on_failure("initial_request");
>t_relay();
>
># We are okay here, the initial INVITE is passed to a local server.
>}
>
>onreply_route {
>if ($rs == 302) {
># The 302 is caught here, but we are pretty much handicapped to do
>anything in this block.
># The response is passed back to the external network, which is
>undesired.
>}
>}
>
>failure_route[initial_request] {
># How can we arrive here right upon the receipt of the 302, not in
>onreply_route?
>}
>
>> On Sep 5, 2017, at 4:54 PM, Alex Balashov 
>wrote:
>> 
>> Yes, failure_route is the answer to all your objectives here. You can
>> intercept the 302, extract what you want from it, create a new branch
>> and fork the call elsewhere.
>> 
>> -- 
>> Alex Balashov | Principal | Evariste Systems LLC
>> 
>> Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) 
>> Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
>> 
>> ___
>> Users mailing list
>> Users@lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users

-- Alex

--
Sent via mobile, please forgive typos and brevity. 

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Intercepting a 302 response and dispatching an INVITE to a new destination set

2017-09-07 Thread Blagovest Buyukliev 
Which functions need to be used for that?

The current routing logic is roughly what's listed below and the problematic 
issues are commented.

How can it be modified to accomplish what you've described?

route {
...
loose_route();
record_route();
t_on_failure("initial_request");
t_relay();

# We are okay here, the initial INVITE is passed to a local server.
}

onreply_route {
if ($rs == 302) {
# The 302 is caught here, but we are pretty much handicapped to do 
anything in this block.
# The response is passed back to the external network, which is 
undesired.
}
}

failure_route[initial_request] {
# How can we arrive here right upon the receipt of the 302, not in 
onreply_route?
}

> On Sep 5, 2017, at 4:54 PM, Alex Balashov  wrote:
> 
> Yes, failure_route is the answer to all your objectives here. You can
> intercept the 302, extract what you want from it, create a new branch
> and fork the call elsewhere.
> 
> -- 
> Alex Balashov | Principal | Evariste Systems LLC
> 
> Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) 
> Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
> 
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Intercepting a 302 response and dispatching an INVITE to a new destination set

2017-09-05 Thread Alex Balashov 
Yes, failure_route is the answer to all your objectives here. You can
intercept the 302, extract what you want from it, create a new branch
and fork the call elsewhere.

-- 
Alex Balashov | Principal | Evariste Systems LLC

Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) 
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] Intercepting a 302 response and dispatching an INVITE to a new destination set

2017-09-05 Thread Blagovest Buyukliev 
Hello,

We are using OpenSIPS 2.3.1 as a proxy to dispatch requests between an external 
network (referred to as "EN") and a few different destination sets of local SIP 
servers (referred to as "LS1", "LS2", "LS3", etc.).

The basic architecture looks like this:

EN <-> OSIPS <-> (LS1, LS2, LS3, ...)

The current setup worked well for us until we implemented a feature in the 
first set of local servers (LS1) which makes them send a "302 Moved 
Temporarily" response to certain INVITEs matching a specific criteria. With 
this feature on, a typical (and unwanted) SIP conversation becomes:

1) EN -> OSIPS: "1 INVITE"
2) OSIPS -> LS1[x]: "1 INVITE" (adds Record-Route and Via headers)
3) LS1[x] -> OSIPS: "100 Trying"
4) LS1[x] -> OSIPS: "302 Moved Temporarily" (request must be handled by a
local server from a different set, say LS3)
5) OSIPS -> EN: "302 Moved Temporarily"
6) EN -> OSIPS: "1 ACK"

The external network simply replies with an ACK to the 302, but doesn't 
initiate a new INVITE to what's indicated in the Contact header of the 302 
response.

To go around this problem, my action plan is to prevent OpenSIPS from passing 
back the 302 to EN in point 5 and instead dispatch the original INVITE to a 
random server from LS3, which would result in a conversation similar to this:

1) EN -> OSIPS: "1 INVITE"
2) OSIPS -> LS1[x]: "1 INVITE" (adds Record-Route and Via headers)
3) LS1[x] -> OSIPS: "100 Trying"
4) LS1[x] -> OSIPS: "302 Moved Temporarily"
5) OSIPS -> LS3[y]: "1 INVITE"
6) LS3[y] -> OSIPS: "200 OK"
7) OSIPS -> EN: "200 OK"
8) EN -> OSIPS: "1 ACK"

However, implementing that behaviour turned out to be very hard, considering my 
limited knowledge of OpenSIPS.

The particular problems that I encountered were:

a) Not being able to drop the 302 from "onreply_route", since the drop() 
function seems to be able to drop only 1xx provisional responses;
b) Not being able to call any of the dispatcher functions for switching to a 
new destination in "onreply_route".

Is there a way to let OpenSIPS handle the 302 not as a normal reply but as a 
failure in "failure_route", where the dispatcher functions can be called?

In general, is the latter conversation flow possible to implement with 
OpenSIPS, or maybe a better solution exists?

Regards,
Blagovest
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users