[EMAIL PROTECTED] wrote:
> From: Paul Kyzivat <[EMAIL PROTECTED]>
>
> 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.
>
> 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.
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.
> > 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.
>
> Why the mode? In your draft you discounted providing this by the
> subscriber. That analysis seemed appropriate to me.
>
> 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.
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?
> > 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.
>
> 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.
>
> Yes, the lack of symmetry is a negative.
How do you feel about call-info for this purpose?
Paul
_______________________________________________
BLISS mailing list
[email protected]
http://www.ietf.org/mailman/listinfo/bliss
