Subject: RE: [SIP] REFER progress

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Tue, 9 Jan 2001 15:03:57 -0800

This makes some sense to me. If the alternate proposal is saying that UA's
"don't really need to implement the full SUB/NOT for REFER (eg using
implicit subscription, single response)" then it is not really SUB/NOT at
all - so why confuse things and call it that? As Robert Sparks says, if you
want to add full(er) subscription functionality later then it simply
confuses things between UA's that do and do not fully implement
SUBSCRIBE/NOTIFY.
 
If REFERDONE is being used _explicitly_ for REFER response status then this
seems more in line with our design goals than _implicitly_ using a NOTIFY to
do the same thing (and easier to parse IMO). I am not advocating that each
function gets its own method but if you are saying that UA's do not need to
implement full SUB/NOT then we should not be using NOTIFY for this purpose.
 
Robert.

-- My opinions are my own and should not be taken as representing those of
Nuera Communications, Inc. -- 

 -----Original Message-----
From: Robert Sparks [ mailto:[email-masked]
<mailto:[email-masked]> ]
Sent: Wednesday, January 10, 2001 9:03 AM
To: 'Tom-PT Taylor'; Robert Sparks; 'Rohan Mahy'; Sean Olson
Cc: sip
Subject: RE: [SIP] REFER progress

If you have enough of the SUB/NOTIFY mechanism to include an event
header, you can create profiles on the event that will tell you what
the many NOTIFYs coming back mean. I again argue that to go down
this path sanely, you want an explicit subscribe to a particular event.
 
Now - to push again for closure of the work item at hand.
 
Allowing more than one NOTIFY is probably solvable, but is
going to take a _lot_ of discussion. If we restrict the behavior
to one reciprocal request, and call it NOTIFY, we close
the door on allowing more than one NOTIFY in the future.
 
Hence I push again for REFERDONE. That gets us to where we
thought we were with NOTIFY before we ran afoul of the timeout
problem. This will satisfy the working group deliverable.
 
_Future_ work can work add notifies to the scenario by extension,
preferably in the context of SIP Events.

RjS

-----Original Message-----
From: Tom-PT Taylor [mailto:[email-masked]]
Sent: Tuesday, January 09, 2001 2:54 PM
To: Robert Sparks; 'Rohan Mahy'; Sean Olson
Cc: sip
Subject: RE: [SIP] REFER progress

I assumed the originator would be subscribed to all of the responses
associated with the transaction, simply as a consequence of piggybacking on
the general SUBS/NOTIFY mechanism as applied to SIP events.

> -----Original Message----- 
> From: Robert Sparks [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> Sent: Tuesday, January 09, 2001 2:24 PM 
> To: 'Rohan Mahy'; Sean Olson; Robert Sparks 
> Cc: sip 
> Subject: RE: [SIP] REFER progress 
> 
> 
> As far as I can thell, You and Sean are assuming you get 
> exactly one NOTIFY then. 
> 
> At that point we're just quibbling on the method name. 
> 
> Or do you disagree? If you are assuming more than one 
> NOTIFY, then I think you missed my point. 
> 
> RjS 
> 
> 
> 
> > -----Original Message----- 
> > From: Rohan Mahy [ mailto:[email-masked] <mailto:[email-masked]> ] 
> > Sent: Tuesday, January 09, 2001 12:50 PM 
> > To: Sean Olson; Robert Sparks 
> > Cc: [email-masked] 
> > Subject: Re: [SIP] REFER progress 
> > 
> > 
> > Hi, 
> > 
> > I agree with Sean that an implicit NOTIFY is 
> straightforward, no more 
> > complicated than REFERDONE and solves the timeout problem.  I 
> > hope we don't 
> > need a meeting to close this issue.  ;-) 
> > 
> > The "other" problem, however, is the one that opened the 
> can of worms. 
> > What primitive(s) do you use to get attended transfer to 
> > work?  All of the 
> > proposals (something like 4 of them) work and solve the 
> > requirement for an 
> > attended transfer.  Some of these proposals deal more with 
> > the  bis draft 
> > (see Tom Taylor's post today).  Everyone seems to want other 
> > features as 
> > well, but we need to see at least a "sketch" of the 
> complete features 
> > picture associated with each proposal.  This is why I 
> > proposed the one-day 
> > face-to-face meeting. 
> > 
> > thanks, 
> > -rohan 
> > 
> > 
> > 
> > At 12:15 PM 1/9/01 , Sean Olson wrote: 
> > >I'm sorry, I don't see the standardization of the 
> > >REFERDONE as being any easier than the standardization 
> > >of a NOTIFY to serve the same purpose. 
> > > 
> > >To satisfy a need stated by Billy, the 
> > >body of the NOTIFY could simply be the SDP 
> > >from the 200 OK (assuming an INVITE) or empty 
> > >for a BYE. Uses of REFER for other methods would 
> > >need to be specified in extension drafts. 
> > >The Event: token could be "referdone". 
> > > 
> > >Is there anything else that needs to be specified 
> > >for the use of NOTIFY that I am missing? 
> > > 
> > >I don't wish to drag this out forever. I think 
> > >the solution is fairly simple and straightforward 
> > >and could be extended in the future. 
> > > 
> > >Please point out faults with this proposal and 
> > >areas of implementation difficulty. 
> > >/sean 
> > > 
> > >Robert Sparks wrote: 
> > > 
> > >> a.s. This got a little long - sorry 
> > >>      It does contain a concrete proposal. 
> > >> ------------ 
> > >> I think we are falling into a set of traps 
> > >> with the REFER discussions, endangering an 
> > >> already overdue deliverable. 
> > >> 
> > >> The worst is specification creep. The group 
> > >> was pretty happy with the functionality of 
> > >> the current draft. When we tripped up on the 
> > >> timeout problem, we saw a host of extra 
> > >> functionality we could add while working 
> > >> around that problem. 
> > >> 
> > >> Most of us have gravitated towards a model 
> > >> where REFER is answered with a set of 
> > >> reciprocal responses (essentially NOTIFYs, 
> > >> possibly of a different name, with or without 
> > >> an explicit subscribe). What we _haven't_ 
> > >> spent much time on is the profile of those 
> > >> responses. How many can there be? What do 
> > >> they contain? 
> > >> 
> > >> I really anticipate the answers to those last 
> > >> questions will vary widely depending on the 
> > >> application using REFER. We want to be able 
> > >> to do other things than transfer (this is 
> > >> why the method got renamed from TRANSFER). 
> > >> A rich response set for a REFER that triggers 
> > >> a SUBSCRIBE is likely to be entirely different 
> > >> in character from one that triggers an INVITE. 
> > >> 
> > >> 
> > >> PROPOSAL 
> > >> In interests of meeting our working group 
> > >> deliverable on this topic (now _WAY_ overdue), 
> > >> I suggest that obtaining this rich response 
> > >> set has shown itself to be too big a bite. I 
> > >> propose that it is time to fall back to a single 
> > >> REFERDONE reciprocal request, carrying the 
> > >> information that is provided in the current 
> > >> draft's final response. This would provide a 
> > >> baseline version of REFER that would meet the 
> > >> requirements the current draft addresses. 
> > >> 
> > >> I further propose that when we complete that work, 
> > >> we can return to REFER and define an extension that 
> > >> would get the richer response set, addressing the 
> > >> current lack of definition of that response set 
> > >> with something like sip-event profiles. 
> > >> 
> > >> RjS 
> > >> 
> > >> 
> > >> 
> > >> _______________________________________________ 
> > >> SIP mailing list 
> > >> [email-masked] 
> > >> http://lists.bell-labs.com/mailman/listinfo/sip
<http://lists.bell-labs.com/mailman/listinfo/sip>  
> > > 
> > > 
> > >_______________________________________________ 
> > >SIP mailing list 
> > >[email-masked] 
> > > http://lists.bell-labs.com/mailman/listinfo/sip
<http://lists.bell-labs.com/mailman/listinfo/sip>  
> > 
> 
> 
> _______________________________________________ 
> SIP mailing list 
> [email-masked] 
> http://lists.bell-labs.com/mailman/listinfo/sip
<http://lists.bell-labs.com/mailman/listinfo/sip>

---

From: Sean Olson <[email-masked]>
Date: Tue, 09 Jan 2001 17:24:55 -0600

I have a small problem with this logic. What I am
proposing is perfectly inline with SUB/NOT and is
not a radical deviation from it. I argued for implicit
subscriptions in the SUB/NOT draft specifically for
this type of situation. With regards to the complexity
of the solution using NOTIFY, I don't see much difference
between NOTIFY and REFERDONE in this case. Both will
need to indicate a final response code. The NOTIFY
solution happens to use the Event: header. The body
of the NOTIFY may or may not contain SDP. The
receiving client of course is free to ignore it.
I'm not advocating anything like XML be used for this.
The only modification I would make in a future extension
would be the support of multiple NOTIFYs and this is
*very* easily handled by a client that supports a single
NOTIFY. (Provisional responses in the NOTIFY can simply
be ignored)

I'm not going to argue forever on this, I promise :)
I just would prefer that NOTIFY be used over REFERDONE
barring any more substantial arguments.

/sean

Fairlie-Cuninghame, Robert wrote:

> This makes some sense to me. If the alternate proposal is saying that 
> UA's "don't really need to implement the full SUB/NOT for REFER (eg 
> using implicit subscription, single response)" then it is not really 
> SUB/NOT at all - so why confuse things and call it that? As Robert 
> Sparks says, if you want to add full(er) subscription functionality 
> later then it simply confuses things between UA's that do and do not 
> fully implement SUBSCRIBE/NOTIFY.
> 
>  
> 
> If REFERDONE is being used _explicitly_ for REFER response status then 
> this seems more in line with our design goals than _implicitly_ using a 
> NOTIFY to do the same thing (and easier to parse IMO). I am not 
> advocating that each function gets its own method but if you are saying 
> that UA's do not need to implement full SUB/NOT then we should not be 
> using NOTIFY for this purpose.
> 
>  
> 
> Robert.
> 
> -- My opinions are my own and should not be taken as representing those 
> of Nuera Communications, Inc. --
> 
>  
> 
> From: Robert Sparks [mailto:[email-masked]]
>         I assumed the originator would be subscribed to all of the 
>         responses associated with the transaction, simply as a 
>         consequence of piggybacking on the general SUBS/NOTIFY mechanism 
>         as applied to SIP events.
>         
>          > From: Robert Sparks [mailto:[email-masked]]
>          > > From: Rohan Mahy [mailto:[email-masked]]

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Tue, 09 Jan 2001 18:41:55 -0500

> barring any more substantial arguments.

There clearly is no deep technical difference between

REFERDONE

and

NOTIFY
Event: Refer-Done

However, I believe we've tried to make the point in other venues that
events are a fundamental mechanism that has broad applicability. This
smells like an event (as in "let me tell you, something happened") as
opposed to "do something". Thus, I would find it easier to explain the
overall architecture if we consistently labeled (call-related and other)
events as NOTIFY rather than inventing a new method name for each type
of event. By that logic, we should have PRESENT and NOT-PRESENT and
VOICEMAIL-ARRIVED and who knows what else. Can be done, just seems like
it degnerates into an unstructured list of dozens of methods rather than
some logical hierarchy of "this is an event, with a type label".

As has been pointed out in addition, there is no complexity benefit to
limiting notification just to completion of the referred operation. We
may want other status updates in the future and I certainly don't want
to invent a new method for each.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Alan Johnston <[email-masked]>
Date: Tue, 09 Jan 2001 21:17:35 -0600

I'd be OK with REFER generating an implicit NOTIFY response (instead of
REFERDONE) as long as:

1. This usage of NOTIFY is defined in a document separate from the other
presence stuff (maybe even part of the REFER document).  Our PSTN Gateways
will never implement full presence, but we will want them to support various
types of call transfers using REFER.  Writing requirements for vendors that
say "implement only this piece of this document" is problematic.

2. There are separate event for the progress of the REFERed Request (18x
response received) vs. completion of the REFERed Request (final response -
2xx or failure).  This way, we can implement all the different types of call
transfers in the PSTN, completely blind transfers, transfers where you
disconnect after the target phone rings, and fully attended transfer where
you only disconnect after a successful completion of the transfer.  I'm not
necessarily in favor of multiple NOTIFY per REFER, just that the REFER
should be able to specify which call progress or completion event will
generate the one and only NOTIFY.

Thanks,
Alan Johnston
WorldCom

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 09 Jan 2001 22:46:19 -0500

> say "implement only this piece of this document" is problematic.

This is similar to the other uses of NOTIFY outside presence, such as
the vmail notification and some of the suggested uses in connection with
conferences. I can't see much that needs to be said generically, since
NOTIFY is just another method. (Most of the discussion in the
presence/events documents seems to be about SUBSCRIBE, with NOTIFY
receiving relatively little coverage.) Thus, beyond saying a sentence
about Call-IDs, this should all be contained in the REFER draft.

> generate the one and only NOTIFY.

Agreed. It would be easy enough to specify multiple Event labels and
this would be consistent, I believe, with the overall event
architecture. If desired, details can then be encoded as message/sip, as
suggested earlier.

---

From: "Robert Sparks" <[email-masked]>
Date: Wed, 10 Jan 2001 09:09:38 -0600

Ok - I think I see enough of a consensus trend to take this and produce
a revised draft.

I will use the idea of an implicit subscribe and  a _single_ NOTIFY to
the Event: refer-done. We can deal with other Event:s in subsequent work.

To mitigate risk, please try to take Rick's thread to completion quickly.

RjS

> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Tuesday, January 09, 2001 9:46 PM
> To: Alan Johnston
> Cc: Henning G. Schulzrinne; Sean Olson; Fairlie-Cuninghame, Robert;
> 'Robert Sparks'; 'Tom-PT Taylor'; 'Rohan Mahy'; sip

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 10 Jan 2001 17:00:40 -0600

In response to Alan's point about document structure, I am concerned that
the implicit subscription is not supported in the current version of the
SIP-Events draft. I had previously strongly opposed an implicit
subscription, but am ready to yield that argument based on further
discussion. However, if we do go with an implied subscription, I would like
to make sure the supporting language makes it back into SIP-Events (sorry
Adam :-) ).

I want to avoid the situation where NOTIFY is defined in multiple places
with varying semantics.

Ben.

> From: Alan Johnston [mailto:[email-masked]]
> Sent: Tuesday, January 09, 2001 9:18 PM
> To: Henning G. Schulzrinne
> Cc: Sean Olson; Fairlie-Cuninghame, Robert; 'Robert Sparks'; 'Tom-PT
> Taylor'; 'Rohan Mahy'; sip