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

From: Brett Tate <[email-masked]>
Date: Sun, 1 Jul 2012 10:10:13 -0700

> IMO its somewhat of a perversion to send an INVITE while 
> desiring that it not be answered.

Although some vendors might use MESSAGE or NOTIFY, the INVITE is another way to cause a ringsplash (associated with some telecom services).  However unless the UAS knows you are attempting a ringsplash (such as by using the Alert-Info), the alert might not fully play or play too long.

> Even more of an abuse to overload the alert urn to
> indicate that you don't want the call answered.

I don't necessarily disagree; however it obviously leads to wondering if anyone would want to send the mentioned ringsplash Alert-Info and have the call to be answered.

> On 6/29/12 4:02 PM, Brett Tate wrote:
> >> 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).

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Tue, 3 Jul 2012 16:15:47 -0400

[as individual]

> Ringsplash is a short burst of ringing, typically in the range of 500
> milliseconds in duration.

The idea seems to be that we want to generate an alert on the UA to
indicate that some action is happening that the user might want to be
informed about, but not to permit the user to answer an INVITE.

I don't think there's any standardized practice for this.

It seems plausible that an INVITE with "Expires: 0" could be used to
indicate a desire to produce alerting without connecting a call.  In
RFC 3261 section 20.19, "Expires: 0" is explicitly valid.

There could be interactions between an auto-answer facility in the UA
and INVITE/Expires: 0, but I assume that the UA firmware will have to
be upgraded to produce a ringsplash under the direction of the
Alert-Info header anyway, so that conflict can be fixed to give
precedence to the no-answer semantics.

The "obvious" way to select the ringsplash is with one of the
"service" URNs, like <urn:alert:service:forward>.  This exposes an
ambiguity of the meaning of these URNs:  when in an INVITE, they
indicate how the called UA is to alert the attending user, but when
used in a 18x response, they indicate how the calling UA is to inform
the calling user.

Hmmm...  actually, the situation is worse, as there is the indication
"an incoming call to this phone has been forwarded from some other
phone" and there is the indication "an incoming call to this phone has
been forwarded elsewhere".  Which of these does
<urn:alert:service:forward> mean?  I believe we may need more values
in the "service" category, and to more clearly specify their meanings.
("service:forwarding-notification" and "service:forwarded-call"?)

>    that may be applied to the physical forwarding line (when idle) to

We can also combine URNs like this:

Alert-Info: urn:alert:service:forward, urn:alert:duration:short

which, if the phone does not have a specific "service:forward" tone,
would cause it to render the "duration:short" tone.

> without defining a do-not-answer value for RFC 5373's Answer-Mode

Actually, "Answer-Mode: no" is a good way to indicate an INVITE that
should not be answered, as the semantics are (can be) clearly
specified.  As I noted above, the phone's code will have to be updated
to support producing ringsplash anyway, so there's no reason we have
to implement ringsplash using only existing headers and values.

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

That's a non-trivial question:  If I have the phone sent to
do-not-disturb, why would I want it to ring?  And if I've got the
phone set to DND, some upstream proxy may decide to not fork the
INVITE to my phone at all.

Dale