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

Wed Sep 14 12:46:18 EDT 2005

Yea, the last deal on ebay showed us all the power of a serverless (or
almost serverless.-) infrastructure. I am really not religious on this. A PC
is a powerful thing! I am just thinking about the poor guys to get all that
streaming and 3rd party call control in an embedded system.

Maybe both models have to be supported. If that should be the case, then we
should have a way of indicating that the endpoint is able (or willing) to
provide MoH. That would make many people's life easier.

Christian 

> -----Original Message-----
> From: Rohan Mahy [mailto:rohan at ekabal.com] 
> Sent: Tuesday, September 13, 2005 9:58 PM
> To: mailinglist
> Cc: techwg at sipforum.org; Rohan Mahy; 'Hutton Andrew'
> Subject: Re: [SIPForum-techwg] SIP Forum Recommendation for 
> Call Hold Feature.
> 
> 
> On Sep 13, 2005, at 13:01, mailinglist wrote:
> 
> > Hi Rohan,
> >
> > in the end the question is who is responsible for providing MoH?
> >
> > The IETF says it is the UA that puts on hold. Either it plays 
> > something prerecorded, streams some WAV or MP3 file, or it uses 3rd 
> > party call control to make an external entity provide the 
> RTP stream.
> >
> > IMHO that concept is a mistake. We can debate for a long time about 
> > the technical feasibility, and yes it is probably feasable (lets 
> > assume that).
> >
> > The real question is what do you do with the millions of 
> devices that 
> > do not implement MoH, just send a a=sendonly attribute. The only 
> > answer is to provide the MoH service from a centralized 
> component. And 
> > that is what we have to prepare for.
> 
> Alternatively, we can throw away the centralized call 
> processing component and deploy endpoints that implement the 
> features we want. 
>  From a deployment cost perspective that is likely to be cheaper.
> 
> You are also glossing over that the a huge proportion of the 
> millions of endpoints out there are still in active 
> development and can be upgraded in the field automatically.
> 
> We are in a situation like that of the browser wars (Internet 
> Explorer vs. Netscape).  There was a lot of functionality 
> available on the newer browsers.  Those who had the newer 
> browsers got a better user experience when visiting many 
> sites, but there were still hundreds of thousands of copies 
> of older browsers floating around out there.  
> Nobody found it necessary to implement "converters" in HTTP 
> proxies to deal with this.  We lived through that and we can 
> certainly live through it again.
> 
> 
> thanks,
> -rohan
> 
> >> -----Original Message-----
> >> From: Rohan Mahy [mailto:rohan at ekabal.com]
> >> Sent: Tuesday, September 13, 2005 3:42 PM
> >> To: mailinglist
> >> Cc: techwg at sipforum.org; Rohan Mahy; 'Hutton Andrew'
> >> Subject: Re: [SIPForum-techwg] SIP Forum Recommendation 
> for Call Hold 
> >> Feature.
> >>
> >> Christian,
> >>
> >> I'm not sure if you are commenting on doing MOH in the phone or 
> >> elsewhere, but I will respond about ways that have worked on the 
> >> phone.
> >>
> >> On Sep 13, 2005, at 12:21, mailinglist wrote:
> >>> 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...
> >>
> >> i know that all the implementations i was involved with correctly 
> >> handled additional 2xx to an INVITE.  For calls involving audio, 
> >> subsequent calls are automatically sent a BYE.  I've seen another 
> >> implementation that adds every 2xx to a conference.
> >>
> >>> 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).
> >>
> >> the implementation I like best doesn't require any extra signaling.
> >> The phone plays a locally stored wav or mp3 file over an 
> existing RTP 
> >> session.
> >>
> >>> 3. NAT is a headache. If you combine NAT with problem 
> number 1, you 
> >>> need a shrink.
> >>
> >> likewise no new NAT headaches with the method I just described.
> >>
> >>> 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?
> >>
> >> If it hurts, don't do that?  Another implementation can 
> fetch an MOH 
> >> file using streaming HTTP.  (No bills for that either.)
> >>
> >>> 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.
> >>
> >> Our purpose here is not to endorse technically dubious 
> implementation 
> >> decisions of large players.  In fact our purpose is quite the 
> >> opposite.
> >> Our purpose is to describe solutions that are implementable and
> >> technically work well.   The market pressure of a 
> demonstrably simple
> >> industry recommendation with a handful of working 
> implementations can 
> >> and does eventually cause industry giants to cave to 
> customer demand 
> >> and implement appropriately.
> >>
> >> thanks,
> >> -rohan
> >>
> >>
> >>> 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
> >>>>
> >>>>
> >>>
> >>
> >
> 
> 