Hi Dale, A couple of comments below.
Regards Andy >-----Original Message----- >From: Dale Worley [mailto:[email protected]] >Sent: 01 March 2009 20:54 >To: BLISS >Cc: Hutton, Andrew >Subject: More comments on draft-ietf-bliss-call-completion-03 > >* 1004 Hutton: Marking > > Section 5.6: "Question: The CC must be marked in some >way as a CC call > in order for the callee's monitor to know that the CC >activation is > being acted upon by the caller's agent. And the >marking must include > the original Call-Id to allow correlation with the >original call. > Possibilities for a marking are a special >URI-parameter on the request > URI or a special header". > > We need to make sure it works across intermediate >B2BUAs that translate > Call-Ids, so Call-Id should not be the means of >correlation (otherwise > it would require intermediate B2BUAs to perform >appropriate translations > on this information, but this would not work if >different routes were > taken). > >This is indeed problematic. In the call-completion design >group we call >it "the correlation problem" and no ideal solution has been found. > >The current thinking is based on the fact that the PSTN >protocols do not >enforce this correlation, that is, the ETSI specification for >call-completion requests does not require the recipient to verify that >the caller has previously made a call to that destination, and indeed, >there may not be enough information in the request to verify it. >(Although the ETSI specification does imply that the originating >exchange should do such verification itself.) > >So the suggestion under consideration is to abandon all attempts at >correlation (which we don't seem to be able to do successfully) and >instead warn that the callees' monitor (which receives CC requests) >should beware that illegitimate CC requests could be used for >cyber-stalking, and take appropriate countermeasures. > >* 3006 Hutton: m values > > Section 4.2: "However, SIP call completion operations >MAY carry an 'm' > parameter to label call completion actions as to the >original cause of > the failure. > > Surely it is not the cause of the failure that is >important it is the > flavor of call completion that is being requested >(i.e. initiate > ccRecall on caller becoming free or when next used). > >We have to define the m values. Each m value corresponds to both a >flavor of initial call failure (which is what causes that code to be >generated) and a flavor of call completion (which is the behavior that >that code elicits). > >A fuller description of the meaning, cause, and effect of the m >parameter is in later sections; section 4.2 is meant to be a summary. >In particular, section 5.3 contains this: > > The monitor has a method of monitoring the status of the >UA(s) and/or > their users to determine when they are "available" for a CC call, > that is, in a suitable state to receive a CC call. In a system with > rich presence information, the presence information may directly > provide this status. In a more restricted system, this >determination > MAY depend on the mode of the CC call in question, which is provided > by the 'm' parameter. E.g., a UA is considered available for CCBS > ("m=BS") when it is not busy, but a UA is considered available for > CCNR ("m=NR") when it becomes not busy after being busy with an > established call. > > >* 3007 Hutton: Callbacks > > Section 5.1: "The agent can order the UA(s) at which >the relevant > calling user is available to generate a CC call to the callee". > > The agent can only do this if it is centralised rather >than being in the > endpoint that made the original call. So is a reason >why the agent may > be located in the server but is it really a >requirement for callback to > mature at a different UA to which it was originated. >This is possibly > added value that an agent could provide but maybe not >something that > should be stated in this draft. > >I don't follow this argument. If the agent is integrated into the UAC, >then the agent can trivially "order" the UAC to generate a CC call, the >agent and the UAC being the same device. [AndyH] - The text in what is now in section 5.2. of -03 when it states various things that the callers agent "can" do but if I understand the text correctly these are all outside the scope of the document. However whether the agent can do these things or not depends on the architecture of the solution (i.e. where the caller's agent is located) so I think it is best just not to mention the things that the agent "can" do but are outside the scope of the document as it just complicates the draft. > > * 3008 Hutton: Forking > > Section 6: "In this case, the caller's agent forks the >SUBSCRIBE to two > destinations, with appropriate Request-Disposition. >The first SUBSCRIBE > is to the URI from Call-Info. The second SUBSCRIBE is >to the original > request-URI, and reaches the same callee's monitor. > > It is not clear to me why the caller's agent would >fork the SUBSCRIBE. > Why would it not just send it to the URI from the Call-Info ? > >First, beware that the descriptions in section 6 are meant to be an >example, and are simplified versions of the descriptions in section 5. >The relevant text for this issue is in section 5.5: > > Additionally, > the caller's agent needs to include the original request-URI in its > set of monitor URIs, because the call may have forked to additional > callees whose responses the caller has not seen. (A >SUBSCRIBE to the > request-URI alone is used in cases where the caller's agent has not > received or cannot remember any monitor URI.) [AndyH] - This relates to me previous message on the list I am not sure that a SIP UA implementation will be able to "fork" the request as it is really not a proxy and probably does not have the capability within it's SIP stack to do this. I think we should try to remove this requirement for the UA to "fork" the request. > >Dale > > > _______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
