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 PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of Paul Kyzivat > Sent: 27 February 2008 00:10 > To: [EMAIL PROTECTED] > Cc: [email protected] > Subject: Re: [BLISS] Call-completion design question: > End-to-end parameters > > > > [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 > _______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
