Just found an IETF draft on how to implement PBX features in SIP http://www.voip-info.org/tiki-index.php?page=SIP+PBX+functions
Maybe we can try to implement these in SER and document these functions on the Wiki?
There's some of these in the source examples and in the howto's, but it might be good to document functions one by one.
# Call Hold # Music on Hold # Unattended Transfer # Consultation Hold # Unconditional Call Forwarding # Attended Transfer # No Answer Call Forwarding # Busy Call Forwarding # Single-Line Extension # 3-way Call # Incoming Call Screening # Find-Me # Call Pickup # Call Park # Outgoing Call Screening # Automatic Redial
Anyway, it's good reading material!
/Olle
Hello,
most of the scenarios below do not require any special support in ser. But I agree that it would be nice to have this documented. If anybody has the time and will to create ser.cfg for the scenarios below and document them (a short description of the scenario, message flow, a short description of ser.cfg) then we would like to include it into the SER documentation.
Please let me know if anyone is interested in contributing this (just one scenario is enough).
thanks, Jan.
On 26-11 22:54, Olle E. Johansson wrote:
Just found an IETF draft on how to implement PBX features in SIP http://www.voip-info.org/tiki-index.php?page=SIP+PBX+functions
Maybe we can try to implement these in SER and document these functions on the Wiki?
There's some of these in the source examples and in the howto's, but it might be good to document functions one by one.
# Call Hold # Music on Hold # Unattended Transfer # Consultation Hold # Unconditional Call Forwarding # Attended Transfer # No Answer Call Forwarding # Busy Call Forwarding # Single-Line Extension # 3-way Call # Incoming Call Screening # Find-Me # Call Pickup # Call Park # Outgoing Call Screening # Automatic Redial
Anyway, it's good reading material!
/Olle
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
At 10:54 PM 11/26/2003, Olle E. Johansson wrote:
Just found an IETF draft on how to implement PBX features in SIP http://www.voip-info.org/tiki-index.php?page=SIP+PBX+functions
Maybe we can try to implement these in SER and document these functions on the Wiki?
documenting is a great thing to do. draft-ietf-sipping-cc-framework may provide you with some very reasonable text.
implementation is not necessarily fature of SER -- it is frequently a feature of end-devices (ED).
There's some of these in the source examples and in the howto's, but it might be good to document functions one by one.
# Call Hold
ED feature, specified in the basic SIP spec (there is a difference in SDP usage between obsoleted and current SIP spec)
# Music on Hold
ED feature.
# Unattended Transfer # Attended Transfer
ED feature. there is an internet draft specifying use of REFER for call transfer. (I'm off-line and can't look it up for you, but all of that should be somewhere at www.iptel.org/ietf)
# Consultation Hold
ED feature
# Unconditional Call Forwarding
a way to do so is to set up permanent UsrLoc entry using SerWeb.
# No Answer Call Forwarding # Busy Call Forwarding
Currently, voicemail examples in the 'examples' directory are closest. (We don't have individualized forwarding preferences yet.)
# Single-Line Extension # Call Pickup # Call Park
I'm not sure how to do it easily -- I suspect it would take quite some call control. Having all telephones rung is as easy as forking, but having one of them joined a conversation entered by another one may be tricky.
# 3-way Call
end-device feature (e.g., cisco and mitel have three party conferencing). If two calls in parallel is in conflict with available bandwidth, one could take a network conferencing server too.
# Incoming Call Screening # Outgoing Call Screening
one can configure accounting to generate records for serweb.
# Find-Me
parallel forking is turned on by default. (if that implements what "find-me" is called)
# Automatic Redial
I would say that's an ED feature. There are some drafts specifying subscribtion to call state but I think that having the phone tried regularly is simpler and does not introduce dependency on a rarely implemented feature.
-jiri
-
Jan Janak -
Jiri Kuthan -
Olle E. Johansson