[Serusers] fr_inv_timers affect on inbound/outbound calling

Steve Blair blairs at isc.upenn.edu
Tue Aug 10 16:14:38 CEST 2004


Greg:

   The problem has been resolved.

Thanks,
Steve

Greg Fausak wrote:

>
> On Aug 10, 2004, at 8:03 AM, Steve Blair wrote:
>
>>
>> Greg:
>>
>>   Are there any issues with the SIP domain name? What about
>> sharing the mysql database?
>>
>>   As I see it I plan on defining a new SRV record for our PSTN gateway.
>> It will point to the current proxy but a different port. Listening on 
>> this
>> port will be the "inbound" proxy.
>>
>>   IP phones will remain as they are, namely they will register to the
>> same server via the SRV record that points to port 5060.
>>   My concern is that I will now need to support two identical databases,
>> two SRV records and two SER config files that are nearly identical.
>>
>>   Is this what you did or am I missing something?
>>
>
> Steve,
>
> The database is an issue.  You can't have more
> than one SER process access the database from
> the same domain.  As a matter of clarification, we
> don't use the mysql database (we use postgres) and
> we have modified all of the tables to support
> multi-domain access.  However, we still have
> the 'in the same domain' access problem.
> The problem is, of course, that the location table
> is cached in ser proxy memory.
>
> However, I don't see why you need multiple
> SER processes accessing the same database.
> If your central proxy server (the one with
> database access) authenticates, but doesn't
> set any timers, it can forward an
> outbound call (for example) to another
> SER proxy that *doesn't* have database access.
> That proxy can impose timers.
>
> We just played around with it until we got it to work.
> I have inbound proxies, outbound proxies, enum proxies and
> core proxies.  We also use jasomi for nat/edge
> b2bua proxies. The core is the only
> one with database access.
>
> I heard that iptel was contemplating a cache-less
> feature that would allow table multiple ser proxies
> accessing the same database at the same time.
> I have though about implementing it myself, but
> I haven't had a compelling need yet.  If you must
> have this feature I think it is fairly easy to implement.
>
> ---greg
>
>
>
>> Thanks,Steve
>>
>> Greg Fausak wrote:
>>
>>> Steve,
>>> Both, actually.
>>> We run SER many times on a single box, and also
>>> on different machines.
>>>
>>> -g
>>>
>>> On Aug 10, 2004, at 6:08 AM, Steve Blair wrote:
>>>
>>>>
>>>> Thanks Greg. Do you run two instances of SER on the same hardware
>>>> or do you have physically different boxes?
>>>>
>>>> _Steve
>>>>
>>>> Greg Fausak wrote:
>>>>
>>>>> Steve,
>>>>>
>>>>> We addressed the issue by creating different proxy servers.
>>>>> that is, for example, we a main proxy server, an inbound proxy
>>>>> server and an outbound proxy server.  we set different
>>>>> timers for each of the different servers.
>>>>>
>>>>> it would be very advantageous if you could set a timeout
>>>>> per transaction, but, till then you'll need work-arounds like
>>>>> this.
>>>>>
>>>>> -g
>>>>>
>>>>> On Aug 9, 2004, at 7:45 PM, Steve Blair wrote:
>>>>>
>>>>>>
>>>>>> Hello:
>>>>>>
>>>>>>  This is a question for the entire list. We are trying to use 
>>>>>> SER/SEMS
>>>>>> to replace Centrex service with an Octel voice mail system.  
>>>>>> Therefore
>>>>>> we need to deal with Centrex user expectations. One of their 
>>>>>> expectations
>>>>>> is how many rings a caller should expect to hear before an 
>>>>>> unanswered
>>>>>> call goes to voicemail. Here is the problem.
>>>>>>
>>>>>>  If we set fr_timer and fr_inv_timer sufficiently large enough to 
>>>>>> handle
>>>>>> the various outbound calling scenarios then the inbound calls have
>>>>>> a ring-count-to-voicemail count of about 8. Large enough to 
>>>>>> disorient
>>>>>> callers who are use to the Centrex service behavior.
>>>>>>
>>>>>>  I have not found a way to balance outbound call setup delays as 
>>>>>> high
>>>>>> as 26 seconds without also increasing the ring-count-to-voicemail 
>>>>>> count
>>>>>> beyond a "reasonable", user acceptable level.
>>>>>>
>>>>>>  It seems that we are running into a user expectation problem but 
>>>>>> it is a
>>>>>> real problem for which I need to find an answer. Does anyone have 
>>>>>> any
>>>>>> experience dealing with this type of issue? If so how did you 
>>>>>> address it?
>>>>>>
>>>>>> Thanks,Steve
>>>>>>
>>>>>> _______________________________________________
>>>>>> Serusers mailing list
>>>>>> serusers at lists.iptel.org
>>>>>> http://lists.iptel.org/mailman/listinfo/serusers
>>>>>>
>>>>>>
>>>>> Greg Fausak
>>>>> www.AddaBrand.com
>>>>> (US) 469-546-1265
>>>>
>>>>
>>>>
>>>>
>>>> -- 
>>>>  ISC Network Engineering
>>>> The University of Pennsylvania
>>>> 3401 Walnut Street, Suite 221A
>>>> Philadelphia, PA 19104
>>>>
>>>> voice: 215-573-8396
>>>>       215-746-7903
>>>>
>>>> fax: 215-898-9348
>>>> sip:blairs at upenn.edu
>>>>
>>>>
>>>>
>>> Greg Fausak
>>> www.AddaBrand.com
>>> (US) 469-546-1265
>>
>>
>>
>> -- 
>>  ISC Network Engineering
>> The University of Pennsylvania
>> 3401 Walnut Street, Suite 221A
>> Philadelphia, PA 19104
>>
>> voice: 215-573-8396
>>       215-746-7903
>>
>> fax: 215-898-9348
>> sip:blairs at upenn.edu
>>
>>
>>
> Greg Fausak
> www.AddaBrand.com
> (US) 469-546-1265


-- 
  
ISC Network Engineering
The University of Pennsylvania
3401 Walnut Street, Suite 221A
Philadelphia, PA 19104  


voice: 215-573-8396 

       215-746-7903

fax: 215-898-9348    

sip:blairs at upenn.edu




More information about the sr-users mailing list