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

Tue Sep 13 15:21:49 EDT 2005

Technically it is possible, no question. But it has the following problems:

1. It is complicated. Think about handling multiple 2xx with several
dialogs, I don't know anybody who implemented that properly... 

2. It takes time to send the messages. If you do it right, you have to send
a lot of messages around before you actually have MoH established. Think
about challenging and security (e.g. mikey).

3. NAT is a headache. If you combine NAT with problem number 1, you need a
shrink.

4. The call to the MoH server will by default appear as regular call. Who
pays the bill for that call? How do you exclude it from the usual billing?

5. What about the other phones? I did not see big C doing MoH and in real
life that is the problem for the persons who have to install a system. Their
customers care little about IETF call flow proposals, they want to have a
working system.

Christian

> -----Original Message-----
> From: Rohan Mahy [mailto:rohan at ekabal.com] 
> Sent: Tuesday, September 13, 2005 2:24 PM
> To: mailinglist
> Cc: Rohan Mahy; 'Hutton Andrew'; 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
> 
> 