Subject: [salud] draft-ietf-salud-alert-info-urns: questions and comments

From: Brett Tate <[email-masked]>
Date: Fri, 29 Jun 2012 09:52:10 -0700

Hi,

Concerning services such as do-not-disturb and call-forwarding (various flavors) optionally sending a ring-splash to the called party, how would that be sent using Alert-Info?  For instance, would it be defined as "service:ringsplash", "service:donotdisturb:ringsplash", or something else?

Although some vendors might implement the splash for the above services (message-summary, etcetera) using SUBSCRIBE/NOTIFY, I'm asking about using the INVITE since the draft did not (unless implied within section 10) expand usability to include Alert-Info within a NOTIFY.  Does anyone send or want to send Alert-Info within a NOTIFY?  If so, should the draft explicitly indicate that the header is optional within a NOTIFY?

The following are some nits concerning draft-ietf-salud-alert-info-urns-06 section 6.2.1:

1) Concerning "service:recall:calback", I assume that "callback" was intended.

2) Concerning "service:recall:transfer        RFC XXXX  Recall due to callback", I'm not positive if "due to callback" was intentional or cut/past error.

Thanks,
Brett

This email is intended solely for the person or entity to which it is addressed and may contain confidential and/or privileged information.  If you are not the intended recipient and have received this email in error, please notify BroadSoft, Inc. immediately by replying to this message, or by sending an email to [email-masked], and destroy all copies of this message, along with any attachment, prior to reading, distributing or copying it.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 29 Jun 2012 14:19:03 -0400

> Concerning services such as do-not-disturb and call-forwarding (various flavors) optionally sending a ring-splash to the called party, how would that be sent using Alert-Info?  For instance, would…

The term "ringsplash" itself doesn't convey any semantics. Do you expect 
it to be a *special* tone? Or do you simply expect it to be brief?

My first thought is just to specify urn:alert:duration:short, along with 
whatever you want to specify the type of alert. Or maybe you need 
"very-short".

But it would be better to define a urn that specifies the *semantic* you 
want the alert to convey. Isn't urn:alert:service:forward already an 
example of this?

> Although some vendors might implement the splash for the above services (message-summary, etcetera) using SUBSCRIBE/NOTIFY, I'm asking about using the INVITE since the draft did not (unless implied…

I have not considered Alert-Info with NOTIFY. Normally NOTIFYs aren't 
alerted. If they were, I would think it would be event-package specific. 
And then the need to alert would probably be conveyed in the body.

	Thanks,
	Paul

> _______________________________________________
> salud mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/salud
>

---

From: Brett Tate <[email-masked]>
Date: Fri, 29 Jun 2012 13:02:15 -0700

> The term "ringsplash" itself doesn't convey any semantics. 
> Do you expect it to be a *special* tone? Or do you simply 
> expect it to be brief?

I'd expect it to be something like RFC 2705's ringsplash.  And if possible, I'd also want the Alert-Info to clearly communicate that this is a ringsplash and indicate the related service.  In case the subsequent CANCEL is early or late, I'd also hope the alert plays once and fully regardless of the CANCEL being early or late.  And being overly optimistic (without defining a do-not-answer value for RFC 5373's Answer-Mode), I'd also potentially want the device to completely treat this as a ringsplash INVITE instead of sending an INVITE 200 response if called party answers prior to CANCEL.

RFC 2705 section 6.1.5: 
  "Ringsplash, also known as "Reminder ring" is a burst of ringing
   that may be applied to the physical forwarding line (when idle) to
   indicate that a call has been forwarded and to remind the user
   that a CF subfeature is active.  In the US, it is defined to be a
   0.5(-0,+0.1) second burst of power ringing. See TR-TSY-000586 -
   Call Forwarding Subfeatures."

> My first thought is just to specify urn:alert:duration:short, 
> along with whatever you want to specify the type of alert. 
> Or maybe you need "very-short".
> 
> But it would be better to define a urn that specifies 
> the *semantic* you want the alert to convey. Isn't 
> urn:alert:service:forward already an example of this?

As currently defined, "urn:alert:service:forward" appears to be an alert played to caller (off hook) instead of the called party (on hook).  Similarly there is currently nothing in the urn to indicate if 1) the INVITE is a forwarded call or 2) a ringsplash because the call was forwarded (instead of being delivered).  

Also since do-not-disturb is not one of the currently defined services within the draft, I'd want to be able to stimulate a ringsplash (if the device knows how) even if the device does not know the related service (do-not-disturb).

Thanks,
Brett

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 29 Jun 2012 16:59:40 -0400

IMO its somewhat of a perversion to send an INVITE while desiring that 
it not be answered. Even more of an abuse to overload the alert urn to 
indicate that you don't want the call answered.

But, I can think of ways you could send the INVITE so that it can't be 
answered. A precondition could do it, though its a hack too.

Clearly this isn't baked yet.

	Thanks,
	Paul