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

Fri Sep 30 15:57:02 EDT 2005

(Catching up on old mail)

IMO any discussion of "hold" in 3261 are meaningless, because SIP just 
doesn't define "hold" at all.

sendonly/inactive may be used by devices that have a notion of hold, but 
using those things doesn't *mean* hold. As Rohan has said, those 
attributes mean exactly what they say, and no more.

There has been *lots* of discussion on this subject, but no tangible 
results of it. Maybe SIPForum is a place to clarify things.

I have been promoting a position, which seems to work better than any 
other, that when offering and answering an endpoint should always 
express the state *it* wants, without regard for what it things the 
other end might want, but constrained by what offer/answer permits.

In the case of hold, I think the model is that an endpoint has a HOLD 
modality for itself, independent of what is going on in the session. 
When HOLD is enabled, the endpoint probably doesn't want to receive 
media. It may or may not want to send media. If it wants to send, then 
sendonly is appropriate in an offer, while if it does not want to send 
then inactive is appropriate. If it receives an offer and must answer, 
then it would answer the same way, except if the offer was recvonly or 
inactive then it must answer inactive rather than sendonly.

More complex MOH implementations, involving 3pcc or transfers, are 
possible as well of course.

Regarding the "importance" of MOH because the poor user wants to hear 
something - the emphasis should be on "something". It doesn't have to be 
something hard to render. Some sort of feedback that the call is still 
active is perhaps important, but an occasional beep is sufficient for 
that. Beyond that the value of anything else drops off quickly, unless 
you are trying to hold the interest of somebody who would rather not be 
waiting.

	Paul

Hutton Andrew wrote:
> Hi Rohan,
> 
> I don't think using "a=inactive" is contrary to RFC3264 however I do think
> there is some inconsistencies in RFC3264 which need some clarification.
> 
> For example section 5 states:
> 
> "If the offerer wishes to only receive media from its peer, it MUST mark the
> stream as recvonly. If the offerer wishes to communicate, but wishes to
> either send nor receive media at this time, it MUST mark the stream with an
> "a=inactive" attribute."
> 
> But section 8.4 states:
> 
> "If the stream to be placed on hold was previously a sendrecv media stream,
> it is placed on hold by marking it as sendonly.  If the stream to be placed
> on hold was previously a recvonly media stream, it is placed on hold by
> marking it inactive."
>  
> So IMHO section 5 indicates the correct behavior for handling media streams
> but section 8.4 as at best confusing because it implies a relationship
> between the state of the media stream with the "call" state.
> 
> I agree with you that there could be problems to do with the interaction
> between 3PCC controllers and a Call Hold feature in a SIP UA this is another
> reason why a SIP Forum recommendation on Call Hold could be helpful.
> 
> Regards
> Andy
> 
> 
> 
> 
> -----Original Message-----
> From: Rohan Mahy [mailto:rohan at ekabal.com] 
> Sent: 14 September 2005 19:02
> To: Hutton Andrew
> Cc: 'mailinglist'; 'techwg at sipforum.org'; Rohan Mahy
> Subject: Re: [SIPForum-techwg] SIP Forum Recommendation for Call Hold Feat
> ure.
> 
> Andrew,
> 
> I'm concerned about recommending something contrary to RFC3264.  As you 
> pointed out, we are in a situation now where some endpoints are 
> implementing to RFC3264 (a=sendonly), some implemented to RFC2543 
> (c=0.0.0.0), and some implemented something entirely different 
> (a=inactive).  Without placing a value judgment on which of these are 
> reasonable or better, these three choice are mutually exclusive and 
> using deploying more than one breaks interoperability.
> 
> Clearly something has to change, but lets make sure we are very crisp 
> on what we are trying to accomplish.
> 
> In any case, I don't think the specific proposal here works.  3pcc 
> controllers need to set a=inactive: for a short period of time for a 
> number of flows to work properly.  We don't want short annoying blips 
> of music or announcements inserted into these sessions.  Under the 
> current approach it is impossible to distinguish a 3pcc controller from 
> a UA that's indicating it won't produce its own hold music.
> 
> Things in the network shouldn't be messing about with session 
> descriptions without some form of consent from the UAs (implicit or 
> explicit).  If it is implicit, we need to be sure there are no 
> unintended consequences.  UAs need to be able to clearly indicate 
> *something* about the hold state(s) to other SIP nodes, but this might 
> already be covered by +sip.rendering.
> 
> Hope this helps.
> 
> thanks,
> -rohan
> 
> On Sep 14, 2005, at 9:50, Hutton Andrew wrote:
> 
>>Hi All,
>>
>>This is just the type of discussion I hoped we would have.
>>
>>Currently we are faced with a situation where many SIP UA's generate
>>"a=sendonly" to indicate that they have put a session on hold. However
>>"a=sendonly" really means just what it says and that is that the UA 
>>wishes
>>to send media but does not want the peer device to transmit. 
>>Unfortunately
>>some statements in RFC 3264 seems to state that this is how an SIP UA 
>>should
>>behave.
>>
>>Most SIP Phones probably don't want to be have to generate MOH and 
>>even if
>>they did many application servers will intercept the "a=sendonly" and 
>>decide
>>to insert a media server to provide MOH. So it seems the model has been
>>broken and a SIP UA cannot use "a=sendonly" to indicate it wants to
>>establish a sendonly media stream because it is likely that something 
>>in the
>>network will intercept this and assume the SIP UA has invoked call 
>>hold and
>>insert music.
>>
>>A slightly better way for a SIP UA to indicate it wants to put a 
>>session on
>>hold would be to use "a=inactive" which at least indicates that the 
>>SIP UA
>>is making the media stream inactive it would not then be so harmful 
>>for an
>>application server to intercept this and provide music to the held 
>>party.
>>
>>So we need to make some recommendations on how a SIP UA should behave 
>>when
>>it does wants to put a call on hold and provide music and for the case 
>>when
>>a SIP UA wishes to put the call on hold but not provide music. I guess 
>>one
>>possibility is that hold is actually just a local UA feature which is 
>>not
>>signalled over the network but this would not satisfy the application
>>servers which really want to know when a call has been put on hold.
>>
>>Another possibility is that we want a more explicit call hold 
>>indication. It
>>appears that this is what the "sip.rendering" parameter that has been 
>>added
>>to the dialog event package is trying to achieve.
>>
>>Regards
>>Andy
>>
>>
>>
>>-----Original Message-----
>>From: mailinglist [mailto:mailinglist at pbxnsip.com]
>>Sent: 13 September 2005 21:01
>>To: 'Rohan Mahy'
>>Cc: techwg at sipforum.org; Hutton Andrew
>>Subject: RE: [SIPForum-techwg] SIP Forum Recommendation for Call Hold
>>Feature.
>>
>>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.
>>
>>
>>Christian
>>
>>
>>>-----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
>>>>>
>>>>>
> _______________________________________________
> techwg mailing list
> Send mail to: techwg at sipforum.org
> Unsubscribe or edit options at:  http://sipforum.org/mailman/listinfo/techwg
> 