[OpenSIPS-Users] Dispatcher Configuration

[Gonzalez, Julio]

Hi Bogdan,

Currently I have only one AS backup and opensip is working as load
balancer and we might be having a few more within the cluster.

A couple of questions:

1. Does opensip track the SIP phone originator?  If there are two byes
from different users, does opensip know which transaction this BYE
belongs to? Do I actually care?

2. Do I need to create another failure route for this case?. I mean,
will the failure route section of the opensip configuration be invoked
again when the BYE is received (i.e. it forgets about the original
INVITE)?

3. Can I use the same failure route that I have for route?

4. Does opensip correlate the INVITE with the BYE? Or (as I've
understood) opensip is transaction stateful and not dialog stateful?

Regards,

Julio

-----Original Message-----
From: Bogdan-Andrei Iancu [mailto:bogdan at voice-system.ro] 
Sent: Donnerstag, 30. Oktober 2008 11:41
To: Gonzalez, Julio
Cc: users at lists.opensips.org
Subject: Re: [OpenSIPS-Users] Dispatcher Configuration

Hi Julio,

and the backup AS is only one (I mean is a one to one replacement), or 
you can send the BYE to any of the available AS?

Because, for sequential requests, you could install a failure_route and 
catch the local 408 (timeout) and do a serial fork to another AS.

Regards,
Bogdan

Gonzalez, Julio wrote:
> Hi Bodgan,
>
> Thanks for answering.. 
>
> I do dispatching on the first message (it could be INVITE, MESSAGE,
> etc.) and then record-route.
>
> RTP does not flow over my AS. 
>
> The issues is when I sent the bye and no answer from original AS, then
I
> expect that the BYE goes to the back-up AS. At that time, RTP (the
> entire session) is over.
>
> Regards,
>
> Julio
>
> -----Original Message-----
> From: Bogdan-Andrei Iancu [mailto:bogdan at voice-system.ro] 
> Sent: Freitag, 24. Oktober 2008 14:42
> To: Gonzalez, Julio
> Cc: users at lists.opensips.org
> Subject: Re: [OpenSIPS-Users] Dispatcher Configuration
>
> Hi Julio,
>
> Do you do dispatching for all requests (initial -like INVITE - and 
> sequential - like ACK, BYE) or only for initial ones and you do 
> record-route ?
>
> Also, in step 2 , how is the call (RTP) moved on the backup AS? does
it 
> take over the IP of the primary AS?
>
> Regards,
> Bogdan
>
> Gonzalez, Julio wrote:
>   
>> Hi All,
>>
>> I am using the dispatcher (in OpenSip 1.4.2) module to balance the 
>> load but I am struggling with the fail-over configuration. As far as
I
>>     
>
>   
>> know, OpenSip is a transaction stateful server (not dialog statefull)

>> so that It will not correlate the different transactions of one
>>     
> dialog.
>   
>> My problem is in case of failover when a dialog was already 
>> established. The scenario is as follows:
>>
>> 1. During the course of the call, the application server goes down
>>
>> 2. Application Server back-up takes over.
>>
>> 3. Call is not affected. RTP continues flowing.
>>
>> 4. User disconnects the call.
>>
>> 5. When the user disconnect the call, obviously the BYE will try the 
>> get the old route to the destination, but as this Application Server 
>> was "moved" to another IP Address
>>
>> 6. OpenSip receives a timeout.
>>
>> 7. OpenSip notes the problem, marks destination unavailable and 
>> selects the new destination from the list of proxies.
>>
>> 8. Message goes to destination.
>>
>> I looked at the list and there are a couple of examples but all of 
>> these are assuming the initial INVITE. Here, I already sent the
INVITE
>>     
>
>   
>> and the call was successful established...
>>
>> How can I set up (or where in) the configuration file to capture this

>> reply message?
>>
>> I tried to used the reply_route section, but I it is not allowed to 
>> put calls like dst_mark() ..
>>
>> Any help will be much appreciated.
>>
>> Julio Gonzalez-Saenz
>>
>>
>>     
>
------------------------------------------------------------------------
>   
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>   
>>     
>
>
>