18 Dec
2003
18 Dec
'03
11:28 a.m.
I agree that features are not the only thing to look at for decision-making.
The purpose for this table is to have a compiled list of SIP proxy specific
features that are already available in SER (maybe it can be added to the SER
admin manual), and have an idea of what may need development if required.
Sure, but this may not be possible if some sort of authentication is
required. Isn't this better handle on the SIP proxy server?
Is caller blocking system wide or configurable per user?
Don't the SIP proxy needs to support the SIP REDIR too?
Is there software already available or are you just saying that this will
need to be developed as separate software?
Again is there some software developed for SER or are you thinking about
clustering software and/or making usage of DNS SRV resource records which
will provide some kind of redundancy?
Thanks, your input was appreciated.
-Cesar
-----Original Message-----
From: Jiri Kuthan [mailto:jiri@iptel.org]
Sent: Wednesday, December 17, 2003 3:42 PM
To: Hernandez, Cesar; 'serusers(a)lists.iptel.org'
Subject: Re: [Serusers] SER supported feature list
At 09:19 PM 12/17/2003, Hernandez, Cesar wrote:
* Private
number (permanent Caller-ID blocking):
A way I do maintain privacy is I use a stupid
user id
(You certainly know how much identity is dislocsed if you
send from mr_goerge_w_bush(a)hotmail.com....) * Caller
blocking:
Yes -- we block requests from source causing annoying traffic. * Call
Transfer:
phone feature * Support for
call time limit:
call-limitation is part of separate software * Redundant
server configuration:
available as separate software Hello,
I'm compiling a table of features supported in SER, such table will be
helpful
to compare SER capabilities with other SIP proxy servers.
Keep in mind that's a hard job. Some of the features may be
end-device feature and some may have different mimics than
you would expect. Also, it is not only specific telephony
features which matter: importantly, there are things such
as operational characteristics (performance, scalability)
and ability to introduce new features and integrate with web.
* Private number (permanent Caller-ID blocking):
A way I do maintain privacy is I use a stupid user id
(You certainly know how much identity is dislocsed if you
send from mr_goerge_w_bush(a)hotmail.com....)
* Caller-ID blocking per call (like Bell *67):
see above, a phone may maintain multiple identities, one of
them less informational than the other one.
* Caller blocking:
Yes -- we block requests from source causing annoying traffic.
* Call Waiting (support more than one call):
phone feature (see for example www.iptel.org/tt/ for such a phone)
* International routing dial plan:
* Least-cost routing:
all trivial config options
* URI/Phone manipulation: Yes
* Find-me parallel calling: No
find-me is built-in (known under the SIP term "parallel forking")
* Find-me consecutive calling: No
unavailable now
* Call Transfer:
phone feature
* Conference Calls (3-way calling): Yes
* NAT STUN: Yes
just for sake of clarity: we have a STUN impelmentation,
but it is separate from SER
* Billing Flat-file CDR: Yes
* Authentication: Yes
* Authorization: Yes
* RADIUS authentication/Authorization: Yes
* RADIUS accounting: Yes
* Support for call time limit:
call-limitation is part of separate software
* ENUM support : Yes
* IM&P (Instant Messaging and presence): Yes (2G/SMS, SIMPLE/XMPP Jabber)
* WEB Provisioning Interfaces: Yes
* Programming interface to remotely provision from an OSS system
(add/remove/modify
user/settings):
provisioning available as command-line or web tools
* Programming interface to remotely modify system
settings from an OSS
system (routing rules, gateways, etc.):
available as server configuration options
* Redundant server configuration:
available as separate softwarea
* Call return (like Bell *69):
* Call screening:
see missed calls and click-to-dial in SERweb
* MWI (SIP NOTIFY):
not now
-jiri
18 Dec
18 Dec
5:48 p.m.
New subject: [Serusers] SER supported feature list
At 05:28 PM 12/18/2003, Hernandez, Cesar wrote:
Sure, but this may not be possible if some sort of authentication is
required. Isn't this better handle on the SIP proxy server?
Both is possible, I just happen to like end-device-driven identity
better. The architectureal principal which applies is the end-to-end
principle, which advices to leave burden away from network. One
could introduce network-driven anonymization, but that would take
a b2bua, i.e., more software to buy and maintain, more scalability
issues (session state must be remembered), etc.
Is caller blocking system wide or configurable per user?
System-wide.
Don't the SIP proxy needs to support the SIP REDIR too?
Redirection is a different feature from call transer. Redirection
divers call to be set up. Call transfer diverts established call.
Redirection is implementd using 3xx reply classes in SIP which we
support. Transfer is implemented using the REFER method, which does
not need to be understood by proxy server. It is just relayed as any
other method is.
Is there software already available or are you just saying that this will
need to be developed as separate software?
It is available under a commercial license.
Again is there some software developed for SER or are you thinking about
clustering software and/or making usage of DNS SRV resource records which
will provide some kind of redundancy?
Likewise. DNS/SRV is only one part of the picture -- state replication
is the other part.
-jiri
* Private number (permanent Caller-ID blocking):
A way I do maintain privacy is I use a stupid user id
(You certainly know how much identity is dislocsed if you
send from mr_goerge_w_bush(a)hotmail.com....) * Caller blocking:
Yes -- we block requests from
source causing annoying traffic. * Call Transfer:
phone feature * Support for call time limit:
call-limitation is
part of separate software * Redundant server configuration:
available as
separate software 
19 Dec
19 Dec
12:13 a.m.
New subject: [Serusers] SER supported feature list
Jiri Kuthan writes:
Is caller blocking system wide or configurable per user?
System-wide.
again, in our case, caller blocking is configurable per user based on
information we get from radius.
Both is possible, I just happen to like
end-device-driven identity
better. The architectureal principal which applies is the end-to-end
principle, which advices to leave burden away from network. One
could introduce network-driven anonymization, but that would take
a b2bua, i.e., more software to buy and maintain, more scalability
issues (session state must be remembered), etc.
unfortunately the phone law in finland dictates that the user must have
the right to ask the network to block his/her callerid at least for
those calls that end up in pstn.
fortunately this is easy to do in ser and we have done it long time
ago. the trick is to add rpid header to the invite request that has
privacy=full parameter. in our case this is configurable by the user
himself per phone number uri.
* Caller
blocking:
Yes -- we block requests from source causing annoying traffic. >>>* Call Transfer:
>>phone feature
this is what i'm currently working on, i.e., per user per uri network
based call transfer (unconditional, busy, no answer and unavailable).
-- juha
7679
days inactive
7680
days old
2 comments
3 participants
participants (3)
-
Hernandez, Cesar -
Jiri Kuthan -
Juha Heinanen