[SIPForum-techwg] Additional Content: message waiting indicator

[Jamie Palmer]

John,


On 30/10/08 4:01 AM, "Elwell, John" <john.elwell at siemens.com> wrote:

> Jamie,
> 
>> -----Original Message-----
>> From: techwg-bounces at sipforum.org
>> [mailto:techwg-bounces at sipforum.org] On Behalf Of Jamie Palmer
>> Sent: 27 October 2008 16:12
>> To: techwg at sipforum.org
>> Subject: [SIPForum-techwg] Additional Content: message
>> waiting indicator
>> 
>> Folks,
>> 
>> While reviewing the service interactions for
>> transfer/forwarding, another
>> service interaction came up regarding message waiting
>> indicator support --
>> and it was decided that this should be brought before the
>> broader audience
>> for discussion.
>> 
>> Since PRI offers a basic MWI capability -- it seems
>> reasonable (IMO) that
>> SIPConnect also offer this capability.  We had proposed this in the
>> BroadSoft submission...but it only occurred to me recently
>> that this didn't
>> make the 00 draft for SIPConnect 1.1.  Below is some proposed
>> text for MWI
>> support...
>> 
>> 1.1      Message Waiting Indicator
>> Voicemail is a service that can be deployed either within the
>> enterprise
>> (often integrated with the PBX) - or hosted in the service providers
>> network.  Both models have their merits and reasons for
>> deploying one or the
>> other are outside the scope of this document.  When voicemail
>> is hosted in
>> the service provider network, the hosted voicemail
>> application must be able
>> to notify the enterprise when a new voicemail has been received.
> [JRE] I am not convinced this is a common enough scenario that it really
> needs to be in SIPconnect 1.1. If it is, it certainly should be optional
> to implement. But like other features that can be left for use between
> consenting parties, I think this too can be omitted from SIPconnect 1.1.
> 
[jbp] I disagree.  I think if we are building a specification that replaces
PRI, then specifying how message waiting indicator works is important.  As
the text below indicates, this is a "MUST" only "if voicemail is hosted on
the Service Provider network"...doesn't this make it optional enough?
 
>>  
>> If voicemail is hosted on the Service Provider network, then
>> the Service
>> Provider MUST support sending a message-summary NOTIFY event,
>> acting  as a
>> message notifier, as per RFC 3842 [25] using the SIP Specific Event
>> Notification framework as per RFC 3265 [26].   The Service
>> Provider MUST
>> support receiving a SUBSCRIBE event for message-summary.
> [JRE] We would also need to say something about how we route or redirect
> calls to voicemail. Should it involve voicemail URI (RFC 4458) or
> History-Info (RFC 4244)?
>
[jbp] I agree --that's why there was a "a forwarding to voicemail scenario"
in the original text of the 00 draft under the "retargeting services"
section.  And it is also one of the reasons why History-Info was required.

Having re-read RFC4458, I'm not sure this is something we would want to
include in 1.1.  It seems like it would be more applicable between the
service providers proxy/application server and the actual voicemail system.

I think from the perspective of the Enterprise, there should be no
difference between forwarding to a phone number/sip-uri and forwarding to a
voicemail system -- the same call flow should work for both, the same
information should be provided.  I think that's all we need for SIPConnect
1.1 -- perhaps we could look at something more advanced like RFC 4458 in
SIPConnect 2.0...

 
>> 
>> If voicemail is hosted on the Service Provider network, then
>> the PBX MUST
>> support receiving a message-summary NOTIFY event as per RFC
>> 3842 [25] using
>> the SIP Specific Event Notification Framework as per RFC
>> 3265[26].  The PBX
>> MUST support sending a SUBSCRIBE event for message-summary.
> [JRE] I don't think these should be MUST support - only MAY support.
> 
[jbp] The clause above starts with an "If voicemail is hosted on the Service
Provider network" -- so my intent was to make it optional at the service
provider level -- but required for any CPE equipment.

> John