Subject: RE: [BLISS] Use of Warning: header to transport additional status indications

From: "Brian Stucker" <[email-masked]>
Date: Tue, 4 Sep 2007 10:38:58 -0500

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Friday, August 31, 2007 3:47 PM
> To: [email-masked]
> Subject: Re: [BLISS] Use of Warning: header to transport 
> additional status indications
> 
>    From: "Brian Stucker" <[email-masked]>
> 
>    Interesting way of putting it, but you've missed one thing: the
>    indication is always present and in-sync with the status 
> of the feature
>    in the existing PSTN technique.
> 
> Is that really so, though?  My PSTN-provided voicemail uses a 
> modified dial tone to indicate that I have new voicemail 
> present.  But there is a delay in reporting -- I can call the 
> voicemail retrieval number, play and delete a new message, 
> but if I hang up and immediately go off-hook again, the 
> modified dial tone will remain.
> 
> Is PSTN call-forwarding reporting actually always in-sync?  
> Or is it just good enough that people are satisfied?

You're using a slightly different scenario to make your point. With
voicemail, it may take some time for the SMDI message off the voicemail
box to hit your PSTN switch and cause the MWI flag to be set/cleared in
your profile.

For call forwarding, if the switch is the thing actually doing the call
forwarding, then your profile entry is immediately updated as part of
the same software process that enabled CFW because that flag is the
thing that tells the switch to forward your calls.

Are you arguing for "good-enough" behavior because you really think it's
the ideal solution to the problem of keeping two state machines in sync,
or for some other reason?

> 
>    It may not be in your case. Otherwise, I agree, yes, this would be
>    equivalent. However, if people KNOW that they have call forwarding
>    setup and don't get the indication as they expect, due to lag, that
>    can be confusing to them and interpreted as unreliable.
> 
> We can also use some tricks to improve the reporting time lag 
> -- e.g., the gateway can be programmed to know the dial codes 
> for activating and deactivating call forwarding, and can be 
> careful to quickly get a refresh of the call-forwarding state 
> after the end of a call that was dialed using one of those dial codes.
> 
> I don't think that these problems are really that difficult 
> that we must meticulously replicate what the PSTN already 
> does.  And we really should avoid architectural contortions 
> of SIP; it's messy enough already.

I agree, we should avoid architectural contortions of SIP; but it's a
tool and we should not be afraid to use it. 

<rant (not directed at anyone in particular)>
*** END USERS DO NOT CARE THAT THEIR CALLS ARE CARRIED BY SIP OR NOT.
***

They have a set of features, some new, some old that they're used to
that they want to keep. We have a bad habit of leaving people less
versed in the protocol to try to define how these features should work
with SIP and then complaining that they did it all wrong, ridicule their
requirements because they happen to be coming from a particular
background, or come up with a sort-of-works solution for them which
doesn't really satisfy their requirements.

We're talking about a box that can't do subscribe/notify and the desire
to play a tone at the beginning of a call depending upon the state of a
flag somewhere in the network. This isn't rocket science. SIP can do
this, and it can do this with more flexibility than the PSTN can.
</rant>

And with that, Denis, I am going to bow out of the discussion. I'm fine
with an Alert-Info with a defined URN on a 180, but would ask that an
SUB/NOT mechanism be defined in conjunction with this to receive the
information that way for more SIP-aware network solutions.

Regards,
Brian

_______________________________________________
BLISS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/bliss

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 04 Sep 2007 14:09:01 -0400

inline

> thing that tells the switch to forward your calls.

The "switch" that is responsible for call forwarding is involved in 
*inbound* calls. It is not necessarily involved in *outbound* calls, 
where it isn't needed. While some architectures will result in the same 
component being responsible for both, that certainly won't always be the 
case.

> tool and we should not be afraid to use it. 

Note that this can provide *better* results than the proposed solution 
of carrying this in the response to an outgoing call. It can result in 
the UAC receiving a notification relatively quickly after the state is 
changed without the UAC ever being touched by a user. A suitable UAC can 
then light an indicator light. This is *way* better than the proposal 
and better than native PSTN implementations too. And its so even if the 
forwarding is being handled in a PSTN component.

> information that way for more SIP-aware network solutions.

PLEASE - there were two distinct pieces of information being discussed 
in the original proposal.

1) the callee is on another call but is being alerted anyway.
    For some reason the callee desires that the caller know
    that situation.

2) a proxy responsible for an AOR has been configured to unconditionally
    forward all inbound calls to that AOR. There is a desire to inform
    UAs registered to this AOR that this configuration is in effect, with
    the result that no inbound calls will be presented to these UAs.

They were conflated there presumably on the assumption that a single 
mechanism was to be used for both. But the discussion since has 
separated them. Don't put them back together please.

We have "some" general agreement on the use of Alert-Info for (1).

I don't know if we have *any* agreement on (2). (Well, Dale and I agree, 
but I doubt that matters.)

	Paul

---

From: [email-masked]
Date: Tue, 4 Sep 2007 14:47:44 -0400

It has been mentioned that the PSTN method of providing the
call-forwarding status is instantaneous, with the implication that it
is important to the user that it be so.  This has been used to support
the concept of providing the call-forwarding status piggybacked on the
response messages for an outgoing INVITE -- which I consider to be an
abomination.  So I was inquiring if the apparent user need was a real
user need.

Dale

---

From: "Brian Stucker" <[email-masked]>
Date: Tue, 4 Sep 2007 14:13:10 -0500

inline

> From: Paul Kyzivat [mailto:[email-masked]] 

[snip]

> > voicemail, it may take some time for the SMDI message off the 
> > voicemail box to hit your PSTN switch and cause the MWI flag to be 
> > set/cleared in your profile.
> > 
> > For call forwarding, if the switch is the thing actually doing the 
> > call forwarding, then your profile entry is immediately updated as 
> > part of the same software process that enabled CFW because 
> that flag 
> > is the thing that tells the switch to forward your calls.
> 
> *inbound* calls. It is not necessarily involved in *outbound* 
> calls, where it isn't needed. While some architectures will 
> result in the same component being responsible for both, that 
> certainly won't always be the case.

Nice antiseptic quotes around "switch". :)

Yes, this is true. It is possible in "some architectures", however, in
the PSTN architecture that is being discussed, it does not make any
difference because the profile information is made available to the
"switch" handling the outbound call from a central repository prior to
the call being authorized to complete. That information has a flag in it
that tells the outbound switch that call-forwarding is in effect, and
that a warning tone should be played.

> 
> > Are you arguing for "good-enough" behavior because you really think 
> > it's the ideal solution to the problem of keeping two state 
> machines 
> > in sync, or for some other reason?
> > 
> >> -- e.g., the gateway can be programmed to know the dial codes for 
> >> activating and deactivating call forwarding, and can be careful to 
> >> quickly get a refresh of the call-forwarding state after 
> the end of a 
> >> call that was dialed using one of those dial codes.
> >>
> >> I don't think that these problems are really that 
> difficult that we 
> >> must meticulously replicate what the PSTN already does.  And we 
> >> really should avoid architectural contortions of SIP; it's messy 
> >> enough already.
> > 
> Note that this can provide *better* results than the proposed 
> solution of carrying this in the response to an outgoing 
> call. It can result in the UAC receiving a notification 
> relatively quickly after the state is changed without the UAC 
> ever being touched by a user. A suitable UAC can then light 
> an indicator light. This is *way* better than the proposal 
> and better than native PSTN implementations too. And its so 
> even if the forwarding is being handled in a PSTN component.

The term "better" is relative. Relative to you, perhaps yes, your
proposal would yeild better results. To a blind man, an indicator light
is useless. To a deaf man, a tone is useless. You're arguing a totally,
entirely, different point than what I am trying to point out here. I'm
not arguing that one way or another of providing the feature is the
*best* way because that's a value judgement that is outside of the scope
of the protocol question being asked. You are designing a network
architecture to fit the solution you'd like to see. I don't think that's
what was asked for. What was asked was, given a network architecture
that is out of scope for discussion, what is the best way to use SIP to
address a need without contorting SIP (and I fail to see how using
Alert-Info contorts SIP). 

If you want the operators that drive a good chunk of the service
requirements that create the message flows we're here to interop to stay
away from this forum, then all we need to do is just keep posting
threads like this one, and they'll simply say, "forget that group, I'm
going to TISPAN or 3GPP where I, as an operator, can get something
done." If that's what you would like, then let's continue to argue
non-protocol questions and send more business to IMS so CT3 can just
define a P-Alert-Info header and be done with it.

> > with SIP and then complaining that they did it all wrong, ridicule 
> > their requirements because they happen to be coming from a 
> particular 
> > We're talking about a box that can't do subscribe/notify and the 
> > desire to play a tone at the beginning of a call depending upon the 
> > state of a flag somewhere in the network. This isn't rocket 
> science. 
> > SIP can do this, and it can do this with more flexibility 
> than the PSTN can.
> > </rant>
> > 
> > And with that, Denis, I am going to bow out of the discussion. I'm 
> > fine with an Alert-Info with a defined URN on a 180, but would ask 
> > that an SUB/NOT mechanism be defined in conjunction with this to 
> > receive the information that way for more SIP-aware network 
> solutions.
> 
> PLEASE - there were two distinct pieces of information being 
> discussed in the original proposal.
> 
> They were conflated there presumably on the assumption that a 
> single mechanism was to be used for both. But the discussion 
> since has separated them. Don't put them back together please.

I'm not conflating, I'm personally fine with the same mechanism being
used for both. If you want to play a tone, and you know your Alert-Info
header won't get stripped going to the UA and are willing to do the
leg-work to get an appropriate URN defined, knock yourself out.

> I don't know if we have *any* agreement on (2). (Well, Dale 
> and I agree, but I doubt that matters.)
> 
> 	Paul
>

---

From: "Brian Stucker" <[email-masked]>
Date: Tue, 4 Sep 2007 14:32:47 -0500

> Sent: Tuesday, September 04, 2007 1:48 PM
> To: [email-masked]
> call-forwarding status is instantaneous, with the implication 
> that it is important to the user that it be so.  This has 
> been used to support the concept of providing the 
> call-forwarding status piggybacked on the response messages 
> for an outgoing INVITE -- which I consider to be an 
> abomination.  So I was inquiring if the apparent user need 
> was a real user need.

Ah, thank you for clarifying.

So, are you opposed to tones in general, or just this one? PBXes could
do this today as well, so this is not limited to the PSTN.

I'd be interested to hear your thoughts on how transporting
feature-specific information for the originator of a call in the case of
identity compares with this case. Since the network may be involved in
asserting the identity of the terminating party on behalf of the
originator who has a called party name feature, how would you recommend
that information be transported?

BTW- My earlier implication is that it is important to the user that the
mechanism used to report the desired state information (in this case the
call-forwarding status) does so in as timely a method as possible to
avoid confusion as to the actual state of the feature by the end-user. I
think this is a general requirement for any feature which has such an
indication to the end-user, and is not limited to this discussion. 

In particular to this discussion, I do not see this as requiring that
call-forwarding status be piggybacked on response messages for an
outgoing INVITE (this statement should make you happy). Rather, that the
call-forwarding status be updated at whatever element is responsible for
signaling to the user that the feature is enabled prior to the next call
being initiated (or as close to that time as is feasibly possible). 

I see being able to provide feature parity within SIP, when
subscribe/notify is not possible, where the alternative is NO feature
(in this case no indication) when using a SIP UA as being a bad thing
(tm). Especially so when the potential solution to the problem is such
that there appears to be a way of initially providing the feature to the
SIP UA, with acknowledgement that there are more complete ways of
approaching the problem space within other, future, network
architectures, without contorting SIP and without precluding the
solution you (and I) are advocating.

Regards,
Brian

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 04 Sep 2007 18:20:59 -0400

inline,

	Paul

> that a warning tone should be played.

The basic feature being discussed (letting the UAC, and hence the user 
of the UAC, know that forwarding is enabled) is valid whether the 
forwarding is done in the PSTN or in SIP.

IMO it would be best if there was a single mechanism that SIP UAs use 
for this in both cases. So a solution biased towards a PSTN architecture 
isn't ideal.

> Alert-Info contorts SIP). 

I disagree. It is better if the UA knows the status as soon as possible, 
so that the information can be made available to the user as soon as 
possible.

The indicator is useful for those who can see. Those who can't see need 
another means to discover what the UAC knows. It could be via a modified 
dial tone, or a special tone played from time to time, or whatever. We 
don't need to design the UI here. The examples are just that.

The information being conveyed is about the (in)ability to receive 
incoming calls. It really has *nothing* to do with outgoing calls. It 
could happen on a device that is *never* intended to originate calls, 
and that may in fact be prevented from originating calls. In that case 
presenting the information at the time of call origination is *useless*. 
  I find it hard to argue that making it possible to present it sooner 
is not "better".

Using Alert-Info for this is contorted because it has nothing to do with 
the call.

> define a P-Alert-Info header and be done with it.

The Alert-Info header is already there. I don't think we can *prevent* 
it being used for this purpose.

But we can suggest that it is not a *good* way, and that there are 
*better* ways.

Or we can agree that every implementation idiosyncrasy of the PSTN be 
replicated in SIP, in which case there was no reason to do SIP.

> I'm not conflating,

Yes you are. These are entirely distinct things that have been lumped 
together solely to justify a common implementation.

> I'm personally fine with the same mechanism being
> used for both.

That is a different story. They are conflated, but you don't mind. We 
have different opinions, and it is a matter of arguing the merits, which 
is what we have been doing.

If you start out conflating them then the possibility of solving them 
differently is off of the table.

> If you want to play a tone, and you know your Alert-Info

Yes, I agree with that. It then comes down to:
- who should make the decision include the A-I?
- what are "valid" reasons for doing so?

I can envision roles for nodes representing both the caller and the 
callee in the insertion and/or manipulation of A-I values, but it seems 
to me these all should have some relevance to the call at hand:
- UAC may put in value it would like to callee to play
- Proxy for the UAC may add a value if none provided, based on
   policy of the calling user, perhaps based on attributes of the call.
- Proxy for UAS may sanitize the incoming values in a variety
   of ways to "protect" the UAS. (Based on user controlled policy.)
   May strip all but a restricted set of values that are known
   to be safe. May replace or add value providing distinctive
   alerting about classes of callers.
- UAS may put in a value it would like the UAC to render as ringback
- Proxy for the UAS may add a value if none provided, based on
   policy of the called user, perhaps based on attributes of the call
   or response.
- Proxy for the UAC may sanitize the incoming values in the response
   in a variety of ways to "protect" the UAC. (Based on user controlled
   policy.) May strip all but a restricted set of values that are known
   to be safe. May replace or add value providing distinctive
   alerting perhaps based on attributes of the call or response.

The usage for informing of forwarding enabled is a variant of the last 
bullet above, where the basis for the alert has *nothing* to do with the 
attributes of the call or the call response. It can still be considered 
"policy" so it likely can't be entirely excluded. But that doesn't make 
it a "good" use.

---

From: [email-masked]
Date: Wed, 5 Sep 2007 16:52:33 -0400

I'm not sure what you mean by "tones in general" here.  As far as I
know, SIP has no "tones".

   I'd be interested to hear your thoughts on how transporting
   feature-specific information for the originator of a call in the case of
   identity compares with this case.

What does "in the case of identity" mean?

Also, the core of your sentence seems to be "I'd be interested to hear
your thoughts on how transporting feature-specific information [...]
compares with this case."  And I don't know what you mean by
"transporting feature-specific information" or "this case".

   Since the network may be involved in asserting the identity of the
   terminating party on behalf of the originator who has a called
   party name feature, how would you recommend that information be
   transported?

I don't understand whether you are speaking of the network asserting
the identity of the terminating party to the originating party (and
hence doing so on behalf of the terminating party), or asserting the
identity of the calling party to the terminating party (and hence
doing so on behalf of the calling party).

What is a "called party name feature"?  A feature of the called
party's name, like "starts with 'D'"?

It certainly seems to be desirable, though I'm sure there are cases
where you could argue that timeliness can be sacrificed to some degree
to gain some other advantage.  But I'm sure we fundamentally agree
here.

   In particular to this discussion, I do not see this as requiring that
   call-forwarding status be piggybacked on response messages for an
   outgoing INVITE (this statement should make you happy).

Yes.

   Rather, that the call-forwarding status be updated at whatever
   element is responsible for signaling to the user that the feature
   is enabled prior to the next call being initiated (or as close to
   that time as is feasibly possible).

That's one aspect of timeliness, and it seems we agree that, as above.

   I see being able to provide feature parity within SIP, 

(As an aside, what do you mean by "feature parity"?)

   [...] when subscribe/notify is not possible, 

I think I'm not understanding what you mean by "when subscribe/notify
is not possible".  As sort of a general property, any SIP agent always
has SUBSCRIBE/NOTIFY available.  But I think that you are referring to
a rather particular networking situation, and mean that
SUBSCRIBE/NOTIFY is not available at a certain point in the
architecture -- but I don't grasp exactly what that point is, or
rather, why there aren't "simple" alternatives that suffice.

   [...] where the alternative is NO feature (in this case no
   indication) when using a SIP UA as being a bad thing
   (tm). Especially so when the potential solution to the problem is
   such that there appears to be a way of initially providing the
   feature to the SIP UA, with acknowledgement that there are more
   complete ways of approaching the problem space within other,
   future, network architectures, without contorting SIP and without
   precluding the solution you (and I) are advocating.

Dale

---

From: "Huelsemann, Martin" <[email-masked]>
Date: Tue, 11 Sep 2007 13:41:57 +0200

Hi all,

I've changed the name of this thread, as this is only about the 'call diversion active' notification now. Sorry for the late reply.

So the result of the discussion seems to be that most of you support SUB/NOT for this case. Nevertheless a last try to animate a different solution.

Of course if this would be a status change notification in the context of a activation or deactivation of a service, no doubt that there is no other mechanism than RFC 3265. 
But this is not really a notification about changes in the status of the service, it is more a warning that the service is still active.

Of course this warning could also be conveyed with SUB/NOT, but the question is who would subscribe to this? I think it's not worth subscribing to this, because the user in principle knows the the diversion is activated, because he probably has received this information during the activation, with SUB/NOT, HTTP/XCAP or other means. If it would be only this one example it probably wouldn't matter, but - as a matter of principle - if there are a lot more notifications like this, especially the users of mobile devices will think about to which they should subscribe. (at this time I know only about this one)

So 'call diversion active' is not a status the user wants to be informed of, it's a warning the service provider wants to send to the user.

Of course the user anyway has to fulfil some requirements to receive these notifications/warnings, so RFC 3265 could be the solution. But I think a solution that minimizes the signalling requirements (without an additional SUB/NOT transaction) would make it even more likely that the user receives this warning.

Alert-Info? 

Use of Warning: header to transport not additional status indications but service related warnings?

BR, Martin

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]] 
> Gesendet: Mittwoch, 5. September 2007 22:53
> An: [email-masked]
> Betreff: Re: [BLISS] Use of Warning: header to transport 
> additional statusindications
> 
> 
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 11 Sep 2007 08:13:41 -0400

> But this is not really a notification about changes in the status of the service, it is more a warning that the service is still active.

If there is a mechanism for status change notification, then there is no 
reason for sending a warning that the service is still active.

A warning such as you describe may be appropriate between the UA and the 
user of the UA. But the UA can deliver such warnings based on its 
awareness of the status.

This division of responsibility is consistent with the sip philosophy 
that the endpoints are relatively intelligent, and responsible for UI. 
In that way it differs from the traditional PSTN view of endpoints as 
stupid, with the UI being largely generated elsewhere.

Shifting the UI responsibility to the UA means that it can generate an 
appropriate UI based on its own design rather than the design of the 
network. For instance in this case it means that it may deliver the 
notification at a different point in time that just when a call attempt 
is made. Of course it could still deliver a notification at the time of 
a call attempt, using a tone, if that is the UI it chooses to provide.

	Paul

---

From: "Brian Stucker" <[email-masked]>
Date: Tue, 11 Sep 2007 10:04:19 -0500

> Sent: Tuesday, September 11, 2007 7:14 AM
> To: Huelsemann, Martin
> Cc: [email-masked]; Stucker, Brian (RICH1:AR00); 
> Alexeitsev, D; [email-masked]
> Subject: Re: notification/warning: call diversion active
> 
> 
> 
> > I've changed the name of this thread, as this is only about 
> the 'call diversion active' notification now. Sorry for the 
> late reply.
> > 
> > So the result of the discussion seems to be that most of 
> you support SUB/NOT for this case. Nevertheless a last try to 
> animate a different solution.
> > 
> > Of course if this would be a status change notification in 
> the context of a activation or deactivation of a service, no 
> doubt that there is no other mechanism than RFC 3265. 
> > But this is not really a notification about changes in the 
> status of the service, it is more a warning that the service 
> is still active.
> 
> If there is a mechanism for status change notification, then 
> there is no reason for sending a warning that the service is 
> still active.
> 
> A warning such as you describe may be appropriate between the 
> UA and the user of the UA. But the UA can deliver such 
> warnings based on its awareness of the status.
> 
> This division of responsibility is consistent with the sip 
> philosophy that the endpoints are relatively intelligent, and 
> responsible for UI. 
> In that way it differs from the traditional PSTN view of 
> endpoints as stupid, with the UI being largely generated elsewhere.
> 
> Shifting the UI responsibility to the UA means that it can 
> generate an appropriate UI based on its own design rather 
> than the design of the network. For instance in this case it 
> means that it may deliver the notification at a different 
> point in time that just when a call attempt is made. Of 
> course it could still deliver a notification at the time of a 
> call attempt, using a tone, if that is the UI it chooses to provide.

I agree with you in the case that a status change notification mechanism is employed. 

I believe the remaining question, though, is if there is a way to convey this information using an ad-hoc means where the UA had not previously subscribed, or known to subscribe for a status change notification. Basically, it wouldn't be a status *change* notification, but an FYI *notification* for  UAs that do not subscribe.

We send the state of all sorts of pieces of information in SIP without requiring a prior subscription, but as part of an existing session/session-setup.

Regards,
Brian

> 
> 	Paul
> 
> > Of course this warning could also be conveyed with SUB/NOT, but the 
> > question is who would subscribe to this? I think it's not worth 
> > subscribing to this, because the user in principle knows the the 
> > diversion is activated, because he probably has received this 
> > information during the activation, with SUB/NOT, HTTP/XCAP or other 
> > means. If it would be only this one example it probably wouldn't 
> > matter, but - as a matter of principle - if there are a lot more 
> > notifications like this, especially the users of mobile 
> devices will 
> > think about to which they should subscribe. (at this time I 
> know only 
> > about this one)
> > 
> > So 'call diversion active' is not a status the user wants 
> to be informed of, it's a warning the service provider wants 
> to send to the user.
> > 
> > 
> > Of course the user anyway has to fulfil some requirements 
> to receive these notifications/warnings, so RFC 3265 could be 
> the solution. But I think a solution that minimizes the 
> signalling requirements (without an additional SUB/NOT 
> transaction) would make it even more likely that the user 
> receives this warning.
> > 
> > 
> > Alert-Info? 
> > 
> > Use of Warning: header to transport not additional status 
> indications but service related warnings?
> > 
> > 
> > 
> > BR, Martin
> > 
> > 
> > 
> > 
> > 
> > 
> >>    feature-specific information for the originator of a 
> call in the 
> >> case of
> >> Also, the core of your sentence seems to be "I'd be interested to 
> >> hear your thoughts on how transporting feature-specific 
> information 
> >> [...] compares with this case."  And I don't know what you mean by 
> >>    call-forwarding status) does so in as timely a method 
> as possible 
> >> to
> >>    think this is a general requirement for any feature 
> which has such 
> >> an
> >> where you could argue that timeliness can be sacrificed to some 
> >> degree to gain some other advantage.  But I'm sure we 
> fundamentally 
> >> agree here.
> >>
> >>    In particular to this discussion, I do not see this as 
> requiring 
> >> that
> >> is not possible".  As sort of a general property, any SIP agent 
> >> always has SUBSCRIBE/NOTIFY available.  But I think that you are 
> >> referring to a rather particular networking situation, and 
> mean that

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 11 Sep 2007 11:47:44 -0400

> We send the state of all sorts of pieces of information in SIP without requiring a prior subscription, but as part of an existing session/session-setup.

We've been over this. IMO it is inappropriate for an intermediate node 
to hyjack a request intended for some other purpose in order to convey 
this kind of status that isn't related in any way to the request.

Nor do I think there is reason to convey this information at all if the 
UA hasn't indicated an interest in receiving it.

	Paul

---

From: "Brian Stucker" <[email-masked]>
Date: Tue, 11 Sep 2007 11:08:15 -0500

> Sent: Tuesday, September 11, 2007 10:48 AM
> To: Stucker, Brian (RICH1:AR00)
> Cc: Huelsemann, Martin; [email-masked]; Alexeitsev, 
> D; [email-masked]
> >> If there is a mechanism for status change notification, 
> then there is 
> >> no reason for sending a warning that the service is still active.
> >>
> >> A warning such as you describe may be appropriate between 
> the UA and 
> >> the user of the UA. But the UA can deliver such warnings 
> based on its 
> >> awareness of the status.
> >>
> philosophy 
> endpoints as 
> generate 
> >> an appropriate UI based on its own design rather than the 
> design of 
> >> the network. For instance in this case it means that it 
> may deliver 
> >> the notification at a different point in time that just 
> when a call 
> >> attempt is made. Of course it could still deliver a 
> notification at 
> >> the time of a call attempt, using a tone, if that is the UI it 
> >> chooses to provide.
> > 
> > I believe the remaining question, though, is if there is a 
> way to convey this information using an ad-hoc means where 
> the UA had not previously subscribed, or known to subscribe 
> for a status change notification. Basically, it wouldn't be a 
> status *change* notification, but an FYI *notification* for  
> UAs that do not subscribe.
> > 
> > We send the state of all sorts of pieces of information in 
> SIP without requiring a prior subscription, but as part of an 
> existing session/session-setup.
> 
> We've been over this. IMO it is inappropriate for an 
> intermediate node to hyjack a request intended for some other 
> purpose in order to convey this kind of status that isn't 
> related in any way to the request.
> 
> Nor do I think there is reason to convey this information at 
> all if the UA hasn't indicated an interest in receiving it.

I think you're taking a very narrow view because you happen to not like
the service involved, i.e. "this kind of status" where the point was
that it's simply "status" and could be used for anything. The UA doesn't
indicate an interest in receiving much of the information it receives in
SIP messages. Take RFC-4474 for example: where did the UA indicate
interest in receiving an Indentity-Info header in the response to the
INVITE? Nowhere. It's even stated that inclusion of the information is
done opportunistically for UAs that support the mechanism in section 7.
Same thing here.

If you're drawing the line at not sending information to a UA because
they have not explicitly stated an interest in receiving such, then be
prepared to see an explosion of tokens in the supported header of the
INVITE as a result. Since there's no normative requirement on the UA to
do something at a protocol level with the information they receive in
the response, as opposed to something like PRACK, I don't see a
requirement for the UA to explicitly ask for the information beforehand
at a protocol level either.

But, let's say for sake of argument that we were to define a supported
header token for this information called "foo" that is specified to
opportunistically ask for any status notifications related to the "foo"
service in responses. It seems to me that at that time no SIP-level
argument could be made that would prevent a mechanism for reporting
"foo" in a header filed within a response message could be devised
unless you were to stipulate that the supported header is intended only
for features that are popular on the mailing list.

Regards,
Brian

---

From: "Huelsemann, Martin" <[email-masked]>
Date: Tue, 11 Sep 2007 18:19:02 +0200

Of course when you have received already status information about the diversion activation with SUB/NOT, a warning that the diversion is still active might be redundant. But also of course it wouldn't be harmful.  This concept is also used in the PSTN/ISDN, where you activate the diversion via a functional protocol and your terminal is aware of the status of the diversion. But, just to make sure, the service provider has the chance to inform you once again.

But there might be the general case where I haven't asked you for a certain information, but you want to inform me nevertheless, because you know that once I have this information it's very useful for me.
Similar the other issue we have discussed, Call Waiting. "This is a waiting call, it will take longer until I answer, so be careful and don't hang up too early." As you renember there we found the solution to use the Alert-Info header.

BR, Martin

> Von: Brian Stucker [mailto:[email-masked]] 
> Gesendet: Dienstag, 11. September 2007 17:04
> An: Paul Kyzivat; Hülsemann, Martin
> Cc: [email-masked]; Alexeitsev, Denis; [email-masked]
> Betreff: RE: notification/warning: call diversion active
> 
> 
>  
> 
> > >>    BTW- My earlier implication is that it is important 
> to the user 
> > >> that the
> > >>    mechanism used to report the desired state 
> information (in this 
> > >> case the

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 11 Sep 2007 12:57:07 -0400

Brian Stucker wrote:

> that it's simply "status" and could be used for anything.

The issue is that not only is the information not about the call, its 
not from the callee either.

Do you think it would be ok for your home proxy to insert 
*advertisements* into incoming messages? Maybe it could insert an 
Alert-Info that tells you it is time to pay your bill.

> The UA doesn't

I'm just objecting to hyjacking of the message by a third party to carry 
information not pertinent to the reason the message was sent.

I distinguish this from the case where a proxy might insert info that 
*is* pertinent to the message. E.g. a home proxy for a callee might 
insert an Alert-Info into an incoming request specifying a distinctive 
ring tone, based on a policy that classifies callers. That is providing 
information that *is* pertinent to the message.

> for features that are popular on the mailing list.

So if you want to use Alert-Info for this I think you are *allowed* do, 
without a Supported header. But I still think it is inappropriate.

	Paul

---

From: [email-masked]
Date: Tue, 11 Sep 2007 15:04:09 -0400

From: "Huelsemann, Martin" <[email-masked]>

   But there might be the general case where I haven't asked you for a
   certain information, but you want to inform me nevertheless,
   because you know that once I have this information it's very useful
   for me.

I'm having a hard time seeing how to make this work, really:

Some SIP server sends my UA information which (by our assumption) my
UA *isn't interested in knowing*.  However, we assume that by some
magic the UA *will tell me this information*, despite that we've
already assumed that the UA *isn't interested in it*.

The only way around this paradox -- that is, an implied *requirement*
of this proposal -- is that the UA will use the Alert-Info header to
provide an audio signal to the user, and that by manipulating the
Alert-Info header, the SIP server can get a few bits of status
information transmitted transparently through the UA.

In practice, no SIP phone I'm aware of pays attention to Alert-Info,
due to its well-known security problems.

Dale

---

From: [email-masked]
Date: Tue, 11 Sep 2007 15:07:35 -0400

I believe the remaining question, though, is if there is a way to
   convey this information using an ad-hoc means where the UA had not
   previously subscribed, or known to subscribe for a status change
   notification. Basically, it wouldn't be a status *change*
   notification, but an FYI *notification* for UAs that do not
   subscribe.

We have PUBLISH for that -- it's the "push" dual to SUBSCRIBE's
"pull".

   We send the state of all sorts of pieces of information in SIP
   without requiring a prior subscription, but as part of an existing
   session/session-setup.

True, but almost all of them are properties of the session in
question.  The few that describe one UA or the other are used to
convey to the other UA information that it may need to negotiate the
session.

Dale

---

From: [email-masked]
Date: Tue, 11 Sep 2007 15:12:18 -0400

So 'call diversion active' is not a status the user wants to be
   informed of, it's a warning the service provider wants to send to
   the user.

If the user doesn't want to be informed of it, and the service
provider wants to send it to the user, I expect that the UA will just
throw away this indication.

   But I think a solution that minimizes the signalling requirements
   (without an additional SUB/NOT transaction) would make it even more
   likely that the user receives this warning.

I think you have a real problem here, but you're getting it tangled up
in a proposed solution for a particular case.  The real problem being:
If the user wants to be informed of a number of bits of status
information, the number of different subscriptions to be maintained
can become a significant bandwidth drain.  But this is a problem that
has been discussed (in the more general case) at some length on the
SIP mailing lists, with some decent solutions.

Dale

---

From: "Brian Stucker" <[email-masked]>
Date: Tue, 11 Sep 2007 14:13:26 -0500

> Sent: Tuesday, September 11, 2007 2:04 PM
> To: [email-masked]
> Subject: [BLISS] Re: AW: notification/warning: call diversion active
> 
> Some SIP server sends my UA information which (by our 
> assumption) my UA *isn't interested in knowing*.  However, we 
> assume that by some magic the UA *will tell me this 
> information*, despite that we've already assumed that the UA 
> *isn't interested in it*.

No. There's information that the UA hasn't previously SUBSCRIBED to (for
whatever reason) that it may or may not be interested in, that the proxy
can supply to it that the UA may find useful. I would present to you
Exhibit A: RFC-4474 as an example of just such a mechanism.

> 
> The only way around this paradox -- that is, an implied 
> *requirement* of this proposal -- is that the UA will use the 
> Alert-Info header to provide an audio signal to the user, and 
> that by manipulating the Alert-Info header, the SIP server 
> can get a few bits of status information transmitted 
> transparently through the UA.

Or some other header, yes, just not the warning header as was originally
proffered.

> 
> In practice, no SIP phone I'm aware of pays attention to 
> Alert-Info, due to its well-known security problems.

There are SIP phones that pay attention to Alert-Info. They just don't
blithely accept whatever is sent to them or the work in concert with a
proxy that polices the contents of the header prior to delivery to the
UA.

If Alert-Info were used, you'd have to come up with a URN scheme to
support this. But, since the actual rendering of the information may
vary according to device characteristics and user preferences, perhaps
this is not the best header to use; unless you expect very little in the
way of rendering logic by the UA and wish to direct the rendering
behavior more precisely.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 11 Sep 2007 15:23:01 -0400

Without boiling the ocean on the general multiple subscription issue...

This kind of stuff (the forwarding indicator and other policy stuff that 
might affect the user) can all be handled using a subscription to 
configuration information.

	Paul

---

From: "Brian Stucker" <[email-masked]>
Date: Tue, 11 Sep 2007 14:23:04 -0500

> Sent: Tuesday, September 11, 2007 2:08 PM
> To: [email-masked]
> Subject: [BLISS] Re: notification/warning: call diversion active
> 
> We have PUBLISH for that -- it's the "push" dual to 
> SUBSCRIBE's "pull".

Thanks for the tip, I was a co-author of PUBLISH.

The UA is not an event state compositor in this case, and without
proxy-authentication of the PUBLISH request or some other means of
ensuring integrity, you'd be ill-advised to use this mechanism for this
purpose for security reasons. It's the same thing as implementing an
implicit subscription mechanisms except now the UA has to deal with
soft-states and the other responsibilities of an event state compositor.
What are you going to use for the expiration on the PUBLISH? Forever?
Are you going to periodically send this to the UA?

> question.  The few that describe one UA or the other are used 
> to convey to the other UA information that it may need to 
> negotiate the session.

This is a property of the session in question: hey originator, don't
forget that if the terminator tries to reach you at the number you're
calling from *for this session* that they may get forwarded to someplace
else, so if you need them to call you back, you may need to give them
another number to reach you at or disable your call forwarding.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 11 Sep 2007 15:25:06 -0400

Dale,

We are on the same page, except wrt Alert-Info. Even there I agree that 
hardly anything is going to honor A-I today.

What I have been advocating is that A-I be used to convey a URN. Then 
the UA can render an alert corresponding to the URN iff it knows what 
that URN means and is agreeable that it is appropriate for use as an alert.

Then somebod(y/ies) establish one, or several, URN schemes that are 
useful for identifying alerts.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 11 Sep 2007 17:42:39 -0400

> another number to reach you at or disable your call forwarding. 

If you can honestly spin it this way, then I agree you can make a case 
for it.

But is that *really* the intent?

The user of this phone honestly isn't interested in knowing he incoming 
calls are being diverted elsewhere except when making an outgoing call???

	Paul

---

From: "Brian Stucker" <[email-masked]>
Date: Tue, 11 Sep 2007 21:34:02 -0500

> Sent: Tuesday, September 11, 2007 4:43 PM
> Cc: [email-masked]; [email-masked]
> Subject: Re: [BLISS] Re: notification/warning: call diversion active
> 
> 
> 
> Brian Stucker wrote:
> 
> > calling from *for this session* that they may get forwarded to 
> > someplace else, so if you need them to call you back, you 
> may need to 
> > give them another number to reach you at or disable your 
> call forwarding.
> 
> If you can honestly spin it this way, then I agree you can 
> make a case for it.
> 
> The user of this phone honestly isn't interested in knowing 
> he incoming calls are being diverted elsewhere except when 
> making an outgoing call???

This isn't my feature, so I can't speak to how someone else might use
it. I'm speaking up because I happen to think that there is a potential
time and place for something like this within SIP without bending or
breaking the rules. If it didn't have anything to do with the session in
any way then I'd say, yep, it shouldn't be signaled as part of the
session setup, move along. For instance, I wouldn't agree that we should
warn the user that their password is going to expire in 30 days at the
beginning of every call.

To me, I view this notification as a reminder in addition to other
possible mechanisms that have been proposed. If a document were produced
that were to describe how to tell SIP UAs that they have call forwarding
enabled, I would expect it to have a way of detecting the configuration
information directly (perhaps through SUB/NOT to a config framework
package) in addition to this reminder.

Regards,
Brian

---

From: "Huelsemann, Martin" <[email-masked]>
Date: Wed, 12 Sep 2007 11:21:52 +0200

As Paul said, for 'call diversion active' the user can derive this information also from a subscription to his configuration. But, he has to be active to receive this warning, he has to subscribe to some states, and he has to take care that the subscription remains active.
But I think that's not the concept of a warning. I think in this case the "warned" is willing to passively receive this information, but it's the "warner" who actively sends this information. 
When my girlfriend tells to me "Be careful, the coffee is hot!", she wants to tell this to me independently from if I have asked for this or not. And she is nice enough to tell this to me even though she told me only a minute ago, that the status of my cup has changed from 'empty' to 'filled with hot coffee'. (Yes, sorry for this naive comparison.)

But I think there is a need to send information independently from actions of the receiver of this information (the only requirement would be the he is able to receive this information by being compatible to some spec), and of course these information/warnings should be send via the shortest path, which could be the response to a request.

These information of course should be strictly limited to warnings related to a service in which context the request or reponse is sent, perhaps with a mechanism similar to the warn-codes of the warning header. And of course requests that might result from the current request and which are influenced by the service (the recall to a contact with a activated diversion).

BR, Martin

> Gesendet: Mittwoch, 12. September 2007 04:34
> An: Paul Kyzivat
> Cc: [email-masked]; [email-masked]; Hülsemann, 
> Martin; Alexeitsev, Denis
> Betreff: RE: [BLISS] Re: notification/warning: call diversion active
> 
> 
>  
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 12 Sep 2007 09:44:12 -0400

Huelsemann, Martin wrote:
> As Paul said, for 'call diversion active' the user can derive this
> information also from a subscription to his configuration. But, he
> has to be active to receive this warning, he has to subscribe to some
> states, and he has to take care that the subscription remains active.
> But I think that's not the concept of a warning. I think in this
> case the "warned" is willing to passively receive this information,
> but it's the "warner" who actively sends this information. 

I agree, but I think I disagree on who the "warned" and the "warner" are.

I gather that you think the "warned" is the UA, and the "warner" is the 
home proxy of the UA. Or maybe that the "warned" is the user, the 
"warner" is the home proxy of the UA, and the UA itself is a passive 
bystander.

IMO the "warned" is the *user* of the UA. And the "warner" is the UA, 
because it controls the interface to the user. When *it* is the "warner" 
then it can determine the time and manner of the warning based on its 
own UI capabilities as well as the desires of its user as expressed in 
its configuration.

> When my girlfriend tells to me "Be careful, the coffee is hot!",
> she wants to tell this to me independently from if I have asked for
> this or not. And she is nice enough to tell this to me even though she
> told me only a minute ago, that the status of my cup has changed from
> 'empty' to 'filled with hot coffee'. (Yes, sorry for this naive
> comparison.)

Fine. But this is different from the coffeepot itself sending the words 
"Be careful, the coffee is hot!" through your girlfriend's mouth. Some 
enterprising coffeepot maker might think that was a good idea, but it 
isn't a great one. For instance it wouldn't be very effective if you 
didn't speak English.

Instead, it is your girlfriend that actively determines that the coffee 
is hot, perhaps by interacting with the pot, and then decides if and how 
to convey that information to you. She may make that determination when 
she pours the coffee you requested. Or she may have made that 
determination earlier.

> But I think there is a need to send information independently from
> actions of the receiver of this information (the only requirement
> would be the he is able to receive this information by being
> compatible to some spec), and of course these information/warnings
> should be send via the shortest path, which could be the response to
> a request.
> 
> These information of course should be strictly limited to warnings
> related to a service in which context the request or reponse is sent,
> perhaps with a mechanism similar to the warn-codes of the warning
> header. And of course requests that might result from the current
> request and which are influenced by the service (the recall to a
> contact with a activated diversion).

I agree that if you spin it as functionally related to the current call 
request then the information can be considered appropriate. In that case 
I would not object. (But I don't for a minute *believe* that relating 
this to the current call is a sensible feature. It certainly isn't the 
kind of indication *I* want from my service provider when I have call 
forwarding enabled.)

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 12 Sep 2007 15:05:05 -0400

inline.

	Thanks,
	Paul

Martin Taylor wrote:
> There's a lot of very interesting SIP philosophy in this email thread, but I think that there are also some practical realities worth talking about.
> 
> The good old PSTN has, for many years, offered a service called Unconditional Call Forwarding (aka Call Forwarding Variable).  It's very widely used, and very useful.  In the early years of deploying this service, service providers got feedback from their subscribers that using this service can have unfortunate consequences.  Example:  I go away for a few days to look after my mother, who is sick, and I set my home phone to forward all calls to my mother's number.  Then I come home.  And I'm expecting a call, but I've forgotten that call forwarding is currently active.  I wonder why my phone's not ringing.  And the people calling me wonder why they get connected to my mother.

Yup. Its a real problem.

> As I'm sure you all know, one of the solutions that the industry cooked up to this is to apply a brief burst of ringing to my phone whenever a call to my phone is forwarded.  When I hear this burst of ringing ("ringsplash"), it jogs my memory and I recall that I previously enabled call forwarded, so I dial the feature code to disable it. 

Given a certain set of assumed limitations its not such a bad solution.

> Another solution that is in use today is to give me stutter dial tone when I go off hook if call forwarding is activated.  This is not such a good solution, for a couple of reasons -- firstly, I have to go off-hook to get the reminder; and secondly, stutter dial tone is often used for other purposes, such as to indicate that I have a voice message waiting.

The need to go off hook is a killer. And yet the solution the current 
discussion has been focusing on has that limitation. That is one of the 
reasons I don't believe it is a plausible use case.

> In my experience, the ringsplash option is widely chosen by those subscribers who use the Unconditional Call Forwarding service.  There is little doubt that it is considered useful, and that figuring out how to provide some equivalent function to users of SIP UAs is worth doing. 

Yes, I can understand pressure to do this, at least if something else 
better can't be done.

Note that the current discussion *does not* address this particular 
behavior.

> Not least because many of us see an enormous opportunity to apply SIP in solutions that are intended to provide a replacement to the legacy PSTN, where one of the fundamental requirements is to be able to preserve legacy POTS phone behavior (in addition to being able to do wondrous new things that are enabled by intelligent SIP terminals).

We should be able to do *better* than this with SIP.

> At least one other organization has generated a specification for a solution to this problem: CableLabs, with their Residential SIP Telephony (RST) application.

I am familiar with that work, though I haven't studied the final specs.

> In the RST application, in common with many real-world implementations of SIP intended to offer a public telephony service, the call forwarding service is applied in the core network, typically by means of a B2BUA.  If I have Unconditional Call Forwarding enabled, then the call is never even presented to my UA.  The call is intercepted by the B2BUA, and re-directed to the destination that I specified when I activated the service.  To emulate ringsplash, the B2BUA needs to signal something to my UA every time such a forwarding event occurs.  It should not send me an INVITE, because there is no intention to set up any kind of session to my UA.
> 
> The solution chosen by CableLabs is to require the UA to subscribe to the ua-profile event.  The state of "ua-profile" is defined to include not just the activation status of the Unconditional Call Forwarding service, but also the count of calls that have been forwarded since I activated the service.  Every time the B2BUA forwards a call, it increments this count, which results in a change in the state of ua-profile.  The owner of the subscription to ua-profile, typically the B2BUA itself, therefore sends a NOTIFY to my UA that includes this changed state.  The UA remembers the last value of the forwarded calls count that it received via such a NOTIFY, and if the new value is greater than the last value, it applies ringsplash to the phone.

Yup. I knew about that. Its difficult to know how much of these private 
efforts it is ok to discuss here.

If you insist on getting the ringsplash for each call, then I think it 
is a reasonable approach. But that is a limited solution, because it 
means you don't know about the forwarding until *after* you have missed 
the call. And you might not hear it at all, even though you are home. 
(Its not as insistent as a ringing phone.)

IMO it would be much better if the phone provided an indication of this 
status even when there is no incoming call attempt. For instance it 
could flash a light on the phone (analogous to, but distinct from, the 
message waiting indicator light.)

There is also no reason why the phone can't do several of these:
- flash a light
- display a notice on a screen if it has one
- give you a stutter dial tone when you pick up the phone
   (or actually say "call forwarding enabled")
- do ringsplash when a call is forwarded
- if you insist, provide an altered ringback when
   placing an outgoing call. (But this seems entirely
   redundant if you do the stutter dialtone.

These and other indications can all be enabled by the *same* mechanism: 
subscribe to the ua-profile event package. Have something in there to 
indicate the call forward enable status, as well as the count of 
forwarded calls. That gives you ongoing knowledge of the current 
forwarding state which can be rendered in many of the ways above, as 
well as awareness of a call being forwarded which can trigger the 
ringsplash.

> A disclaimer here . . . I personally had nothing to do with the definition of this solution, and I'm not specifically promoting it to this email list.  But it does the job, and IMHO it makes perfectly valid use of the SUBSCRIBE/NOTIFY mechanism.  In other words, I do not think that it bends or breaks or extends existing SIP protocol definitions, which has to be in its favor.
> 
> Martin
> 
> 
> Sent: 12 September 2007 14:44
> To: Huelsemann, Martin
> Cc: [email-masked]; Alexeitsev, D
> Subject: Re: AW: [BLISS] Re: notification/warning: call diversion active
> 
> 
> 
>> information also from a subscription to his configuration. But, he has 
>> to be active to receive this warning, he has to subscribe to some 
>> But I think that's not the concept of a warning. I think in this case 
>> the "warned" is willing to passively receive this information, but 
>> it's the "warner" who actively sends this information.
> 
> I gather that you think the "warned" is the UA, and the "warner" is the home proxy of the UA. Or maybe that the "warned" is the user, the "warner" is the home proxy of the UA, and the UA itself is a passive bystander.
> 
> IMO the "warned" is the *user* of the UA. And the "warner" is the UA, because it controls the interface to the user. When *it* is the "warner" 
> then it can determine the time and manner of the warning based on its own UI capabilities as well as the desires of its user as expressed in its configuration.
> 
>> When my girlfriend tells to me "Be careful, the coffee is hot!", she 
>> wants to tell this to me independently from if I have asked for this 
>> or not. And she is nice enough to tell this to me even though she told 
>> me only a minute ago, that the status of my cup has changed from 
> Fine. But this is different from the coffeepot itself sending the words "Be careful, the coffee is hot!" through your girlfriend's mouth. Some enterprising coffeepot maker might think that was a good idea, but it isn't a great one. For instance it wouldn't be very effective if you didn't speak English.
> 
> Instead, it is your girlfriend that actively determines that the coffee is hot, perhaps by interacting with the pot, and then decides if and how to convey that information to you. She may make that determination when she pours the coffee you requested. Or she may have made that determination earlier.
> 
>> should be send via the shortest path, which could be the response to a 
>> request.
>>
> I agree that if you spin it as functionally related to the current call request then the information can be considered appropriate. In that case I would not object. (But I don't for a minute *believe* that relating this to the current call is a sensible feature. It certainly isn't the kind of indication *I* want from my service provider when I have call forwarding enabled.)
> 
> 	Paul
> 
>> BR, Martin
>>
>>
>>
>>
>>
>>> Cc: [email-masked]; [email-masked]; Hülsemann, Martin; 
>>> Alexeitsev, Denis
>>>> If you can honestly spin it this way, then I agree you can make a 
>>>> case for it.
>>>>
>>>> The user of this phone honestly isn't interested in knowing he 
>>>> incoming calls are being diverted elsewhere except when making an 
>>>> outgoing call???
>>> it. I'm speaking up because I happen to think that there is a 
>>> potential time and place for something like this within SIP without 
>>> bending or breaking the rules. If it didn't have anything to do with 
>>> the session in any way then I'd say, yep, it shouldn't be signaled as 
>>> part of the session setup, move along. For instance, I wouldn't agree 
>>> that we should warn the user that their password is going to expire 
>>> in 30 days at the beginning of every call.
>>>
>>> possible mechanisms that have been proposed. If a document were 
>>> produced that were to describe how to tell SIP UAs that they have 
>>> call forwarding enabled, I would expect it to have a way of detecting 
>>> the configuration information directly (perhaps through SUB/NOT to a 
>>> config framework

---

From: [email-masked]
Date: Wed, 12 Sep 2007 23:14:51 -0400

Martin Taylor writes:
[somewhat edited and rearranged]
> There's a lot of very interesting SIP philosophy in this email
> thread, but I think that there are also some practical realities
> worth talking about.

> As I'm sure you all know, one of the solutions that the industry
> cooked up to this is to apply a brief burst of ringing to my phone
> whenever a call to my phone is forwarded.  When I hear this burst of
> ringing ("ringsplash"), it jogs my memory and I recall that I
> previously enabled call forwarded, so I dial the feature code to
> disable it.

> Another solution that is in use today is to give me stutter dial
> tone when I go off hook if call forwarding is activated.  This is
> not such a good solution, for a couple of reasons -- firstly, I have
> to go off-hook to get the reminder; and secondly, stutter dial tone
> is often used for other purposes, such as to indicate that I have a
> voice message waiting.

> Not least because many of us see an enormous opportunity to apply
> SIP in solutions that are intended to provide a replacement to the
> legacy PSTN, where one of the fundamental requirements is to be able
> to preserve legacy POTS phone behavior (in addition to being able to
> do wondrous new things that are enabled by intelligent SIP
> terminals).

That's a valid concern.  But in that regard, the idea of indicating
call forwarding active by modifying the ringback of a call does not
satisfy the requirement.

If one wanted a stutter dial tone, the UA could easily apply one if it
maintained awareness of the call-forwarding state.  Indeed, in order
to apply stutter dial tone, the UA *has* to maintain awareness of the
call-forwarding state, since it generates the dial tone before it
interacts with the network to set up the call.

If one wanted a ringsplace when a call was forwarded, one could either
push information to the UA (e.g., through PUBLISH) and have the UA
generate the ringsplash, or some agent could generate a quick
INVITE/CANCEL pair.

Dale

---

From: "Huelsemann, Martin" <[email-masked]>
Date: Thu, 13 Sep 2007 11:57:43 +0200

The problem really is the Unconditional Call Forwarding, which you have forgotten that you've activated it. The question is, how can you be made aware that it's activated? And of course if it is possible to give a former PSTN/ISDN user the same experience for his call diversion service that he was used to from the PSTN/ISDN.

There were several ways how the user could get this information, one that is new to me is the ringsplash. One problem with this really is that you would have to send an INVITE, to other problem I see is that you have to be near to the phone to notice this ringsplash, unless it is also stored in the call-list of your phone.

In the PSTN/ISDN there are several solutions for the problem:

1) your phone stores the status of your call diversion which you have activated via a functional protocol, some display field or light informs you about the active diversion; SIP solution: HTTP/XCAP, SUB/NOT, others

2) every time a diversion occurs you receive a notification in a call-unrelated message, again the information somehow rendered to you by your phone; SIP solution:

3) every time you make a call attempt you reveive a notification in a call-related message; SIP solutions discussed: SUB/NOT or a header in the response to the INVITE.

4) special dial-tone

And I really think the "warner" is the service provider, and the "warned" is the service user. Perhaps this "warning" is not needed as urgently as in the PSTN, where you can also activate the diversion via a stimulus procol, and so your phone does not know about the status of the diversion. 
But I think it still makes sense regarding some security aspects. Perhaps someone else has somehow managed to activate the diversion for your account with a malicious intend, or more likely you have activated the diversion for your account from another phone and so the client you're using now has not subscribed to the diversion status, then this notification independent from a subscription would still make sense.

BR, Martin

> Gesendet: Donnerstag, 13. September 2007 05:15
> An: [email-masked]
> Betreff: Re: AW: [BLISS] Re: notification/warning: call 
> diversion active
> 
> 
> Martin Taylor writes:

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 13 Sep 2007 09:55:29 -0400

I discussed many of the points below in my previous posting. I'm not 
going to repeat all of that here.

But something I think we do need to settle on is who/what is warning 
who/what.

- I have the feeling, supported by your last statement below, that you 
believe it is a network node (acting for the SP) that is warning the 
*user* of the UA, using the UA as a dumb pipe for conveying the warning, 
possibly without understanding that is what it is doing.

- I (and most likely Dale and other sip-heads) think that it is the UA 
that is responsible for warning the user of the UA. To do so, the UA 
must have awareness of the conditions that deserve generating a warning. 
For that, the UA needs access to the policy that is governing forwarding 
policy, even if that policy is being enforced elsewhere. And for the 
ringsplash, the UA needs access to information that a call has been 
forwarded.

The first approach is entirely consistent with PSTN architecture and 
philosophy, so its not surprising that it comes up. It is however 
inconsistent with the basic sip philosophy of putting more intelligence 
into the endpoints and only doing in the network that which can't be 
done in the endpoints.

More below.

> But I think it still makes sense regarding some security aspects. Perhaps someone else has somehow managed to activate the diversion for your account with a malicious intend, or more likely you hav…

*If* you believe the phone is responsible for generating the warning, 
then it makes sense to assume that the phone will take the necessary 
steps to be aware of the condition.

If a phone has not done this, then it must not support the feature of 
delivering call forwarding enabled notification. In that case, if you 
want that feature you should buy a different phone.

Now it may be that there will be a lot of sip devices out there that 
aren't smart enough to provide this feature. Then the question is 
whether the appropriate solution is to implement the feature in the 
network, *assuming* that the UAs are dumb, or to implement the feature 
assuming smart phones and live with the fact that the dumb phones won't 
get the feature.

IMO there is a middle ground between those two extremes:

Dumb phones can be configured with a "helper" that colludes with the 
phone to provide the smart features the phone is unable to do itself. To 
the rest of the system the combination of (helper + dumb phone) is 
viewed as a fully capable phone. The helper can reside anywhere: as a 
physical appendage to the phone, in a special dedicated server in the 
access network, collocated with the "home proxy", or whatever.

The communication between the dumb phone and the helper can sip or sip 
and RTP, or might involve other things (http?) for some classes of 
device. Some of the tricks that have been suggested in this thread for 
tunneling warnings to the user without awareness of the UA might be 
appropriate here.

Doing this would require a means to identify those devices requiring a 
helper and doing the necessary configuration to associate them.

Anyway, that is a thought.

	Thanks,
	Paul

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Fri, 14 Sep 2007 10:07:16 +0200

Also in line some comments

Keith 

> Sent: Wednesday, September 12, 2007 8:05 PM
> To: Martin Taylor
> Cc: [email-masked]; Alexeitsev, D; Huelsemann,Martin
> > There's a lot of very interesting SIP philosophy in this 
> email thread, but I think that there are also some practical 
> realities worth talking about.
> > 
> > The good old PSTN has, for many years, offered a service 
> called Unconditional Call Forwarding (aka Call Forwarding 
> Variable).  It's very widely used, and very useful.  In the 
> early years of deploying this service, service providers got 
> feedback from their subscribers that using this service can 
> have unfortunate consequences.  Example:  I go away for a few 
> days to look after my mother, who is sick, and I set my home 
> phone to forward all calls to my mother's number.  Then I 
> come home.  And I'm expecting a call, but I've forgotten that 
> call forwarding is currently active.  I wonder why my phone's 
> not ringing.  And the people calling me wonder why they get 
> connected to my mother.
> 
> Yup. Its a real problem.
> 
> > As I'm sure you all know, one of the solutions that the 
> industry cooked up to this is to apply a brief burst of 
> ringing to my phone whenever a call to my phone is forwarded. 
>  When I hear this burst of ringing ("ringsplash"), it jogs my 
> memory and I recall that I previously enabled call forwarded, 
> so I dial the feature code to disable it. 
> 
This essentially is the ISDN solution to the problem. There is a configurable option in the protocol that allows the forwarding terminal to receive a protocol element giving the call details every time a call is forwarded. What the terminal does with it is not defined, but it could be used for any kind of audible or visual indication.

> > Another solution that is in use today is to give me stutter 
> dial tone when I go off hook if call forwarding is activated. 
>  This is not such a good solution, for a couple of reasons -- 
> firstly, I have to go off-hook to get the reminder; and 
> secondly, stutter dial tone is often used for other purposes, 
> such as to indicate that I have a voice message waiting.
> 
> The need to go off hook is a killer. And yet the solution the 
> current discussion has been focusing on has that limitation. 
> That is one of the reasons I don't believe it is a plausible use case.
> 
As I have already indicated, the previous functional protocol to SIP, i.e. that for the ISDN, did not specify this.

> > In my experience, the ringsplash option is widely chosen by 
> those subscribers who use the Unconditional Call Forwarding 
> service.  There is little doubt that it is considered useful, 
> and that figuring out how to provide some equivalent function 
> to users of SIP UAs is worth doing. 
> 
> Yes, I can understand pressure to do this, at least if 
> something else better can't be done.
> 
> Note that the current discussion *does not* address this 
> particular behavior.
> 
> > Not least because many of us see an enormous opportunity to 
> apply SIP in solutions that are intended to provide a 
> replacement to the legacy PSTN, where one of the fundamental 
> requirements is to be able to preserve legacy POTS phone 
> behavior (in addition to being able to do wondrous new things 
> that are enabled by intelligent SIP terminals).
> 
> > At least one other organization has generated a 
> specification for a solution to this problem: CableLabs, with 
> their Residential SIP Telephony (RST) application.
> 
> > In the RST application, in common with many real-world 
> implementations of SIP intended to offer a public telephony 
> service, the call forwarding service is applied in the core 
> network, typically by means of a B2BUA.  If I have 
> Unconditional Call Forwarding enabled, then the call is never 
> even presented to my UA.  The call is intercepted by the 
> B2BUA, and re-directed to the destination that I specified 
> when I activated the service.  To emulate ringsplash, the 
> B2BUA needs to signal something to my UA every time such a 
> forwarding event occurs.  It should not send me an INVITE, 
> because there is no intention to set up any kind of session to my UA.
> > 
> > The solution chosen by CableLabs is to require the UA to 
> subscribe to the ua-profile event.  The state of "ua-profile" 
> is defined to include not just the activation status of the 
> Unconditional Call Forwarding service, but also the count of 
> calls that have been forwarded since I activated the service. 
>  Every time the B2BUA forwards a call, it increments this 
> count, which results in a change in the state of ua-profile.  
> The owner of the subscription to ua-profile, typically the 
> B2BUA itself, therefore sends a NOTIFY to my UA that includes 
> this changed state.  The UA remembers the last value of the 
> forwarded calls count that it received via such a NOTIFY, and 
> if the new value is greater than the last value, it applies 
> ringsplash to the phone.
> 
> Yup. I knew about that. Its difficult to know how much of 
> these private efforts it is ok to discuss here.
> 
> If you insist on getting the ringsplash for each call, then I 
> think it is a reasonable approach. But that is a limited 
> solution, because it means you don't know about the 
> forwarding until *after* you have missed the call. And you 
> might not hear it at all, even though you are home. 
The only service definitions I know of for call forwarding do not give the user a chance for interaction. If the user has chance for interaction it becomes either call deflection (diverted before answer) or call transfer (after answer)

> IMO it would be much better if the phone provided an 
> indication of this status even when there is no incoming call 
> attempt. For instance it could flash a light on the phone 
> (analogous to, but distinct from, the message waiting 
> indicator light.)
> 
> subscribe to the ua-profile event package. Have something in 
> there to indicate the call forward enable status, as well as 
> the count of forwarded calls. That gives you ongoing 
> knowledge of the current forwarding state which can be 
> rendered in many of the ways above, as well as awareness of a 
> call being forwarded which can trigger the ringsplash.
> 
> > A disclaimer here . . . I personally had nothing to do with 
> the definition of this solution, and I'm not specifically 
> promoting it to this email list.  But it does the job, and 
> IMHO it makes perfectly valid use of the SUBSCRIBE/NOTIFY 
> mechanism.  In other words, I do not think that it bends or 
> breaks or extends existing SIP protocol definitions, which 
> has to be in its favor.
> > 
> > Martin
> > 
> > 
> > I gather that you think the "warned" is the UA, and the 
> "warner" is the home proxy of the UA. Or maybe that the 
> "warned" is the user, the "warner" is the home proxy of the 
> UA, and the UA itself is a passive bystander.
> > 
> > IMO the "warned" is the *user* of the UA. And the "warner" 
> is the UA, because it controls the interface to the user. 
> When *it* is the "warner" 
> > then it can determine the time and manner of the warning 
> based on its own UI capabilities as well as the desires of 
> its user as expressed in its configuration.
> > 
> >> or not. And she is nice enough to tell this to me even though she 
> > Fine. But this is different from the coffeepot itself 
> sending the words "Be careful, the coffee is hot!" through 
> your girlfriend's mouth. Some enterprising coffeepot maker 
> might think that was a good idea, but it isn't a great one. 
> For instance it wouldn't be very effective if you didn't 
> speak English.
> > 
> > Instead, it is your girlfriend that actively determines 
> that the coffee is hot, perhaps by interacting with the pot, 
> and then decides if and how to convey that information to 
> you. She may make that determination when she pours the 
> coffee you requested. Or she may have made that determination earlier.
> > 
> > I agree that if you spin it as functionally related to the current 
> > call request then the information can be considered appropriate. In 
> > that case I would not object. (But I don't for a minute 
> *believe* that 
> > relating this to the current call is a sensible feature. It 
> certainly 
> > isn't the kind of indication *I* want from my service 
> provider when I 
> > have call forwarding enabled.)
> > 
> > 	Paul
> > 
> >> BR, Martin
> >>
> >>
> >>
> >>
> >>
> >>> This isn't my feature, so I can't speak to how someone else might 
> >>> use it. I'm speaking up because I happen to think that there is a 
> >>> the session in any way then I'd say, yep, it shouldn't be 
> signaled 
> >>> as part of the session setup, move along. For instance, I 
> wouldn't 
> >>> agree that we should warn the user that their password is 
> going to 
> >>> expire in 30 days at the beginning of every call.
> >>>
> >>> call forwarding enabled, I would expect it to have a way of 
> >>> detecting the configuration information directly (perhaps through 
> >>> SUB/NOT to a config framework

---

From: "Martin Taylor" <[email-masked]>
Date: Wed, 12 Sep 2007 19:07:15 +0100

As I'm sure you all know, one of the solutions that the industry cooked up to this is to apply a brief burst of ringing to my phone whenever a call to my phone is forwarded.  When I hear this burst of ringing ("ringsplash"), it jogs my memory and I recall that I previously enabled call forwarded, so I dial the feature code to disable it.  Another solution that is in use today is to give me stutter dial tone when I go off hook if call forwarding is activated.  This is not such a good solution, for a couple of reasons -- firstly, I have to go off-hook to get the reminder; and secondly, stutter dial tone is often used for other purposes, such as to indicate that I have a voice message waiting.

In my experience, the ringsplash option is widely chosen by those subscribers who use the Unconditional Call Forwarding service.  There is little doubt that it is considered useful, and that figuring out how to provide some equivalent function to users of SIP UAs is worth doing.  Not least because many of us see an enormous opportunity to apply SIP in solutions that are intended to provide a replacement to the legacy PSTN, where one of the fundamental requirements is to be able to preserve legacy POTS phone behavior (in addition to being able to do wondrous new things that are enabled by intelligent SIP terminals).

Martin

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: 12 September 2007 14:44
To: Huelsemann, Martin
Cc: [email-masked]; Alexeitsev, D
Subject: Re: AW: [BLISS] Re: notification/warning: call diversion active

	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 19 Sep 2007 11:59:47 +0100

Catching up after being away.

I seem to sense a consensus that there is a requirement for a UA to be aware of the status of call forwarding unconditional (or maybe various types of conditional call forwarding too, although that seems to be outside the scope of the present thread). It can then use this information to advise the user in whatever way is appropriate. To me, things like stutter dial tone or other indications at the time of outgoing call establishment are old fashioned - for a long time I have had phones on my desk that permanently indicate my call forwarding status. Indeed I very rarely hear dial tone, let along stutter dial tone, because I dial from an address book or hot key or missed call list, or failing that I key my digits before going "off-hook" (or activating headset or speakerphone or whatever). My cellphone never gives me dialtone. So PLEASE let's leave the UI to the UA, and just consider how the UA becomes aware of the information.

So if this is the requirement (to keep the UA informed), let's consider solutions.

I have a certain sympathy with Martin Huelsemann's contention that a SUBSCRIBE/NOTIFY mechanism is too heavy in signalling. For example, dialog-stateful proxies / B2BUAs seem to be sensitive to lots of long-term dialogs from every UA.

I like the idea of a URN, but I don't really like putting it Alert-Info in a response to INVITE, for all the reasons stated by various contributors to this thread.

What about a REFER request, referring to a URN that indicates call forwarding status? URN parameters could even indicate conditions, if we need to extend this to conditional call forwarding. Something similar has been proposed by others in the past in the context of remote call control.

John

> Sent: 13 September 2007 14:55
> To: Huelsemann, Martin
> Cc: [email-masked]
> Subject: Re: AW: AW: [BLISS] Re: notification/warning: call 
> diversion active
> 
> > The problem really is the Unconditional Call Forwarding, 
> which you have forgotten that you've activated it. The 
> question is, how can you be made aware that it's activated? 
> And of course if it is possible to give a former PSTN/ISDN 
> user the same experience for his call diversion service that 
> he was used to from the PSTN/ISDN.
> > 
> > There were several ways how the user could get this 
> information, one that is new to me is the ringsplash. One 
> problem with this really is that you would have to send an 
> INVITE, to other problem I see is that you have to be near to 
> the phone to notice this ringsplash, unless it is also stored 
> in the call-list of your phone.
> > 
> > 1) your phone stores the status of your call diversion 
> which you have activated via a functional protocol, some 
> display field or light informs you about the active 
> diversion; SIP solution: HTTP/XCAP, SUB/NOT, others
> > 
> > 2) every time a diversion occurs you receive a notification 
> in a call-unrelated message, again the information somehow 
> rendered to you by your phone; SIP solution:
> > 
> > 3) every time you make a call attempt you reveive a 
> notification in a call-related message; SIP solutions 
> discussed: SUB/NOT or a header in the response to the INVITE.
> > 
> > 4) special dial-tone
> > 
> > 
> > And I really think the "warner" is the service provider, 
> and the "warned" is the service user. Perhaps this "warning" 
> is not needed as urgently as in the PSTN, where you can also 
> activate the diversion via a stimulus procol, and so your 
> phone does not know about the status of the diversion. 
> > But I think it still makes sense regarding some security 
> aspects. Perhaps someone else has somehow managed to activate 
> the diversion for your account with a malicious intend, or 
> more likely you have activated the diversion for your account 
> from another phone and so the client you're using now has not 
> subscribed to the diversion status, then this notification 
> independent from a subscription would still make sense.
>

---

From: "Steve Langstaff" <[email-masked]>
Date: Wed, 19 Sep 2007 04:51:15 -0700

I like the SUBSCRIBE/NOTIFY proposal - it seems to be the right tool for
the job.

Might I suggest that we take a leaf out of RFC3842, and have (at least)
a boolean indication that there is some sort of call diversion active?

E.g. where RFC3842 says:
"The status line allows messaging systems or messaging gateways to
provide
 the traditional boolean message waiting notification.

      Messages-Waiting: yes
"

BLISS-CALL-DIVERSION could say:
"The status line allows call handling systems to provide
 the traditional boolean call diversion notification.

      Call-Diversion: yes
"

> From: Elwell, John [mailto:[email-masked]] 
> Sent: 19 September 2007 12:00
> To: Paul Kyzivat; Huelsemann, Martin
> Cc: [email-masked]
> Subject: RE: AW: AW: [BLISS] Re: notification/warning: call 
> diversion active
> 
> I seem to sense a consensus that there is a requirement for a 
> UA to be aware of the status of call forwarding unconditional 
> (or maybe various types of conditional call forwarding too, 
> although that seems to be outside the scope of the present 
> thread). It can then use this information to advise the user 
> in whatever way is appropriate. To me, things like stutter 
> dial tone or other indications at the time of outgoing call 
> establishment are old fashioned - for a long time I have had 
> phones on my desk that permanently indicate my call 
> forwarding status. Indeed I very rarely hear dial tone, let 
> along stutter dial tone, because I dial from an address book 
> or hot key or missed call list, or failing that I key my 
> digits before going "off-hook" (or activating headset or 
> speakerphone or whatever). My cellphone never gives me 
> dialtone. So PLEASE let's leave the UI to the UA, and just 
> consider how the UA becomes aware of the information.
> 
> I have a certain sympathy with Martin Huelsemann's contention 
> that a SUBSCRIBE/NOTIFY mechanism is too heavy in signalling. 
> For example, dialog-stateful proxies / B2BUAs seem to be 
> sensitive to lots of long-term dialogs from every UA.
> 
> I like the idea of a URN, but I don't really like putting it 
> Alert-Info in a response to INVITE, for all the reasons 
> stated by various contributors to this thread.
> 
> What about a REFER request, referring to a URN that indicates 
> call forwarding status? URN parameters could even indicate 
> conditions, if we need to extend this to conditional call 
> forwarding. Something similar has been proposed by others in 
> the past in the context of remote call control.
> 
> John

---

From: "Martin Taylor" <[email-masked]>
Date: Wed, 19 Sep 2007 13:23:23 +0100

>PLEASE let's leave the UI to the UA, and just consider how the UA becomes aware of the information.

All the discussions I have seen on this thread appear to assume that the UA is an intelligent device with the means to indicate the current status of call forwarding visually (for example by means of text or graphical content on a visual display).  If we are talking about telephone terminals that support SIP natively, then that seems to be a perfectly reasonable assumption.  But there is one very important case for which this is not true: UAs that are in the form of analog telephone adapters.

"Why look back?"  I hear you all say.  "Why would you use an analog handset when you can have a native SIP device that offers all sorts of smart features?"

Two key reasons that I'm aware of (although there are no doubt others):

1)  Incumbent wireline network operators are replacing their legacy TDM infrastructure with VoIP networks, in a manner that is transparent to their subscribers.  Subscribers will continue to use analog phones connected to copper loops, but those loops now terminate in access gateways that convert to VoIP.  Historically, those access gateways have been controlled by media gateway control protocols such as MGCP and Megaco, but increasingly service providers are choosing SIP-based access gateways.

2)  Competing network operators (for example cable operators or broadband network providers) are offering residential and business telephony services delivered to the customer premises over broadband, with connectivity to the subscriber's existing analog telephone equipment (for example, cordless handsets or small key systems) via integrated access devices that provide POTS ports.  In almost all cases, such service providers are choosing SIP-based integrated access devices.

In both cases, there is advantage to service providers in allowing subscribers to connect their existing equipment to the service, and in delivering an exact equivalent of the familiar POTS service.  Of course, service providers are also taking advantage of the power of SIP application servers to deliver a bunch of new capabilities, but that's another story . . . legacy POTS equivalence is table stakes.

In the POTS world, there are two common ways of warning a subscriber that call diversion is active: by means of ringsplash, where a brief burst of ringing is applied to the phone whenever an incoming call is diverted by the service; and by means of stutter dial tone.  Of these two, ringsplash is probably the more widely deployed.

In the absence of public interoperability specifications, vendors are being forced to come up with proprietary solutions to problems such as how to support ringsplash to UAs that are in the form of analog telephone adapters.  My understanding of the BLISS charter is to make this unnecessary, by identifying this type of problem and defining a recommended SIP signaling solution to it.

The above is a long and roundabout way of saying that we don't just need a means of informing the UA that call forwarding is active, we also need a means of informing the UA of call forwarding events as they happen.  Otherwise we can't deliver POTS equivalence.

I would agree with the view that SUBSCRIBE/NOTIFY is rather a heavyweight solution to this problem.  I would argue that the solution adopted by PacketCable (which, by the way, is in the public domain -- specification at http://www.packetcable.com/downloads/specs/PKT-SP-RSTF-I01-060927.pdf) is ugly, not only because it makes use of SUBSCRIBE/NOTIFY, but also because the event to which the UA is supposed to subscribe (ua-profile) is intended for remote management of UA configuration, and should not be subverted for the purposes of notifying events that take place on the call processing path.

The suggested use of REFER with a URN would appear to be worth further discussion.  The value of the URN could indicate the state of any network-provided feature, and could also indicate call forwarding events so as to support the application of ringsplash.  The problem with REFER is the requirement on the recipient to NOTIFY the requester of the progress of the REFER request.  This generates at least two additional messages (NOTIFY, 200 OK) which serve no functional purpose.

An alternative approach might be to use NOTIFY, but with an implicit subscription.  This is such common practice that it can almost be considered a de facto standard.  For example, many SIP phones do not SUBSCRIBE to message-summary but expect to be sent NOTIFY for message-summary events to drive message waiting indication on the phone.

Martin 

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: 19 September 2007 12:00
To: Paul Kyzivat; Huelsemann, Martin
Cc: [email-masked]
Subject: RE: AW: AW: [BLISS] Re: notification/warning: call diversion active

John

> Subject: Re: AW: AW: [BLISS] Re: notification/warning: call diversion 
> active
> 
> *user* of the UA, using the UA as a dumb pipe for conveying the 
> warning, possibly without understanding that is what it is doing.
> 
> For that, the UA needs access to the policy that is governing 
> forwarding policy, even if that policy is being enforced elsewhere. 
> And for the ringsplash, the UA needs access to information that a call 
> has been forwarded.
> 
> inconsistent with the basic sip philosophy of putting more 
> intelligence into the endpoints and only doing in the network that 
> which can't be done in the endpoints.
> 
> More below.
> 
> which you have forgotten that you've activated it. The question is, 
> how can you be made aware that it's activated?
> And of course if it is possible to give a former PSTN/ISDN user the 
> same experience for his call diversion service that he was used to 
> from the PSTN/ISDN.
> > 
> information, one that is new to me is the ringsplash. One problem with 
> this really is that you would have to send an INVITE, to other problem 
> I see is that you have to be near to the phone to notice this 
> ringsplash, unless it is also stored in the call-list of your phone.
> > 
> which you have activated via a functional protocol, some display field 
> or light informs you about the active diversion; SIP solution: 
> HTTP/XCAP, SUB/NOT, others
> > 
> in a call-unrelated message, again the information somehow rendered to 
> you by your phone; SIP solution:
> > 
> is not needed as urgently as in the PSTN, where you can also activate 
> the diversion via a stimulus procol, and so your phone does not know 
> about the status of the diversion.
> aspects. Perhaps someone else has somehow managed to activate the 
> diversion for your account with a malicious intend, or more likely you 
> have activated the diversion for your account from another phone and 
> so the client you're using now has not subscribed to the diversion 
> status, then this notification independent from a subscription would 
> still make sense.
> 
> assuming smart phones and live with the fact that the dumb phones 
> won't get the feature.
> 
> phone to provide the smart features the phone is unable to do itself. 
> To the rest of the system the combination of (helper + dumb phone) is 
> >> Betreff: Re: AW: [BLISS] Re: notification/warning: call diversion 
> >> active
> >>
> >>
> >> Martin Taylor writes:

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 19 Sep 2007 14:24:39 +0100

Martin,

A couple of comments below.

John 

> From: Martin Taylor [mailto:[email-masked]] 
> Sent: 19 September 2007 13:23
> To: Elwell, John
> Cc: [email-masked]
> All the discussions I have seen on this thread appear to 
> assume that the UA is an intelligent device with the means to 
> indicate the current status of call forwarding visually (for 
> example by means of text or graphical content on a visual 
> display).  If we are talking about telephone terminals that 
> support SIP natively, then that seems to be a perfectly 
> reasonable assumption.  But there is one very important case 
> for which this is not true: UAs that are in the form of 
> analog telephone adapters.
> 
> "Why look back?"  I hear you all say.  "Why would you use an 
> analog handset when you can have a native SIP device that 
> offers all sorts of smart features?"
> 
> 1)  Incumbent wireline network operators are replacing their 
> legacy TDM infrastructure with VoIP networks, in a manner 
> that is transparent to their subscribers.  Subscribers will 
> continue to use analog phones connected to copper loops, but 
> those loops now terminate in access gateways that convert to 
> VoIP.  Historically, those access gateways have been 
> controlled by media gateway control protocols such as MGCP 
> and Megaco, but increasingly service providers are choosing 
> SIP-based access gateways.
> 
> 2)  Competing network operators (for example cable operators 
> or broadband network providers) are offering residential and 
> business telephony services delivered to the customer 
> premises over broadband, with connectivity to the 
> subscriber's existing analog telephone equipment (for 
> example, cordless handsets or small key systems) via 
> integrated access devices that provide POTS ports.  In almost 
> all cases, such service providers are choosing SIP-based 
> integrated access devices.
> 
> In both cases, there is advantage to service providers in 
> allowing subscribers to connect their existing equipment to 
> the service, and in delivering an exact equivalent of the 
> familiar POTS service.  Of course, service providers are also 
> taking advantage of the power of SIP application servers to 
> deliver a bunch of new capabilities, but that's another story 
> . . . legacy POTS equivalence is table stakes.
> 
> In the POTS world, there are two common ways of warning a 
> subscriber that call diversion is active: by means of 
> ringsplash, where a brief burst of ringing is applied to the 
> phone whenever an incoming call is diverted by the service; 
> and by means of stutter dial tone.  Of these two, ringsplash 
> is probably the more widely deployed.
> 
> In the absence of public interoperability specifications, 
> vendors are being forced to come up with proprietary 
> solutions to problems such as how to support ringsplash to 
> UAs that are in the form of analog telephone adapters.  My 
> understanding of the BLISS charter is to make this 
> unnecessary, by identifying this type of problem and defining 
> a recommended SIP signaling solution to it.
> 
> The above is a long and roundabout way of saying that we 
> don't just need a means of informing the UA that call 
> forwarding is active, we also need a means of informing the 
> UA of call forwarding events as they happen.  Otherwise we 
> can't deliver POTS equivalence.
[JRE] Whilst I accept the scenarios you describe, I don't understand what you mean by "informing the UA of call forwarding events as they happen" - this sounds the same as what I was arguing. As long as the UA (in your case the POTS adaptor) is aware of the call forwarding state, it can provide appropriate indications to POTS phones.

> 
> I would agree with the view that SUBSCRIBE/NOTIFY is rather a 
> heavyweight solution to this problem.  I would argue that the 
> solution adopted by PacketCable (which, by the way, is in the 
> public domain -- specification at 
> http://www.packetcable.com/downloads/specs/PKT-SP-RSTF-I01-060
> 927.pdf) is ugly, not only because it makes use of 
> SUBSCRIBE/NOTIFY, but also because the event to which the UA 
> is supposed to subscribe (ua-profile) is intended for remote 
> management of UA configuration, and should not be subverted 
> for the purposes of notifying events that take place on the 
> call processing path.
> 
> The suggested use of REFER with a URN would appear to be 
> worth further discussion.  The value of the URN could 
> indicate the state of any network-provided feature, and could 
> also indicate call forwarding events so as to support the 
> application of ringsplash.  The problem with REFER is the 
> requirement on the recipient to NOTIFY the requester of the 
> progress of the REFER request.  This generates at least two 
> additional messages (NOTIFY, 200 OK) which serve no 
> functional purpose.
[JRE] No - you can use the NoReferSub option (RFC 4488).

> 
> An alternative approach might be to use NOTIFY, but with an 
> implicit subscription.  This is such common practice that it 
> can almost be considered a de facto standard.  For example, 
> many SIP phones do not SUBSCRIBE to message-summary but 
> expect to be sent NOTIFY for message-summary events to drive 
> message waiting indication on the phone.
> 
> Martin 
> 
> 
> diversion 
> problem with 
> display field 
> diversion 
> industry

---

From: "Martin Taylor" <[email-masked]>
Date: Wed, 19 Sep 2007 15:13:20 +0100

> [JRE] Whilst I accept the scenarios you describe, I don't understand what you mean 
> by "informing the UA of call forwarding events as they happen" - this sounds the same 
> as what I was arguing. As long as the UA (in your case the POTS adaptor) is aware 
> of the call forwarding state, it can provide appropriate indications to POTS phones. 

What I meant was that, in order to deliver ringsplash to an analog phone each time an incoming call is forwarded, the UA needs to receive a signaling message that indicates such an event has occurred each time it happens.  This is not the same as being made "aware of the call forwarding state".  The UA can be aware that the call forwarding service is currently enabled (which would allow it, for example, to play stutter dial tone), but in addition to this it needs to be made aware of call forwarding events as they happen (so that it can apply ringsplash).

It would certainly be possible to use the same signaling mechanism both to notify the UA of changes in the state of services such as call forwarding (i.e. enabled / disabled) and to notify the UA of call forwarding events.  We could define for this purpose an event package called "call-forwarding-count" whose state is defined as the number of calls forwarded since the call forwarding service was enabled.  Every time a call is forwarded, this count is incremented, and a NOTIFY containing a body that includes the new value of call-forwarding-count is sent to the UA.

Martin

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: 19 September 2007 14:25
To: Martin Taylor
Cc: [email-masked]
Subject: RE: AW: AW: [BLISS] Re: notification/warning: call diversion active

Martin,

John 

> All the discussions I have seen on this thread appear to assume that 
> the UA is an intelligent device with the means to indicate the current 
> status of call forwarding visually (for example by means of text or 
> graphical content on a visual display).  If we are talking about 
> telephone terminals that support SIP natively, then that seems to be a 
> perfectly reasonable assumption.  But there is one very important case 
> for which this is not true: UAs that are in the form of analog 
> telephone adapters.
> 
> "Why look back?"  I hear you all say.  "Why would you use an analog 
> handset when you can have a native SIP device that offers all sorts of 
> smart features?"
> 
> 1)  Incumbent wireline network operators are replacing their legacy 
> TDM infrastructure with VoIP networks, in a manner that is transparent 
> to their subscribers.  Subscribers will continue to use analog phones 
> connected to copper loops, but those loops now terminate in access 
> gateways that convert to VoIP.  Historically, those access gateways 
> have been controlled by media gateway control protocols such as MGCP 
> and Megaco, but increasingly service providers are choosing SIP-based 
> access gateways.
> 
> 2)  Competing network operators (for example cable operators or 
> broadband network providers) are offering residential and business 
> telephony services delivered to the customer premises over broadband, 
> with connectivity to the subscriber's existing analog telephone 
> equipment (for example, cordless handsets or small key systems) via 
> integrated access devices that provide POTS ports.  In almost all 
> cases, such service providers are choosing SIP-based integrated access 
> devices.
> 
> In both cases, there is advantage to service providers in allowing 
> subscribers to connect their existing equipment to the service, and in 
> delivering an exact equivalent of the familiar POTS service.  Of 
> course, service providers are also taking advantage of the power of 
> SIP application servers to deliver a bunch of new capabilities, but 
> that's another story . . . legacy POTS equivalence is table stakes.
> 
> In the POTS world, there are two common ways of warning a subscriber 
> that call diversion is active: by means of ringsplash, where a brief 
> burst of ringing is applied to the phone whenever an incoming call is 
> diverted by the service; and by means of stutter dial tone.  Of these 
> two, ringsplash is probably the more widely deployed.
> 
> In the absence of public interoperability specifications, vendors are 
> being forced to come up with proprietary solutions to problems such as 
> how to support ringsplash to UAs that are in the form of analog 
> telephone adapters.  My understanding of the BLISS charter is to make 
> this unnecessary, by identifying this type of problem and defining a 
> recommended SIP signaling solution to it.
> 
> The above is a long and roundabout way of saying that we don't just 
> need a means of informing the UA that call forwarding is active, we 
> also need a means of informing the UA of call forwarding events as 
> they happen.  Otherwise we can't deliver POTS equivalence.

> heavyweight solution to this problem.  I would argue that the solution 
> adopted by PacketCable (which, by the way, is in the public domain -- 
> specification at 
> 927.pdf) is ugly, not only because it makes use of SUBSCRIBE/NOTIFY, 
> but also because the event to which the UA is supposed to subscribe 
> (ua-profile) is intended for remote management of UA configuration, 
> and should not be subverted for the purposes of notifying events that 
> take place on the call processing path.
> 
> The suggested use of REFER with a URN would appear to be worth further 
> discussion.  The value of the URN could indicate the state of any 
> network-provided feature, and could also indicate call forwarding 
> events so as to support the application of ringsplash.  The problem 
> with REFER is the requirement on the recipient to NOTIFY the requester 
> of the progress of the REFER request.  This generates at least two 
> additional messages (NOTIFY, 200 OK) which serve no functional 
> purpose.

> 
> An alternative approach might be to use NOTIFY, but with an implicit 
> subscription.  This is such common practice that it can almost be 
> considered a de facto standard.  For example, many SIP phones do not 
> SUBSCRIBE to message-summary but expect to be sent NOTIFY for 
> message-summary events to drive message waiting indication on the 
> phone.
> 
> Martin
> 
> 
> I seem to sense a consensus that there is a requirement for a UA to be 
> aware of the status of call forwarding unconditional (or maybe various 
> types of conditional call forwarding too, although that seems to be 
> outside the scope of the present thread). It can then use this 
> information to advise the user in whatever way is appropriate. To me, 
> things like stutter dial tone or other indications at the time of 
> outgoing call establishment are old fashioned - for a long time I have 
> had phones on my desk that permanently indicate my call forwarding 
> status. Indeed I very rarely hear dial tone, let along stutter dial 
> tone, because I dial from an address book or hot key or missed call 
> list, or failing that I key my digits before going "off-hook" (or 
> activating headset or speakerphone or whatever). My cellphone never 
> gives me dialtone. So PLEASE let's leave the UI to the UA, and just 
> I have a certain sympathy with Martin Huelsemann's contention that a 
> SUBSCRIBE/NOTIFY mechanism is too heavy in signalling.
> For example, dialog-stateful proxies / B2BUAs seem to be sensitive to 
> lots of long-term dialogs from every UA.
> 
> Alert-Info in a response to INVITE, for all the reasons stated by 
> various contributors to this thread.
> 
> What about a REFER request, referring to a URN that indicates call 
> forwarding status? URN parameters could even indicate conditions, if 
> we need to extend this to conditional call forwarding. Something 
> similar has been proposed by others in the past in the context of 
> remote call control.
> 
> John
>

---

From: "Michael Procter" <[email-masked]>
Date: Wed, 19 Sep 2007 08:15:08 -0700

> similar has been proposed by others in the past in the context of

Isn't there a presumption that the recipient of a REFER should contact
the specified third party (modulo authorisation considerations)?

>From RFC3515 Section 2:
   REFER is a SIP method as defined by RFC 3261 [1].  The REFER method
   indicates that the recipient (identified by the Request-URI) should
   contact a third party using the contact information provided in the
   request.

It seems a bit of a stretch to me to use REFER (even to a URN) to
indicate either call forwarding is active, or a call has been forwarded
(although with some fast talking, I might accept the second of these).  

This problem (delivery of call forwarding state) does sound like the
sort of thing that should be handled with SUBSCRIBE/NOTIFY.  And if that
is deemed too heavy, maybe an unsolicited (out of dialog) NOTIFY is the
lesser of the two evils.

Another way of looking at this is that an endpoint is trying to monitor
the state of a service that it has pushed into the network.  If call
forwarding was implemented on the UA instead of in the network, then it
would always know what the current state was, and it would also know
whenever it forwards a call.  Of course, moving the service to the edge
has its own tradeoffs, but it may be worth examining those in the light
of the difficulties we are seeing here.

Regards,

Michael Procter

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 19 Sep 2007 11:16:27 -0400

> It would certainly be possible to use the same signaling mechanism both to notify the UA of changes in the state of services such as call forwarding (i.e. enabled / disabled) and to notify the UA o…

The mechanism you mention has been suggested.

Another way to do it would be to configure phones that want this feature 
to do the forwarding locally rather than in the network. The call is 
actually delivered to them, and they return a 3xx or something similar. 
At that time the phone can also do a ringsplash.

Alternatively, a phone that knows network forwarding is enabled could 
simply generate a ringsplash periodically - not related to an actual 
call forwarding. This is a way to alert a user when there is no display 
and the user is not picking up the phone.

It depends on how faithful you want to be to the legacy behaviors, vs. 
finding a good way to achieve the *intent* of making the user aware of 
the situation.

	Paul

---

From: "Huelsemann, Martin" <[email-masked]>
Date: Wed, 19 Sep 2007 17:44:33 +0200

First I agree with the key reasons Martin gave why there won't be just smart SIP phones which we have to consider when deveoping service features. Only that this isn't just valid for analog phones / POTS, but also for ISDN phones on integrated access devices.

For the notifications I think there are two different types of them we have to consider.

On the one hand there are notifications about events. An event that you have successfully activated the diversion or an event that an diversion has occurred. For me the appropriate mechanism seems to be SUB/NOT with configuration event packages or call-forwarding-count event package. If you are interested you can subscribe to this notifications, if you think it's not worth you don't subscribe.

On the other hand there are notifications that are more something like a reminder, e.g. "your diversion is still active". Nothing has changed, the diversion can be active since over a day. But as you have activated that diversion so long ago, you might have forgotten it's active, and so this reminder (warning) is usefull. I think in this case SUB/NOT isn't really mandatory, especially when you consider the rather heavy signalling.

But before we think about the appropriate SIP solution: as Paul said this reminder should be generated locally by your SIP phone. I still think it's useful if also the service provider has a chance to send you this information. Because it can be harmful if you cannot be reached via phone, and if several instances have the possibility to inform you that nobody can call you it's better than just one way of informing you.

BR, Martin

> Von: Martin Taylor [mailto:[email-masked]] 
> Gesendet: Mittwoch, 19. September 2007 14:23
> An: Elwell, John
> Cc: [email-masked]
> Betreff: RE: AW: AW: [BLISS] Re: notification/warning: call 
> diversion active
> 
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 19 Sep 2007 12:01:20 -0400

> First I agree with the key reasons Martin gave why there won't be just smart SIP phones which we have to consider when deveoping service features. Only that this isn't just valid for analog phones…

Any phone or ATA that is capable of doing sip is "smart" enough. I don't 
think the issue is really intelligence - it is really about the richness 
of the UI on the device.

If the UI is limited (e.g. it is via an RJ11 interface to a black phone) 
  then the device has to work with that. That can be generating various 
ringer and/or ringback signals from time to time. We have been 
descriptions of a number of these. There is no reason why the UA can't 
be smart enough to do something suitable if it is aware of the situation.

> On the other hand there are notifications that are more something like a reminder, e.g. "your diversion is still active". Nothing has changed, the diversion can be active since over a day. But as y…

Human users can forget about these things. A suitable UI to remind them 
is a reasonable thing.

But the UA only forgets such things in particular circumstances that are 
understood. We generally call this sort of thing "soft state". And we 
expect the device to recognize when it might have lost its soft state 
and take actions to refresh it. We don't need the network to proactively 
do anything about this - it just needs to be able to honor a request 
from the device to refresh its soft state.

Event packages are well suited to this. When a device restarts it 
doesn't know the state, so it establishes a subscription. The first 
notification informs it of the state, which it then retains as soft 
state. Subsequently it assumes that state is valid until it receives a 
notification to the contrary or until the subscription is terminated.

As long as it is aware of the state it can then take appropriate action 
to remind a user who might have forgotten.

	Paul

---

From: [email-masked]
Date: Wed, 19 Sep 2007 17:15:42 -0400

From: "Martin Taylor" <[email-masked]>

   All the discussions I have seen on this thread appear to assume
   that the UA is an intelligent device with the means to indicate the
   current status of call forwarding visually (for example by means of
   text or graphical content on a visual display).  If we are talking
   about telephone terminals that support SIP natively, then that
   seems to be a perfectly reasonable assumption.  But there is one
   very important case for which this is not true: UAs that are in the
   form of analog telephone adapters.

I don't see that this example changes the situation in any significant
way.  As Paul said, let the UA (that is, the SIP User Agent) be able
to know the status in question, and it can determine how best to
present the information to the user.

In the case of an adaptor that speaks SIP out one side and POTS to a
black phone out the other side, the analysis is just the same -- the
UA is the adaptor, and once the adaptor is aware of the state
information, it determines how to present it to the user using the
interface available (the black phone).

Similarly for adaptors between SIP and ISDN phones, or indeed, between
SIP and any other telephony protocol, no matter how simple or complex.

The confusion stems, I think, from the idea that "the network tells
the user", that is, that some agent deep in the network will somehow
get the status information to the user without the knowledgeable
participation of the UA.  This leads one to try to figure out how to
tunnel the information through the UA in a way that the UA is unlikely
to modify or interpret.  But that is a bad design choice, I think.  It
runs counter to the design philosophy of SIP, and becomes vulnerable
to many legitimate choices in UA implementation.

Dale