Re: [OpenSIPS-Users] dispatcher and attended transfers

2009-04-24 Thread Stanisław Pitucha
2009/4/15 Bogdan-Andrei Iancu bog...@voice-system.ro:
 Right now the function is not allowed in failure route, but on a short
 overview on the code, there is no reason not to. So, as a trick you can call
 from failure route a generic route block and use the ds_selectxxX() from
 there - this will by pass the checks ;).

Great - finally got time to test that and it works.

The basic idea is (with some pseudocode and fake queries ;) ):

route[5] {
  avp_db_query(select callee_contact from dialog [table to check if
there are any other dialogs from the same number with state in (3,4)
and timeout  unix_timestamp() and lots of other conditions on
from_uri and to_uri], $avp(s:othercalldest));
  if (is_avp_set($avp(s:othercalldest)) {
$var(commonuri) = $(avp(s:othercalldest)[0]);
$var(commonhost) = $(var(commonuri){uri.host});
if (is_one_of_our_pbxes($var(commonhost)) {
  t_on_failure(2);
  $rd = $var(commonhost);
  return;
} else {
  # same check for $(avp(s:othercalldest)[1])
}
  } else {
route(6);
  }
}

route[6] {
  t_on_failure(1);
  ds_select_domain(...);
}

failure_route[1] {
  # standard check status, ds_next_domain(...) and t_relay()
}

failure_route[2] {
  if (t_check_status(408|480|5[0-9][0-9])) {
route(6);
t_relay();
  }
}

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


Re: [OpenSIPS-Users] dispatcher and attended transfers

2009-04-15 Thread Bogdan-Andrei Iancu
Hi Stan,

Stanisław Pitucha wrote:
 2009/4/8 Bogdan-Andrei Iancu bog...@voice-system.ro:
   
 if I got it right, you want to have a kind of dispatching to guarantee that
 all in or out calls for user A are going through the same PBX. Correct?
 

 In short:
 Yes. But internal calls should use only one PBX in the cluster, not two.

 Long explanation:
 Actually, we don't care where the first call is exactly (can be
 randomised / load balanced). Just that if some user is already talking
 to someone on PBX X, we want his next call to route via X too.

 We've got that already working via a hack - we're getting the caller /
 callee contact from the dialog table into an avp. Then if
 $avp(s:contact){uri.host} matches any of our pbxes, we use it for
 routing; otherwise we use a dispatcher. That works relatively well,
 but breaks when one of the PBXes dies for example. Dialog stays in the
 database forever and that user can't dial out anyone, because he
 always gets routed to the dead IP.
   
Got your problem.
 We can't simply route all the calls to/from user A to the same PBX,
 because we'd like to use only one PBX when doing internal calls. If we
 want internal calls to use only one PBX, hashing just on From: and
 To: headers is not enough, because we have 2 transfer scenarios:

 A calls B, B calls C, transfers
 - (two different destinations - B, C and sources - A, B)

 A calls B, A calls C, transfers
 - (two different destinations - B, C, same sources)
   
yes, transfer and dispatcher are not good friends.
 Good enough solution would be, to set the $avp(s:contact){uri.host} as
 the first destination, with failover positions filled with the result
 of ds_select_domain().
   
looks like a nice solution - ideally will be (and can be done) to use 
the ds_select() function in failure route (to do dispatching) only if 
the PBX to contact is down.

Right now the function is not allowed in failure route, but on a short 
overview on the code, there is no reason not to. So, as a trick you can 
call from failure route a generic route block and use the ds_selectxxX() 
from there - this will by pass the checks ;).

Let me know f it works for you.

Regards,
Bogdan
 Ok... I hope that explained the situation :)

 Thanks,
 Stan

 ___
 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] dispatcher and attended transfers

2009-04-08 Thread Bogdan-Andrei Iancu
Hi Stan,

if I got it right, you want to have a kind of dispatching to guarantee 
that all in or out calls for user A are going through the same PBX. Correct?

And the problem is when you to a REFERyou have A talking to PBX1 and 
it wants to do a transfer ? Or?

Regards,
Bogdan


Stanisław Pitucha wrote:
 2009/4/7 Adrian Georgescu a...@ag-projects.com:
   
 You cannot do this reliable the way you propose. The only reliable way is to
 sit behind a PBX/B2BUA that your control and behaves in a consistent and
 reliable way. Otherwise you are at the mercy at the combinations of the SIP
 User Agents that are involved in the call transfer operation.
 

 There is only one specific scenario I want to support:
 - phone has a dialog already open to a PBX
 - phone sends an new call INVITE  to a PBX
 - phone joins the call legs with a REFER

 I think, this is the PBX/B2BUA situation you're talking about?

 I'm not sure what you mean by the combinations of the SIP User Agents
 that are involved. I didn't have any problems with this setup as long
 as the same phone always uses the same pbx.

   
 If you will try to fix incrementally every problem your discover in the SIP
 Proxy for call transfer you will be busy forever solving this because is
 end-point implementation dependent.
 

 I'm only trying to solve failover + distribution over PBXes in the
 proxy. Transfers are properly handled by N asterisk hosts.
 To be specific - my network looks like this:
 UAs - openser (with dispatcher) - N identical asterisk boxes
 All calls go through one of the asterisk boxes.

 Stan

 ___
 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] dispatcher and attended transfers

2009-04-08 Thread Stanisław Pitucha
2009/4/8 Bogdan-Andrei Iancu bog...@voice-system.ro:
 if I got it right, you want to have a kind of dispatching to guarantee that
 all in or out calls for user A are going through the same PBX. Correct?

In short:
Yes. But internal calls should use only one PBX in the cluster, not two.

Long explanation:
Actually, we don't care where the first call is exactly (can be
randomised / load balanced). Just that if some user is already talking
to someone on PBX X, we want his next call to route via X too.

We've got that already working via a hack - we're getting the caller /
callee contact from the dialog table into an avp. Then if
$avp(s:contact){uri.host} matches any of our pbxes, we use it for
routing; otherwise we use a dispatcher. That works relatively well,
but breaks when one of the PBXes dies for example. Dialog stays in the
database forever and that user can't dial out anyone, because he
always gets routed to the dead IP.

We can't simply route all the calls to/from user A to the same PBX,
because we'd like to use only one PBX when doing internal calls. If we
want internal calls to use only one PBX, hashing just on From: and
To: headers is not enough, because we have 2 transfer scenarios:

A calls B, B calls C, transfers
- (two different destinations - B, C and sources - A, B)

A calls B, A calls C, transfers
- (two different destinations - B, C, same sources)

Good enough solution would be, to set the $avp(s:contact){uri.host} as
the first destination, with failover positions filled with the result
of ds_select_domain().

Ok... I hope that explained the situation :)

Thanks,
Stan

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


[OpenSIPS-Users] dispatcher and attended transfers

2009-04-07 Thread Stanisław Pitucha
Hi,
I'm trying to find a solution for using both a dispatcher and attended
transfers reliably.
Standard problems are:
- calls from user A must go to the same pbx as all ongoing calls To and From A
- dispatcher failover must work properly if there's a record of A's
dialog with PBX-1, but PBX-1 goes down

Issues that make this scenario hard to solve are:
- afaik, there's no good way to get the destination of other dialogs,
other than a sql query
- ds_select_domain doesn't work from failure route, so selecting a
preferred destination as well as failover routes must be done in the
same place

I made a patch for the dispatcher module that solves that more or less
(additional avp decides host to prepend to the list), but it has it's
own issues (preferred host appears twice in the destinations list,
marking bad hosts is probably buggy), so I'm not really happy with
that way to solve it.

Has anyone got a working solution for this problem?

Thanks,
Stan

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


Re: [OpenSIPS-Users] dispatcher and attended transfers

2009-04-07 Thread Adrian Georgescu
You cannot do this reliable the way you propose. The only reliable way  
is to sit behind a PBX/B2BUA that your control and behaves in a  
consistent and reliable way. Otherwise you are at the mercy at the  
combinations of the SIP User Agents that are involved in the call  
transfer operation.


If you will try to fix incrementally every problem your discover in  
the SIP Proxy for call transfer you will be busy forever solving this  
because is end-point implementation dependent.


Adrian


On Apr 7, 2009, at 6:41 PM, Stanisław Pitucha wrote:


Hi,
I'm trying to find a solution for using both a dispatcher and attended
transfers reliably.



Standard problems are:
- calls from user A must go to the same pbx as all ongoing calls To  
and From A

- dispatcher failover must work properly if there's a record of A's
dialog with PBX-1, but PBX-1 goes down

Issues that make this scenario hard to solve are:
- afaik, there's no good way to get the destination of other dialogs,
other than a sql query
- ds_select_domain doesn't work from failure route, so selecting a
preferred destination as well as failover routes must be done in the
same place

I made a patch for the dispatcher module that solves that more or less
(additional avp decides host to prepend to the list), but it has it's
own issues (preferred host appears twice in the destinations list,
marking bad hosts is probably buggy), so I'm not really happy with
that way to solve it.

Has anyone got a working solution for this problem?

Thanks,
Stan

___
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] dispatcher and attended transfers

2009-04-07 Thread Stanisław Pitucha
2009/4/7 Adrian Georgescu a...@ag-projects.com:
 You cannot do this reliable the way you propose. The only reliable way is to
 sit behind a PBX/B2BUA that your control and behaves in a consistent and
 reliable way. Otherwise you are at the mercy at the combinations of the SIP
 User Agents that are involved in the call transfer operation.

There is only one specific scenario I want to support:
- phone has a dialog already open to a PBX
- phone sends an new call INVITE  to a PBX
- phone joins the call legs with a REFER

I think, this is the PBX/B2BUA situation you're talking about?

I'm not sure what you mean by the combinations of the SIP User Agents
that are involved. I didn't have any problems with this setup as long
as the same phone always uses the same pbx.

 If you will try to fix incrementally every problem your discover in the SIP
 Proxy for call transfer you will be busy forever solving this because is
 end-point implementation dependent.

I'm only trying to solve failover + distribution over PBXes in the
proxy. Transfers are properly handled by N asterisk hosts.
To be specific - my network looks like this:
UAs - openser (with dispatcher) - N identical asterisk boxes
All calls go through one of the asterisk boxes.

Stan

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