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. > 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. > 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. Dale _______________________________________________ BLISS mailing list [email protected] http://www.ietf.org/mailman/listinfo/bliss
