[SIPForum-techwg] SIP Forum Recommendation for Call Hold Feature.
henry at pulver.com
Tue Sep 13 15:11:41 EDT 2005
I could add to Rohan's point that even having MOH can be a presence data
element, separately from the fact that MOH is generated locally in the SIP
UA, just as "network announcements" are (try the XTEN eyeBeam):
I suggest looking again at
on-the-phone: The person is talking on the telephone. This activity
is included since it can often be derived automatically.
From: techwg-bounces at sipforum.org [mailto:techwg-bounces at sipforum.org] On
Behalf Of Rohan Mahy
Sent: Tuesday, September 13, 2005 1:24 PM
Cc: techwg at sipforum.org
Subject: Re: [SIPForum-techwg] SIP Forum Recommendation for Call Hold
On Sep 13, 2005, at 10:56, mailinglist wrote:
> There is one tricky problem that IMHO has not been addressed properly
> by the IETF proposals. Who provides the music on hold (MoH)?
> There are some folks that a very simple solution: Don't provide MoH!
> But there are some folks (probably the rest of the world's polulation)
> that wants to hear something. Unfortunately, it is practically
> impossible to get MoH from the endpoint, so the PBX must provide this.
I don't know why you say its impossible to get MOH from a phone.
Looking around, I have three SIP phones in my office that all can
produce their own MOH.
> I saw a proposal that send around 1000 SIP messages before you finally
> get MoH. I don't think that is realistic either, MoH has to come
> immediately without big bargaining between all kinds of servers or
> even the UAC.
>> From: techwg-bounces at sipforum.org
>> [mailto:techwg-bounces at sipforum.org] On Behalf Of Hutton Andrew
>> Sent: Tuesday, September 13, 2005 3:57 AM
>> To: 'techwg at sipforum.org'
>> Subject: [SIPForum-techwg] SIP Forum Recommendation for Call Hold
>> Hi All,
>> One of the things our working group proposal indicates we might work
>> on is the production of some recommendations for SIP Protocol feature
>> requirements. I am not sure what form such a proposal will take but I
>> thought I would test the water by suggesting that one of the features
>> we should be writing a recommendation for is Call Hold.
>> Putting a call on hold is one of the basic features of any telephone
>> and every SIP phones I have seen has implemented some kind of call
>> hold function however there are some aspects of this feature which in
>> a SIP environment are open to interpretation and therefore
>> interoperability problems. It is also my understanding that this is
>> not a feature that the IETF will tackle. A SIP Forum recommendation
>> would be useful to set the baseline requirements for a SIP Phone to
>> support Call Hold.
>> Issues which a SIP Forum recommendation on call hold could help to
>> clarify include:
>> 1. How does a SIP Phone indicate a Call Hold invocation (i.e. use of
>> a=sendOnly, a=inactive etc.).
>> 2. How is Music on Hold invoked either from a phone or via a media
>> 3. How does hold apply to multiple media streams (e.g. audio and
>> 4. RTCP Issues.
>> 5. Use of the dialog-event-package "sip.rendering" parameter to
>> indicate call hold.
>> Another question I have is whether this working group will make
>> recommendation purely for SIP Phones or whether we will also include
>> recommendations for other entities like Media Servers and Application
>> Servers as in most environments these servers do exist and impact the
>> SIP Phone requirements.
>> I apologise for starting with one of the less interesting features
>> but I think this could be a useful starting point and is a feature we
>> need to tackle.
>> Andrew Hutton - System Design Consultant
>> Tel: +44 (0)115 943 2618
>> Mobile: +44 (0) 7711877253
>> e-mail: mailto:andrew.hutton at siemens.com
>> Siemens Communications
>> Technology Drive, Beeston, Nottingham, NG9 1LA. England.
>> "Siemens Communications - a division of Siemens plc, Registered No:
>> 727817, England. Registered office: Siemens House, Oldbury,
>> Bracknell, Berkshire, RG12 8FZ.
>> This communication contains information which is confidential and may
>> also be privileged. It is for the exclusive use of the addressee. If
>> you are not the addressee please note that any distribution,
>> reproduction, copying, publication or use of this communication or
>> the information is prohibited. If you have received this
>> communication in error, please contact us immediately and also delete
>> the communication from your computer. We accept no liability for any
>> loss or damage suffered by any person arising from use of this
> techwg mailing list
> Send mail to: techwg at sipforum.org
> Unsubscribe or edit options at:
techwg mailing list
Send mail to: techwg at sipforum.org
Unsubscribe or edit options at: http://sipforum.org/mailman/listinfo/techwg
More information about the techwg