Subject: [BLISS] Call-completion design question: End-to-end parameters

From: [email-masked]
Date: Fri, 22 Feb 2008 17:19:35 -0500

As part of the design of the call-completion feature, we are running
into a problem regarding data which needs to be carried from the UAC
to UAS.  So the call-completion design committee is circulating the
question to the Bliss membership for opinions.

Background:

In the call completion design, there are three circumstances where we
want the UAC to supply certain parameters which will certainly seen by
the UAS.  The question is how to best accomplish this in the face of
complex forking scenarios and the current definitions of SIP.

In the original call from the UAC to the UAS, the UAC may wish to
apply a specifically constructed unique identifier to the call.  The
idea of using it as the Call-Id was rejected because of the ubiquitous
assumption in SIP that Call-Ids can be constructed arbitrarily (as
long as they are unique).  The current choice is to attach it to the
From header as the 'id' header parameter.  (The conceptually ideal
choice would be to attach it as a parameter to the Call-Id header, but
the grammar does not allow that.)

Advantages:  Attaching 'id' to the From header is almost certain to
work in existing systems.

Disadvantages:  The 'id' is not conceptually an attribute of the
caller, but of the call itself.

In the call completion request SUBSCRIBE, by which the UAC indicates
that it wants to be notified when the UAS's user is available for
another call, we wish to attach two parameters:  'id' is used to carry
the Call-Id of the original call (or the 'id' paramater of the
original INVITE, if there was one), and 'm' is used to carry the
"mode" by which the original call failed.  The current choice is to
attach these to the request-URI.

Advantages:  This allows us to consider the SUBSCRIBE as identifying
the record of a particular original call that is archived at the UAS,
and so it is natural that when that original call is selected for
re-call, the single subscription will receive that notice.

Disadvantages:  The above advantage is specious, as there can be
multiple subscriptions regarding a single original call and we want to
select only one subscription for re-call; thus different subscriptions
to the same URI should receive different event information.  Worse,
any forking proxy is likely to discard the request-URI parameters.

Another possibility is attaching these parameters to the event package
name in the Event header.

Advantages:  Proxies are unlikely to alter the Event header.

Disadvantages:  Giving up the illusion that these subscriptions are
passive observers of a data object that is not affected by which
subscriptions exist.

In the call completion re-call INVITE, by which the UAC contacts again
the UAS, we also want to carry the 'id' value as an authenticator that
this INVITE is an authorized call completion re-call, so that this
INVITE can be given priority over other INVITEs.  The current choice
is to attach this parameter to the request-URI.

Advantages:  It might work, especially if the INVITE is sent directly
to the UAS or a monitor that is responsible for handling call
completion on behalf of the UAS.

Disadvantages: Forking proxies are likely to discard the request-URI
parameters.

An alternative to all of the above is that we could define new
header(s) to carry the required information.

Advantage:  It would work.

Disadvantage:  Defining a new header just for this one feature.

Comments?

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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 25 Feb 2008 14:01:20 -0500

> caller, but of the call itself.

I'm confused by this part. The callid is already a unique identifier of 
the call. What is the problem with them being constructed arbitrarily as 
long as unique - all you want is unique.

If you are concerned that some UAs only make their callids unique *at 
the moment* but recycle them, then that is just wrong. A UAC that wants 
to avail itself of this feature can just as easily fix its use of callid 
as it can add yet another id to the call. With what you are proposing, 
this would just be yet another call identifier that would have to go in 
*every* call.

> attach these to the request-URI.

Why the mode? In your draft you discounted providing this by the 
subscriber. That analysis seemed appropriate to me.

> to the same URI should receive different event information. 

Why would there be multiple subscriptions to the same original call? The 
only reason I can think of is if there are multiple UAs on the client 
side owned by the same user. I doubt it would be done this way in that 
case. And if it is, why would the target UA want to single one out? 
Notifying them all seems fine in the rare case that this comes up.

This is very distinct from the multiple subscribers to different 
original calls that are all queued up.

> Worse,

This is a more serious problem.

> passive observers of a data object that is not affected by which

I don't think this gives up the notion that the data object is 
unaffected by the subscriptions that exist. It does give up the notion 
that the R-URI is sufficient to identify the data object. Part of that 
identification is here moved to the event header parameters. But it can 
still be specified as selecting the particular resource among those 
handled by this server.

> Disadvantage:  Defining a new header just for this one feature.

How about Call-Info?

It is however disheartening to find that the same information has to be 
carried in different ways in the subscribe and the invite.

	Paul

---

From: [email-masked]
Date: Tue, 26 Feb 2008 17:02:55 -0500

From: Paul Kyzivat <[email-masked]>

I came to this idea in three steps.  The first step was that since the
call-id is only required to be unique, the subscriber (most likely a
SS7-to-SIP gateway, in our use case) could construct the call-id in
any way it liked, as long as it was unique.

Then one of the other committee memebers (someone with telco
experience) suggested that other components of the network might
already have requirements on the call-id, that we couldn't assume that
*our* function had free hand with the call-id.

The third stage was realizing that if our gateway was going to place
specific restrictions on the call-id, we could not forbid other
devices from placing restrictions either.  And there is no way to to
coordinate that situation.

The real situation is unpleasantly complicated.  In a perfect world,
the callee's end would have good enough presence data to handle
everything automatically.  But the callee's end may not have that
data, and indeed, the the caller may have learned things that are not
known by a callee's monitor connected to the callee's home proxy.
(Consider what happens in the PSTN now:  "I called Dave and the call
went to his voicemail after one ring, so I know he's on the phone"
vs. "I called Dave and the call went to his voicemail after 4 rings,
so he didn't answer" It's possible for a proxy upstream of that
forking to not be able to distinguish those cases.)

The other obnoxious fact is that SS7 segregates call-completion into
two very similar but (as far as I can tell) completely independent
features, CCBS and CCNR.  So to get SS7-to-SIP-to-SS7 gatewaying to
work smoothly, we need a way to carry the BS vs. NR bit.

So the 'm' parameter is a way to ensure that SS7 interworking works
well now, as well as being available for expansion, and allowing for
applying hueristics where they work better than the obvious rigid
rules.

   How about Call-Info?

Yes, the lack of symmetry is a negative.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 26 Feb 2008 19:09:31 -0500

> coordinate that situation.

I still don't buy it.

The requirement on callids is that they be unique in space and time.
There is a fundamental issue with a statement like that - without some 
algorithm for partitioning the totality of callid values among 
independent nodes that assign them there is no way for one to guarantee 
that the ones it generates don't conflict with those another generates.

I guess in theory this was intended to be solved by permitting the 
inclusion of a node name/address. But that isn't required, and doesn't 
work in practice because many nodes don't have a unique ip address and 
don't have a dns name, and we now recommend it not be included anyway 
for privacy reasons.

So the recommendation now is, AFAIK, to create something 
cryptographically random with some number of bits of randomness. But of 
course without any rules on how that is formatted there aren't any 
guarantees there either.

Nevertheless, in practice these things are "unique enough". And for your 
use the also only have to be "unique enough" that there is low 
probablility of collision. If there is a rare collison, then the feature 
won't work right. Tough.

I still think it is sufficient for you to use the callid and emphasize 
that clients that expect to use this feature had better ensure that 
their callid is sufficiently unique.

> applying hueristics where they work better than the obvious rigid

OK. Its still a bunch of crap, but I understand the interop issues.

Can you put some weasle words in indicating that this datum may be 
ignored by the callee if it can determine presence without it?

> Yes, the lack of symmetry is a negative.

How do you feel about call-info for this purpose?

	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 27 Feb 2008 07:37:06 +0000

Dale,

I still don't get this call-ID stuff. If there is an intermediate B2BUA
that maps call-IDs between the upstream side and the downstream side and
it is not CC-stateful, how can it ensure that it performs the same
mapping on a call-ID in the Event header field of a SUBSCRIBE request
that it carried out on the original INVITE request? Without such
mapping, the callee's monitor will receive a different call-ID and will
be unable to match.

Even with a CC-stateful B2BUA there, what if the SUBSCRIBE request gets
routed differently and passes through a different B2BUA?

John

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Paul Kyzivat
> Sent: 27 February 2008 00:10
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [BLISS] Call-completion design question: 
> End-to-end parameters
> 
> 
> 
_______________________________________________
BLISS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/bliss