[SIPForum-techwg] SIP Forum Recommendation for Call Hold Feature.

Henry Sinnreich 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 
http://www.ietf.org/internet-drafts/draft-ietf-simple-rpid-08.txt   

For example:
   on-the-phone: The person is talking on the telephone.  This activity
      is included since it can often be derived automatically.

Thanks, Henry

-----Original Message-----
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
To: mailinglist
Cc: techwg at sipforum.org
Subject: Re: [SIPForum-techwg] SIP Forum Recommendation for Call Hold
Feature.


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.

thanks,
-rohan


> 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.
>  
> Christian
>
>> 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 
>> Feature.
>>
>>
>> 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 
>> server.
>> 3. How does hold apply to multiple media streams (e.g. audio and 
>> video).
>> 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.
>>
>> Regards
>> Andy
>>
>> 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 
>> e-mail."
>>
> _______________________________________________
> techwg mailing list
> Send mail to: techwg at sipforum.org
> Unsubscribe or edit options at:  
> http://sipforum.org/mailman/listinfo/techwg


_______________________________________________
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 mailing list