Subject: Re: [BLISS] thoughts on draft-ietf-bliss-call-completion; sus/res

From: "Huelsemann, Martin" <[email-masked]>
Date: Tue, 5 Aug 2008 14:56:19 +0200

> > Very much related to that, ccbs has an effect of 
> introducing work in one 
> > domain (the one of the callee) that primarily (if not exclusively) 
> > benefits the other (the one of the caller). This provides 
> an unfortunate 
> >  negative incentive for implementing this in a callee 
> domain. I think we 
> > need to take care to minimize the amount of work required on the 
> > callee's side to support this. So for example, I am reluctant to 
> > introduce requirements to do things like suspend/resume, as these 
> > introduce additional work and state on behalf of the callee's agent.
> 
> While I agree that it is important to consider what the 
> incentives are 
> for implementing this stuff, I don't think this should be viewed as 
> primarily benefiting the caller at the expense of the callee. 
> At least 
> not if this is considered an *optional* feature at the callee.
> 
> A callee will offer this capability if he considers it advantageous - 
> namely if he considers the incoming calls to his benefit, and missing 
> them to be a loss. If the callee doesn't view incoming calls 
> that way he 
> is free to omit the feature.
> 
> To the caller who wants to get through, there are various potential 
> solutions. One is to simply repeatedly reattempt the call. 
> This can be 
> done manually by the UAC user, but it can also be implemented 
> in the UAC 
> itself.
> 

I agree that at the end of the day there is a interest of the caller as well as of the callee to get a failed call completed as soon as possible. Especially business users set a high value on reducing the average waiting time for their customers when they are busy. They don't want many redials to be started, which could mean their most important customer is the unlucky one who has to wait the longest until his redial succeeds.

And if a callee decides that CC is offered to the caller (I think regarding policies we are much more flexible than it was/is in the PSTN), he will also be interested that CC runs in the most effective way. The effectiveness of course is increased if busy callers don't have to be considered for CC recall processing, for which they have to be suspended.

Because of this I still think sus/res is an important feature for CC. The question is, is it important enough to describe it in the basic CC draft? Or, like we have talked about in Dublin, is it better to have it in a seperate draft, describing enhanced CC features (needed e.g. for 3GPP)?

BR, Martin

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

---

From: "Stumer, Peggy (Com US)" <[email-masked]>
Date: Tue, 5 Aug 2008 07:39:23 -0700

Hi all,
May I ask, is the intention of specifying this feature in order to
interwork with this age-old feature in the legacy TDM network, or, do we
not consider the age-old CCBS/NR (ISDN) feature and instead define a
new, stream-lined call completion type of capability? 

In the interest of interworking with legacy networks supporting this
feature (it is an important enterprise feature especially in Europe),
the suspend/resume procedure should be defined since it is a mandatory
procedure when one supports CCBS and/or CCNR. Likewise, IMO, all
mandatory ISO/IEC/ECMA PICS items for this supplementary service should
be supported/mappable in this SIP draft procedure if there is an intent
to interwork with the ISDN feature (which is desirable from a customer's
perspective who is migrating to VoIP).

If there is no intent to provide the capability to interwork/map this
draft feature with the age-old ISDN feature, then one should consider
redefining and incorporating such presence and IM alternatives that can
actually enhance the age-old feature in many significant ways.
Best Regards, 
Peggy Stumer 
Siemens Enterprise Com 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Huelsemann, Martin
Sent: Tuesday, August 05, 2008 8:56 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [BLISS] thoughts on draft-ietf-bliss-call-completion;
sus/res

> done manually by the UAC user, but it can also be implemented 

I agree that at the end of the day there is a interest of the caller as
well as of the callee to get a failed call completed as soon as
possible. Especially business users set a high value on reducing the
average waiting time for their customers when they are busy. They don't
want many redials to be started, which could mean their most important
customer is the unlucky one who has to wait the longest until his redial
succeeds.

And if a callee decides that CC is offered to the caller (I think
regarding policies we are much more flexible than it was/is in the
PSTN), he will also be interested that CC runs in the most effective
way. The effectiveness of course is increased if busy callers don't have
to be considered for CC recall processing, for which they have to be
suspended.

Because of this I still think sus/res is an important feature for CC.
The question is, is it important enough to describe it in the basic CC
draft? Or, like we have talked about in Dublin, is it better to have it
in a seperate draft, describing enhanced CC features (needed e.g. for
3GPP)?

BR, Martin

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Tue, 5 Aug 2008 18:52:48 +0200

Reading the BLISS charter, I would have said that this issue should have
been included in the work even if it is not included in the the minimum
baseline UA requirements.

"The problem is exacerbated by the desire for these features to work
across many types of SIP endpoints, including SIP hardphones, 
softphones, and gateways to the PSTN and other VoIP networks including 
non-centralized environments, and for the desire to work across domain 
boundaries and to interwork with the PSTN, when applicable.

The focus will not be on rigorous definition of what the specific 
feature is and exactly how it works. Rather, the focus will be on 
documenting the variations that exist in the wild sharing common 
interop problems, figuring out a minimum baseline requirement for a UA 
and servers (minimum set of primitives etc.), defining minimum levels 
of functionality and functional primitives required to realize a broad 
class of related features, and on interoperating with other elements 
which might implement one of those features in different ways."

What I am detecting at the moment is that participants are proposing to
exclude it because they think the cost of solution outweights the usage,
but that they are failing to take into account the need to interwork.

Regards

Keith

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Stumer, Peggy (Com US)
> Sent: Tuesday, August 05, 2008 3:39 PM
> To: Huelsemann, Martin; [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: [BLISS] thoughts on 
> draft-ietf-bliss-call-completion; sus/res
> 
> Hi all,
> May I ask, is the intention of specifying this feature in 
> order to interwork with this age-old feature in the legacy 
> TDM network, or, do we not consider the age-old CCBS/NR 
> (ISDN) feature and instead define a new, stream-lined call 
> completion type of capability? 
> 
> In the interest of interworking with legacy networks 
> supporting this feature (it is an important enterprise 
> feature especially in Europe), the suspend/resume procedure 
> should be defined since it is a mandatory procedure when one 
> supports CCBS and/or CCNR. Likewise, IMO, all mandatory 
> ISO/IEC/ECMA PICS items for this supplementary service should 
> be supported/mappable in this SIP draft procedure if there is 
> an intent to interwork with the ISDN feature (which is 
> desirable from a customer's perspective who is migrating to VoIP).
> 
> If there is no intent to provide the capability to 
> interwork/map this draft feature with the age-old ISDN 
> feature, then one should consider redefining and 
> incorporating such presence and IM alternatives that can 
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Huelsemann, Martin
> Subject: Re: [BLISS] thoughts on 
> draft-ietf-bliss-call-completion; sus/res
> 
> 
> > them to be a loss. If the callee doesn't view incoming 
> calls that way 
> > he is free to omit the feature.
> > 
> > done manually by the UAC user, but it can also be 
> implemented in the 
> > UAC itself.
> > 
> 
> 
> 
> I agree that at the end of the day there is a interest of the 
> caller as well as of the callee to get a failed call 
> completed as soon as possible. Especially business users set 
> a high value on reducing the average waiting time for their 
> customers when they are busy. They don't want many redials to 
> be started, which could mean their most important customer is 
> the unlucky one who has to wait the longest until his redial succeeds.
> 
> And if a callee decides that CC is offered to the caller (I 
> think regarding policies we are much more flexible than it 
> was/is in the PSTN), he will also be interested that CC runs 
> in the most effective way. The effectiveness of course is 
> increased if busy callers don't have to be considered for CC 
> recall processing, for which they have to be suspended.
> 
> 
> The question is, is it important enough to describe it in the 
> basic CC draft? Or, like we have talked about in Dublin, is 
> it better to have it in a seperate draft, describing enhanced 
> CC features (needed e.g. for 3GPP)?
> 
> 
> BR, Martin
> 
> 
> 
> 
>

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 08 Aug 2008 08:26:28 +0100

It certainly needs to interwork, but can a basic level of interworking
be achieved without suspend/resume? There are advantages in lowering the
bar for would-be implementations, and also speeding up the process in
BLISS for getting an RFC out.

John 

> On Behalf Of DRAGE, Keith (Keith)
> Sent: 05 August 2008 17:53
> To: Stumer, Peggy (Com US); Huelsemann, Martin; 
> [email-masked]; [email-masked]
> Cc: [email-masked]

---

From: [email-masked]
Date: Thu, 14 Aug 2008 13:16:42 -0400 (EDT)

(My apologies for the slow replies, as I've been busy and also had
some mail problems due to some new anti-spam system on the Bliss
mailing list.)

   From: Jonathan Rosenberg <[email-masked]>

   Very much related to that, ccbs has an effect of introducing work in one 
   domain (the one of the callee) that primarily (if not exclusively) 
   benefits the other (the one of the caller). This provides an unfortunate 
   negative incentive for implementing this in a callee domain. I think 
   we need to take care to minimize the amount of work required on the 
   callee's side to support this. So for example, I am reluctant to 
   introduce requirements to do things like suspend/resume, as these 
   introduce additional work and state on behalf of the callee's agent.

Call-completion can provide value to both the caller and the callee.
In the current US PSTN, only the caller is charged, but (I suspect)
that's because the carriers make more money charging the caller
per-usage than they would by charging potential callees per-month.
(Contrast with call waiting, which is charged per-month at the
callee's end.)

My expectation is that initial CC deployment will be (1) in systems
operated by PSTN carriers and gateways to the PSTN, as continuations
of their current lines of business, and (2) in PBXs, which will market
it as a continuation of the "camp-on" feature.  Our goal is to have
these various deployment islands interoperate without any further work
(especially without work on the part of any transit SIP carriers).
Supporting this goal drives some of the more troublesome requirements
we have.  Once the deployment islands interoperate, we hope to have a
critical mass of users so that additional systems will implement CC as
a matter of course.

   What does a calling domain do when it wants to invoke this service and 
   the terminating side doesn't support it. Do we have a recommended 'poor 
   mans' version of this that requires no additional support? i.e., I am 
   aware of implementations that actually periodically send INVITEs. 
   Indeed, doing so may be incentive to properly deploy a sub/not solution 
   to avoid such deluge...

No, we've been considering such a recommendation as outside our scope.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 14 Aug 2008 15:10:13 -0400

> No, we've been considering such a recommendation as outside our scope.

As a phone user, I can definitely say that I just want this feature to 
*work*, regardless of whether the callee has any special support for it.

All this machinery is really an *optimization*, which benefits primarily 
the carrier and/or the callee. Perhaps the queuing is of some benefit to 
the caller by guaranteeing some fairness in the order that calls are 
handled. Possibl it can also provide some feature benefit via the "ring 
when available" vs. having to stay at the phone while the call is 
repeatedly tried.

But if I was given a choice of a phone the only did repeated dialing, vs 
one that only provided the feature if the callee supports it, I would 
choose the former.

	Paul

---

From: [email-masked]
Date: Fri, 15 Aug 2008 15:21:34 -0400 (EDT)

--text follows this line--
   From: Paul Kyzivat <[email-masked]>

   But if I was given a choice of a phone the only did repeated
   dialing, vs one that only provided the feature if the callee
   supports it, I would choose the former.

I would think that a phone that does automatic repeated dialing would
be considered harassment.  (Consider especially the ring-no-answer
case.)  Are there really implementations that do this?

Dale

---

From: [email-masked]
Date: Fri, 15 Aug 2008 17:55:24 -0400 (EDT)

A key part of the mechanism in here is that it focuses on the 'server to
   server' aspect of the problem. It defines only what would need to flow
   between domains or between organizations to accomplish this feature
   between organizations. I think that aspect of it needs to be emphasized.
   For example, some diagrams which show this, including different models
   for how the agents can be co-located.

We have attempted to make that clear.  For instance, section 5.1 of
draft-ietf-bliss-call-completion-02 starts:

   5.1.  Caller's Call-Completion Agent

   The call-completion architecture augments each caller's UA (or UAC)
   which wishes to be able to use the call-completion features with a
   "call-completion agent".

   An agent may be an integrated part of the UA, a separate end-system,
   integrated with a proxy serving the UA, or a function of an
   application server that provides these services to many UAs.

   An agent may service more than one UA as a collective group if it is
   common that a caller or population of users will be shared between
   the UAs, and especially if the UAs share an AOR.

   The caller's agent must be capable of performing a number of
   functions relative to the UA(s).  The method by which it does so is
   outside the scope of this document, but an example method is
   described in appendix A.

... and then enumerates the needed interactions between the agent and
the caller's UA(s).

Section 5.2 has similar text about the monitor.  Appendixes A and B
give outlines of how a simple agent and monitor can be constructed
using standard SIP mechanisms.

Perhaps I don't see what needs to be elaborated.

Dale

---

From: "Alexeitsev, D" <[email-masked]>
Date: Mon, 18 Aug 2008 11:35:19 +0200

Hi, 

I've submitted an initial ID on the URNs for use with the Alert Info.

The draft extends the usage of the Alert-Info header to include URNs
that have a predefined meaning. For example specific types of ringback
tone or specific indication that something happens at the callee side
during alerting like call-waiting.

http://www.ietf.org/internet-drafts/draft-alexeitsev-bliss-alert-info-ur
ns-00.txt

Comment and commentars are warmly welcomed.

Greetings,
Denis

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 18 Aug 2008 10:50:38 -0400

IMO this is off to a good start, but I do have a few comments:

In section 2, the example is inconsistent with the syntax of the URN. It 
appears that the character following "service" should be a ".", not a 
":". Also, "sip:" doesn't belong in the example. I think the example 
should look like:

       Alert-Info: <http://www.exmple.com/sound/moo.wav>,
       <urn:alert:service.call-waiting>

Also, perhaps too much has been cut and pasted from the service URN 
draft. Specifically:

    For any given service URN, service- identifiers can be removed right-
    to-left; the resulting URN is still valid, referring to a more
    generic service.  In other words, if a service 'x.y.z' exists, the
    URNs 'x' and 'x.y' are also valid service URNs.

For one thing, this is defining the "alert" URN, not the "service" URN, 
so the language is at least confusing. Also, this hierarchical 
interpretation is most likely not appropriate in all cases. E.g. while 
it may be clear what to do when receiving 
<sip:urn:alert:service.call-waiting>, what should one do with 
<sip:urn:alert:service> ???

And in the case of urn:alert:tone.foo.bar its hard for me to imagine a 
hierarchical naming scheme that makes any sense. If the hierarchical 
approach applies at all, it likely only applies to urn:alert:service.*.

I'm also slightly dubious of "service" as the appropriate 
characterization for named alerts that are more generic than names for 
tones. I think these are likely names for concepts, but I'm not 
convinced the concepts are necessarily "services", though in some cases 
they might be. Perhaps it would be better to consider them as "states". 
E.g. urn:alert:state.on-a-call instead of urn:alert:service.call-waiting.

Did you intend to create a definition for service.call-waiting as part 
of this document? Or is that only an example, and the actual definition 
will come in some other document?

It would also be helpful to discuss urn:alert:tone a bit more. I'm 
thinking there needs to be more in the registration template for a tone, 
defining which tone it represents in some way. This could be a bit 
tricky, since the goal is to avoid giving a specific encoding. Somehow 
it needs to identify the equivalence class that includes all acceptable 
renderings of the tone while excluding renderings of things that are 
*not* of the tone. And I think it would be helpful to give some examples 
of tones. Would it make sense to extablish some substructure under 
alert:tone? E.g. some country-specific structure?

Also, a typo in section 6.1: s/lables/labels/

	Thanks,
	Paul

---

From: "Alexeitsev, D" <[email-masked]>
Date: Mon, 18 Aug 2008 17:18:57 +0200

Hi Paul 

[DA] Thanks for the comments, reply inline

[DA] I was not sure about this one, some example I've came across have
used the URN including the sip prefix others without. I would correct
the example to the right notation.

    For any given service URN, service- identifiers can be removed
right-
    to-left; the resulting URN is still valid, referring to a more
    generic service.  In other words, if a service 'x.y.z' exists, the
    URNs 'x' and 'x.y' are also valid service URNs.

[DA] Right - it was also my concern, but I did not want to split the
branches to be hierarchic and non hierarchic, as it would complicate the
syntax. I would think about some better wording around this issue

I'm also slightly dubious of "service" as the appropriate 
characterization for named alerts that are more generic than names for 
tones. I think these are likely names for concepts, but I'm not 
convinced the concepts are necessarily "services", though in some cases 
they might be. Perhaps it would be better to consider them as "states". 
E.g. urn:alert:state.on-a-call instead of
urn:alert:service.call-waiting.

[DA] I understand your point, but I think there is value in both
approaches. Personally I can live with either one, so any other opinion
is appreciated.

[DA] My intent was to create a definition for call-waiting in the same
document.

[DA] The tone section is just a placeholder at the moment. Any input on
the desirable values is appreciated.

	Thanks,
	Paul

[DA] Thanks,

Greetings,
Denis

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 18 Aug 2008 19:02:55 -0400

> the example to the right notation.

With the sip prefix it is a sip URL, and must conform to that syntax.

> syntax. I would think about some better wording around this issue

I think I would allow hierarchical naming for purposes of delegating the 
naming authority, but without any assertion that you can infer any 
meaning by trimming of trailing components.

> approaches. Personally I can live with either one, so any other opinion

I don't have a strong opinion on it either, though I think the term 
"service" is generally overworked.

> [DA] My intent was to create a definition for call-waiting in the same

It was unclear whether 6.4 was really an initial registration or just 
part of the template. If its really an initial registration, then the 
RFC references should somehow be tagged with instructions that they be 
replaced by the assigned RFC number for this document. Also, then you 
probably want to leave out tone.xyz (unless there really is an "xyz" 
tone.) But maybe it would be appropriate to add some real tones.

> the desirable values is appreciated.

One more thing here: the draft is very focused on ring*back* tones. But 
Alert-Info is applicable to both ringback and *ring* tones. That may be 
inspiration for more tones that should be defined.

It also may be the case that the same URN may be used for both a ring 
and ringback, though it may be rendered differently. (The fidelity of 
the ringback may be a lot better than for the ring.) I don't know if 
this bears mentioning or not.

	Thanks,
	Paul

---

From: "Huelsemann, Martin" <[email-masked]>
Date: Tue, 19 Aug 2008 09:40:31 +0200

> dialing, vs 

I don't think there will be a 'versus'. CC will be an additional enhancement to the basic 'repeated dialing' feature. So it is also in my ISDN terminal. But I use the repeat dialing only when there is no indication that CC is possible, because my call will be queued anyway.

BR, Martin

---

From: "Alexeitsev, D" <[email-masked]>
Date: Tue, 19 Aug 2008 09:47:56 +0200

Hi Paul,

[DA] Right, ring tones should be covered by the draft. That is on my to
do list as well. 

Greetings,
Denis Alexeitsev

---

From: "TSCHARN, Peter \(Peter\)" <[email-masked]>
Date: Tue, 19 Aug 2008 10:14:29 +0200

I have the feeling of recognizing discussions during specifications of
ISDN supplementary services. Here also the point was made to simply
redial up to the proposal to do it automatically. These discussions had
an end when BT during the nineties had to face the fact that in their
network automatically fast redialling fax machines seized significant
carrier resources. Thus an exponentially increasing interval between
automatic redial attempts was introduced. This was not seen as a
convenient solution for voice calls.

IMO a redial approach is quit inferior to what could be offered by CC
functionality - for the caller (assumed CC is supported at callee side),
the callee (unnecessary ringing) and carrier (save of resources).

Regards

Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Huelsemann, Martin
Sent: Dienstag, 19. August 2008 09:41
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [BLISS] thoughts on draft-ietf-bliss-call-completion-
deployment

> 
> But if I was given a choice of a phone the only did repeated dialing, 
> vs one that only provided the feature if the callee supports it, I 
> would choose the former.

I don't think there will be a 'versus'. CC will be an additional
enhancement to the basic 'repeated dialing' feature. So it is also in my
ISDN terminal. But I use the repeat dialing only when there is no
indication that CC is possible, because my call will be queued anyway.

BR, Martin

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 19 Aug 2008 09:21:15 -0400

> I don't think there will be a 'versus'. CC will be an additional enhancement to the basic 'repeated dialing' feature. So it is also in my ISDN terminal. But I use the repeat dialing only when there…

Here we enter the realm of UI design, which is out of scope for IETF.
But I would certainly prefer a device that just "did the best thing 
possible" rather than making me, the user, choose which technique to 
use. So I would certainly prefer to have a single "Call-Completion" 
button (or I guess a dial string for black phones), and then magic 
happens and eventually the call is completed.

This entire CC mechanism being designed here is but one trick, in the 
bag of tricks, for the UAC to use when appropriate. I think that needs 
to be kept in mind when alternatives are being discussed.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 19 Aug 2008 09:32:11 -0400

> convenient solution for voice calls.

The use of techniques such as exponential backoff is easier to introduce 
when the implementations are all regulated. In an open environment it is 
much like flow control. As with that, while following the rules serves 
the "greater good", any single user can gain advantage by violating the 
rule. Even if the UAC implements the exponential backoff, the user of 
the UAC, having recognized this, can still "cheat" by simply repeatedly 
pressing the "redial" button. (Which is what many of us did for many years.)

> the callee (unnecessary ringing) and carrier (save of resources).

The queued implementation is better for the "greater good". It must 
however be mandatory when present or else some callers will find that 
repeated dialing can still be advantageous. So returning busy for any 
but the selected caller is important. That then breaks any UAC that 
implements CC only via repeated dialing. To provide a functional service 
the UAC then must implement this CC feature when its offered by the callee.

Because this is self regulating, it seems preferable to an exponential 
backoff on a repeat dialing approach.

	Thanks,
	Paul

---

From: [email-masked]
Date: Tue, 19 Aug 2008 12:13:49 -0400 (EDT)

Easily enough done -- If the phone attempts a CC subscription
according to the I-D, and the subscription attempt fails, it can fall
back to another method.

Dale

---

From: [email-masked]
Date: Tue, 19 Aug 2008 12:14:56 -0400 (EDT)

From: "Alexeitsev, D" <[email-masked]>

I like the overall concept -- the original Alert-Info with a true URL
is a nice idea but unlikely to be implemented, whereas it makes sense
to define a series of alert indication *meanings*, which the UA can
choose to render as it pleases.

But that only works if the set of URNs is well-standardized, so both
ends of the dialog know without negotiation that they can be used.
Service-related URNs make sense this way, but on the other hand, "all
the various country-specific ring tones and ringback tones" do not,
since for any one of these tones, most of the phones in the world will
not implement the URN.  (Country-specific tones are how a UA *renders*
standardized alert URNs.)

I do see the logic in providing a hierarchical classification,
allowing some UAs to provide finer-grained information than others.
This isn't necessarily easy to design, though, because you have to pay
attention to how the fall-backs work.  E.g., having a high-level
category "service" is useless because you can't report "service" alone
as a condition to the user.  But you could have "busy.CCBS-available",
because "busy" is also a state that can be usefully rendered to the
user when "busy.CCBS-available" is specified.

Dale

---

From: "Alexeitsev, D" <[email-masked]>
Date: Tue, 19 Aug 2008 18:48:15 +0200

Hi Dale 

[DA] Do you want to define URNs that are not only applicable to the
Alert-Info header and respectively to the alert phase of the call, also
to the Call-Info Header URNs that can be provided at the terminating
phase of the call as well? 

I'm fine with it, that would be a new 'busy' branch: 

    urn:busy:service:ccbs-availabe or urn:busy:state:ccbs-availabe

and extension of the 'alert' branch with: 

    urn:alert:service:ccnr-available or urn:busy:state:ccbs-availabe

We just need to agree on the best term for the 'service'/'state' branch.

Greetings,
Denis Alexeitsev

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 19 Aug 2008 12:54:29 -0400

My initial feeling was that the hierarchical names didn't work well 
here. But Dale's comments have me rethinking that. Among other things, 
that is a way to deal with country specific tones as well. A basic name 
can identify the generic meaning (e.g. "ringing") and a lower level name 
could identify a local-specific variant. If you understand the full name 
then you can render that, else just render something consistent with the 
higher level semantic.

That may also provide an alternative to the "service" vs. "tone" 
distinction.

	Thanks,
	Paul

---

From: [email-masked]
Date: Tue, 19 Aug 2008 23:12:44 -0400 (EDT)

Also related, I think we need to consider the security implications of 
   this. So, if a malicious caller calls a busy user many times, they can 
   cause state to build up in the callee's agent. Indeed I think an 
   implementation would almost be required to construct the call-info URI 
   in a way that allowed it to contain all of the needed state, moving the 
   burden to the caller. This isn't discussed at all, afaict, and its a 
   critical design issue. I seem to recall that this was discussed previously.

   Its my understanding that the server managing the queue is free to prune 
   the queue as desired. For instance, it will almost certainly only keep a 
   single entry from any particular caller. And it can just stop queuing 
   when the queue gets as big as it desires to handle.

   It was disussed previously and one option was to create the queue
   state not at the time of busy recognition for the initial INVITE but at
   the suscription time. In this case the caller would be interested to
   SUBSCRIBE as fast as possible that there will be as less possible delta
   between busy and queue creation time. Subscription also consumes
   resources on the caller side and the resource consumption is not that
   unballanced for caller and callee.

There are a number of aspects to this issue.  The current design is
based on the idea that the PSTN enforces that a CC caller must have
previously made a failed call to the callee in question.  Within that
concept, the design is intended to enforce a similar restriction, to
ensure that SIP CC has privacy enforcement at least as strong as that
of the PSTN.  Recently, we have learned that the PSTN does not enforce
this restriction, which may allow simplification of the CC design.

However, if we desire to enforce the restriction that a CC
subscription is only allowed if it is from the caller of a recently
failed call to the callee, the callee's monitor must maintain a list
of such callers.  In principle this can require unlimited storage, but
there are several mitigations:  (1) no callee has to be recorded more
than once, so repeated calls from a single callee are not significant
(and are already subject to administrative action as abuse), (2) the
amount of information needed to record a caller who does not have a CC
subscription is just the caller's identification string, and (3) the
design allows the monitor to limit the effective queue size according
to any policy it chooses.

Unfortunately, is impossible to depend on a call-info URI containing
the needed state -- one design goal is to support "memoryless" UAs,
gateways actually, where no information is retained between the
original INVITE transaction and the subsequent CC SUBSCRIBE, so the
call-info URI is available as an optimization, but can not be depended
on.  This might seem to be an excessively strict restriction, but
SS7-to-SIP gateway systems seem to be mostly of this sort, because the
gateway is actually a constellation of redundant devices that do not
share call state.

Dale

---

From: [email-masked]
Date: Wed, 20 Aug 2008 16:38:27 -0400 (EDT)

The issue is really targeting/re-forwarding. The question is, if A
   calls B and this is retargeted to C, does it make sense to call
   complete on B or on C? C kind of makes sense; but what if C is busy
   for a while and during that time, the forwarding rules change and
   calls to B no longer forward to C. Now, if A called B back they
   would reach B (who was the person they REALLY wanted to call
   anyway), but a call completion request would in fact go to C. This
   seems wrong to me. One might even argue that call completion and
   forwarding are incompatible. Frankly, if our initial solution
   basically didn't support it (no Call-Info passed back at all when a
   call is forwarded), I think that is arguably a feature. I suspect
   experts on feature interaction have looked at this one; would be
   curious on the best practices around this in the PSTN.

   Some discretion on the part of B and C could make this work better:

   If the forwarding is due to NA or BS, then it can be treated as forking, 
   so that the CC requests go both places. Then whichever gets it first wins.

   Conversely, C can notice that the call was forwarded from B, and can 
   make a policy decision not to support queuing of calls forwarded from B.

   From: "Elwell, John" <[email-masked]>

   In PSTN (or at least enterprise equivalents of PSTN) one practice
   is to make it depend on the conditions for call forwarding. If it is
   call forwarding because of busy or no reply, it makes sense for
   CCBS/CCNR to operate on B, rather than C, because there is just as much
   chance of B becoming available as C becoming available. And after all, B
   is really the person A wants to communicate with. For unconditional call
   forwarding (where B is out of the office for a day, say), it might make
   sense for CCBS/CCNR to operate on C. However, I don't think we want to
   impose rigid rules of this nature on our SIP solution. In some respects
   behaviour should be based on the policy of B, but I am not sure how to
   realise that.

   This is the question, that has no ultimative unswer. One view is
   that it is easier to control the correlation if the call completion wit
   call forwarding is done at the B side. And as you said B is the one A
   really wanted. Things get even more complicated bacause of the different
   types of call forwarding. Here is one of the PSTN BCPs: [...]

Yes, the distinction of forwarding vs. retargeting vs. etc. is
important in CC.  Our assumption is that any sophisticated CC monitor
implementation will have designed proper policies and will edit and
adjust the requests and responses according to that policy.

That is, the messages that are important are:  (1) any HERFP responses
to the original INVITE, (2) final failure responses to the original
INVITE, (3) CC SUBSCRIBE requests, and (4) recall INVITE requests.  In
each case, the proxy doing the forwarding knows the relationship
between the incoming URI and the outgoing URI and thus can determine
whether the outgoing URI is responsible for CC activities of the
incoming URI, or whether a different outgoing URI should be
substituted.  Note that CC SUBSCRIBEs and recall INVITEs can be
detected solely through the 'm' parameter on the request-URI, so even
a memoryless proxy can apply a specific policy.

In Jonathan's case, where INVITEs to B are retargeted to C, there are
two cases:  CC requests to B should be handled by C, or CC requests to
B should be handled by some other UAS/monitor D (which may be a
monitor attached to B).

    Message                 CC handled by C         CC handled by D

    1xx HERFP from C        not modified            Call-Info: call-completion
						    URI replaced with D

    failure responses       not modified            Call-Info: call-completion
    from C                                          URI replaced with D

    CC SUBSCRIBE to B       proxy to C              proxy to D

    recall INVITE to B      proxy to C              proxy to D

And as Paul notes, other policies are possible, and they can be
implemented on a case-by-case basis by B, C, and/or D.

In the case of an unsophisticated proxy with no specific CC behavior,
all cases are handled as described in "CC handled by C", which is
likely to be acceptable, if not optimal, behavior.

Dale

---

From: [email-masked]
Date: Wed, 20 Aug 2008 16:37:12 -0400 (EDT)

On the HERFP problem, I think the issue is really deeper than that.
   [...]  I also think its a mistake to require 199 or 130 or any
   other 'HERFP' response - again, making this too
   complicated. Simplicity is key for this feature IMHO.

The intention of the design is to utilize information available from
HERFP but not require it.  (We cannot require it, as we do not require
that the caller have memory.)  But in the face of forking, we do have
the problem that the caller may have reached several different UASs
that each implement CC -- in a perfect world, the agent would know
what all the monitors are and would subscribe directly to each of
them.

We do prescribe that the CC SUBSCRIBE be sent to the original To URI,
in hopes that it forks identically to the original INVITE, and we
recommend that the SUBSCRIBE be sent to the URI in the CC Call-Info
header, but if the agent can see and remember HERFP responses with CC
Call-Info headers, it provided a more reliable path to the UAS that
generated it.

Dale

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 21 Aug 2008 08:26:30 +0100

Dale,

We don't have a HERFP solution and we don't have 130. At present we only
have (or we shortly will have) 199. However, I am doubtful about the
usefulness of 199 in this context.

First, let's consider the busy case (CCBS). The UAS will return 486. It
will not have established an early dialog, and therefore it will not
send 199.

Second, let's consider the no reply case (CCNR). The caller will often
make the decision to use CCNR after a number of ring cycles, without
necessarily waiting for 487 or 199.

Therefore 199 will be useful only in a minority of cases. We can specify
its use as an optional enhancement, but we should not rely on it for
mainstream feature operation.

John

> On Behalf Of [email-masked]
> Sent: 20 August 2008 21:37
> To: [email-masked]
> draft-ietf-bliss-call-completion - HERFP
> 
>

---

From: [email-masked]
Date: Fri, 22 Aug 2008 18:43:55 -0400 (EDT)

usefulness of 199 in this context. [...]

I think we're all in agreement -- If an HERFP solution becomes
available, we encourage caller's agents to monitor the HERFP
information as a source of additional monitors to subscribe to.  But
the CC mechanism should work as well as possible without the use of
HERFP.

Although if the caller waits until the call fails-over to voicemail,
a 199 would be generated.

Dale

---

From: [email-masked]
Date: Fri, 22 Aug 2008 18:44:50 -0400 (EDT)

Let me describe the information flow in CC, in the ideal case:

- caller sends original INVITE to callee
- callee returns failure response containing Call-Info header
  containing CC subscription URI
- caller subscribes to CC subscription URI
- callee sends NOTIFY containing recall URI
- caller sends INVITE to recall URI

(Note that "NOTIFY containing recall URI" is a fairly recent addition.
I've also omitted use of a suspend/resume server URI.)

In both the CC subscription and the recall, the caller is allowed to
use the original INVITE request URI if it does not receive or cannot
remember the URI provided by the callee.  In the CC subscription case,
the caller is required to also fork the SUBSCRIBE to the original
request URI, in hope of reaching other UASs than the one that
generated the failure response that was returned to the UAC.  In both
cases, the caller adds an "m" parameter to the request URI to mark the
request as a CC request, and also to carry the CCBS vs. CCNR datum.

With that background behind us:

   Also, I would NOT assume that SUBSCRIBE and INVITE to the same URI are 
   routed identically; this is not even true in theory as proxies are 
   allowed to do method-based routing. Indeed, typically SUBSCRIBE are 
   routed to appropriate servers based on event packages.

True.  But we expect that method-based routing will be applied to
requests only when they enter the administrative domain of the request
URI, that is, differing routing will only be done as part of
implementing the requested services.  We expect that "mailing list"
forwarding, whose only purpose is to allow one URI to be an alias for
other URIs, will not be method-sensitive.

   I think the callback INVITE needs to be to a different SIP URI. I 
   suspect it will need different treatment on both sides; i.e., that call 
   should not go to voicemail (I suspect).

In the ideal case, the CC subscription NOTIFY provides a callback URI,
which the callee could use to obtain any treatment of the recall
INVITE that it prefers.  However, gateways may not be able to remember
the callback URI, and so using the original request URI is the
fallback.  In any case, the 'm' parameter on the recall request URI
will tag the INVITE as a recall.

   Using the philosophy embraced in:
   http://www.ietf.org/internet-drafts/draft-ietf-sipping-service-identification-02.txt
   a service URI is absolutely the right thing to differentiate here.

I don't understand what you mean by "service URI" here.  That term is
used only once in the I-D that you reference, and only in regard to
presence.

   I do not understand the usage or need for the 'm' and 'monitor'
   attributes. Monitor shows up as a URI param, in fact. Not at all
   sure why that is needed.

The 'monitor' URI parameter is an arbitrary element of the examples.

The 'm' URI parameter is used to (1) mark the CC SUBSCRIBE as such,
(2) mark the recall INVITE as such, and (3) to carry the CCBS vs. CCNR
datum.

The original definition of the 'm' parameter was in a design where the
URI was always in a Call-Info header with "purpose=call-completion",
so its name was chosen for brevity, representing "mode".  The current
design has that parameter standing on its own in request-URIs, so we
may want a longer name.

As I described above, the 'm' parameter is useful to mark CC
SUBSCRIBEs and INVITEs even when the caller can't remember a URI
provided by the callee.

The 'm' parameter is used to carry the CCBS vs. CCNR status.  This
information is not mandatory, but for callees that do not have rich,
unambiguous presence information, knowing whether the caller perceived
a busy condition or a no-answer condition may be helpful in deciding
whether the callee may be available for recall.  It is also helpful in
the SS7-to-SIP-to-SS7 double-gateway situation, preventing loss of
information between the caller SS7 and the callee SS7.  This
encourages use of SIP as a transit network between SS7 systems.

Dale

---

From: [email-masked]
Date: Fri, 22 Aug 2008 18:44:32 -0400 (EDT)

I have a practical worry on using the Call-ID as a correlator for the 
   subscription. The reality of deployments are many B2BUAs exist, and this 
   is no longer a reliable e2e correlator for things. Anyway its not 
   needed; the URI should be sufficient (and unlike call-id, is reliable). 

(Which URI are you referring to?)

There has been a lot of trouble regarding correlation between CC
subscriptions and orignal calls.  Let us set aside for now the
question of whether correlation needs to be done at all.  The Call-Id
of the original call would be a wonderful correlation identifier, but
as John Elwell pointed out, even now transit networks have many B2BUAs
that change the Call-Id.

Although it is not reflected in draft-ietf-bliss-call-completion-02,
the current thinking is that the URI of the From header would make a
good correlation identifier -- even in the presence of B2BUAs, the
>From URI of the CC SUBSCRIBE and the recall INVITE are very likely to
be identical to the From URI of the original INVITE, all of these
being "as seen at the UAS" -- because B2BUAs are likely to apply the
same transformation rules to all of these requests.

Dale