Subject: Re: [BLISS] Some of Andrew Hutton's concerns aboutdraft-ietf-bliss-call-completion-03

From: "Hutton, Andrew" <[email-masked]>
Date: Tue, 03 Mar 2009 13:52:42 +0000

Hi Dale,

In general I am happy with your responses below.

However this did prompt me to have a look at section 6 of -03
(Examples). This shows that the caller UA generates two SUBSCRIBE's
using the same Call-Id and the text below the diagram states:

"The caller's agent adds to these URIs an 'm' parameter (if possible).
In this case, the caller's agent forks the SUBSCRIBE to two
destinations, with appropriate Request-Disposition."

This I think is a bit strange as I don't think that many UA SIP Stack
implementations provide a service to "fork" in this way. Therefore I
think we may need a different mechanism to allow the callee to determine
that the two subscribes are related.

Regards
Andy 

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of Dale Worley
>Sent: 27 February 2009 21:00
>To: BLISS
>Subject: [BLISS] Some of Andrew Hutton's concerns 
>aboutdraft-ietf-bliss-call-completion-03
>
>[These are keyed to the issue identifiers in the list of open issues we
>keep on the BLISS-CC mailing list.]
>
>> * 1003  Hutton: CC URI
>> 
>> "Hutton, Andrew" <[email-masked]>
>> Section 5.6: "Question: Should the callee's monitor supply a 
>URI which
>> should be used in the CC call?"
>> I think it should.
>
>This text has been moved to section 5.7 of -03.  The current text is:
>"The notification MAY also contain also a URI which should be used in
>the CC call.  In practice, this may be the AOR of the callee."
>
>I think we should change the MAY to SHOULD.
>
>> * 1005  Hutton: Failure
>> 
>> "Hutton, Andrew" <[email-masked]>
>> Section 5.6: "Can a call appear to succeed from the 
>monitor's point of
>> view but fail from the calling user's point of view?"
>> It is not clear to me what constitutes success from the 
>monitor's point
>> of view. Does just getting back a 180 constitute success? If so, from
>> the caller's perspective the call could still fail to be 
>answered, so it
>> would be up to the caller to invoke CCNR (again) if that is what he
>> wants
>
>In section 5.5 of -03, the text is:
>
>   Note that from
>   the SIP point of view, the INVITE may be successful, but from the
>   user's point of view, the call may be unsuccessful.  E.g., the call
>   may have connected to the callee's voicemail, which would return a
>   200 status to the INVITE but from the caller's point of view is "no
>   reply".
>
>I think this satisfies your concern.
>
>> * 3004  Hutton: Failure of initial call
>> 
>> "Hutton, Andrew" <[email-masked]>
>> Terminology: "CC request: (1) the indication by the caller to the
>> caller's agent that the caller desires CC for a failed 
>original call". 
>> Why does there have to be a failed original call should it 
>be possible
>> to initiate a CC request with no previous call or even if 
>the previous
>> call was "successful". The concept of "failure" really only 
>applies to
>> the user and cannot be specified.
>
>> * 3005  Hutton: Queue
>> 
>> "Hutton, Andrew" <[email-masked]>
>> Terminology: "Call-completion queue: a buffer at the callee' monitor
>> which stores incoming calls which have failed or may have failed"
>> Presumably this means that it is left to the implementation to decide
>> what failed means and that potentially all calls will be in 
>this "queue"?
>
>It does appear that these definitions need to be revised so that
>"failed" is not seen as restrictive.
>
>> * 1006  Hutton: 180 Ringing
>> 
>> "Hutton, Andrew" <[email-masked]>
>> Section 6: I think that the URI of the monitor (i.e. 
>Call-Info) should
>> be included also in a 180 Ringing because the caller may need to know
>> that callback is available before deciding to give up on the ringing
>> call.
>
>That is a good point, and I think that the group agreed with 
>it when you
>made it, but the -03 text does not reflect that consensus.  I will
>propose some edits about this.
>
>> * 3002  Hutton: Location of agents
>> 
>> "Hutton, Andrew" <[email-masked]>:
>> Abstract: "implementations at the caller's and callee's endpoints
>> cooperate to place the caller's request for call completion 
>into a queue
>> at the callee's endpoint".
>> I think the draft gives some mixed messages regarding the options for
>> where the caller's and callee's agent may be located and some
>> clarification is needed. Maybe the abstract should make it clear that
>> the document does not specify the location of the agents.
>
>Yes, I think that sentence in the Abstract needs to be revised.  The
>idea we want to convey is that the agent/monitor can be in the UAs
>themselves, or be in "servers" that are presumably involved in the
>endpoint's networks.
>
>> * 3003  Hutton: Appendixes
>> 
>> "Hutton, Andrew" <[email-masked]>
>> Introduction: "As a proof-of-concept, simple agents and monitors can
>be
>> devised that interact with users and UAs entirely through 
>standard SIP
>> mechanisms [RFC3265], [RFC4235] and [RFC3515], as described in the
>> Appendixes".
>> The appendixes do I think add to the confusion regarding where the
>> caller's agent is located as it describes features codes 
>being used to
>> invoke the service which seems at odd's with the abstract.
>
>> * 3009  Hutton: Example
>> 
>> "Hutton, Andrew" <[email-masked]>
>> Appendix A.  "Example Caller's Agent". 
>> This is an example of using a feature code to invoke the feature from
>> the "UA" would it be possible to also include an example 
>where the agent
>> is in the UA ?
>
>We could write such an example, but I don't think that it would add
>much to the document.  The call flow example in section 6 of -03 shows
>what behavior would look like if the agent/monitor were integrated into
>the UAs.  Indeed, the point of the Appendixes is to show that one can
>separate the agent/monitor from the UAs and still use SIP signaling to
>coordinate the agent/monitor with their respective UAs.
>
>Dale
>
>
>_______________________________________________
>BLISS mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/bliss
>

---

From: "Dale Worley" <[email-masked]>
Date: Fri, 06 Mar 2009 15:56:26 -0500

> that the two subscribes are related.

The stack I am most familiar with (sipX) can be used to implement
proxies, so it has no trouble issuing two requests with the same
Call-Id.  But that may not be true of other stacks, particularly those
intended exclusively for use in UAs.

The tremendous advantage of using the same Call-Id in both SUBSCRIBEs is
that the existing "merged request" logic will identify duplicates.

Other than for efficiency, I don't think that it is necessary to detect
duplicate subscriptions arriving at a callee -- if duplication is not
detected, the caller has two entries in the callee's queue.  The worst
result from that is that the caller is not available when the first
entry is selected, and then the second entry is selected, causing the
caller to be rung again.

Dale