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.
- 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@hotmail.com....)
Sure, but this may not be possible if some sort of authentication is required. Isn't this better handle on the SIP proxy server?
- Caller blocking:
Yes -- we block requests from source causing annoying traffic.
Is caller blocking system wide or configurable per user?
- Call Transfer:
phone feature
Don't the SIP proxy needs to support the SIP REDIR too?
- Support for call time limit:
call-limitation is part of separate software
Is there software already available or are you just saying that this will need to be developed as separate software?
- Redundant server configuration:
available 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@lists.iptel.org' Subject: Re: [Serusers] SER supported feature list
At 09:19 PM 12/17/2003, Hernandez, Cesar wrote:
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@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
At 05:28 PM 12/18/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@hotmail.com....)
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.
- Caller blocking:
Yes -- we block requests from source causing annoying traffic.
Is caller blocking system wide or configurable per user?
System-wide.
- Call Transfer:
phone feature
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.
- Support for call time limit:
call-limitation is part of separate software
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.
- Redundant server configuration:
available 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?
Likewise. DNS/SRV is only one part of the picture -- state replication is the other part.
-jiri
Jiri Kuthan writes:
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.
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.
- 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
-
Hernandez, Cesar -
Jiri Kuthan -
Juha Heinanen