10 Aug
2004
10 Aug
'04
2:14 p.m.
Greg:
The problem has been resolved.
Thanks,
Steve
Greg Fausak wrote:
On Aug 10, 2004, at 8:03 AM, Steve Blair wrote:
--
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@upenn.edu
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:
Greg Fausak
www.AddaBrand.com
(US) 469-546-1265 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:
--
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@upenn.edu
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(a)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@upenn.edu
Greg Fausak
www.AddaBrand.com
(US) 469-546-1265