Subject: RE: [SIP] REFER progress

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Wed, 10 Jan 2001 10:52:24 -0000

I was unsure on whether to throw this in on the SUBSCRIBE/NOTIFY discussion
or on the REFER discussion.

If I can go back to some of the early ISDN discussions (groans no doubt all
round) and come up with some of the requirements that went into the ISDN
Notification indicator, then those requirements identified a need for
something that 

-	was to be sent to the end user
-	did not need to be understood along the way
-	was not critical to the end terminal (i.e. could be thrown away if
not required).

The ISDN version could have ended up better, but does the above give some
starting point to writing down some requirements in this area, and then
deciding on a single generic mechanism, rather than ending up with different
things in separate drafts. So rephrasing in SIP speak

-	need a means for a proxy or remote UA to send information to the
other UA.
-	intervening proxies on the path do not need to be able to understand
any of the contents, and will simply pass on the contents without
modification.
(Discussion point - is there a need to include user identification in such
information that needs to be subject to the privacy draft)
-	a receiving UA does not need to understand the contents; if they are
not understood, then the information is discarded.
-	the information could consist of multiple parameters.
-	needs to be able to be included with other SIP request response
flows, or in a request of its own.
-	may be in association with an existing session, or may be
independent of a session.

I would also not that if we came up with a mechanism that fulfilled these
requirements (and I get the impression that an Event header used in extended
circumstances, with NOTIFY as a carriage mechanism where no other request
exists, would do that), then some of the requirements of the
diversion/forwarding draft could also be met by it, e.g. the need to inform
the calling and forwarded-to users that forwarding has taken place.

Ready to duck.

Keith

Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: [email-masked]

> ----------
> From: 	Rohan Mahy[SMTP:[email-masked]]
> Sent: 	09 January 2001 18:49
> 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
> >
> >
> >_______________________________________________
> >SIP mailing list
> >[email-masked]
> >http://lists.bell-labs.com/mailman/listinfo/sip
> 
> 
> _______________________________________________
> SIP mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/sip
> 

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip