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

Wed Sep 14 13:46:58 EDT 2005

On Sep 14, 2005, at 9:46, mailinglist wrote:

> 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.

I agree that a positive indication in the dialog would be a useful 
thing. Is the +sip.rendering media-feature tag sufficient (ex: placed 
in a Contact header in a target refresh request) or is there something 
else needed?

thanks,
-rohan

> 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
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>>
>