headers
Internet-Drafts | 8 Dec 2008 18:00
Picon
Favicon

I-D Action:draft-ietf-bliss-call-completion-03.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Basic Level of Interoperability for SIP Services Working Group of the IETF.

	Title           : Call Completion for Session Initiation Protocol (SIP)
	Author(s)       : D. Worley, et al.
	Filename        : draft-ietf-bliss-call-completion-03.txt
	Pages           : 28
	Date            : 2008-12-08

The features "call completion on busy subscriber" and "call
completion on no reply" allow the calling party of a failed call to
be notified when the called party becomes available to receive a
call.  This document describes an architecture for implementing these
features in the Session Initiation Protocol: "Call completion"
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, and, when a caller's request is ready to be
serviced, re-attempt the original, failed call.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-bliss-call-completion-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
Attachment (draft-ietf-bliss-call-completion-03.txt): message/external-body, 70 bytes
(Continue reading)

Permalink | Reply | 0 comments |
headers
Huelsemann, Martin | 8 Dec 2008 18:01
Picon

WG: New Version Notification for draft-ietf-bliss-call-completion-03

Hi,

a revision of the call-complition draft has just been uploaded.

Please note explicitly that this is not the major revison of the draft which then intoduces a multi-stage
call-complition solution, including dialog events and call-completion events, which we have talked
about in Minneapolis.

This is a revision of the proposal for the usage of a call-completion event package, with a lot of detailed
defintions and clarifications. Comments as input for further revisons are welcome.

A proposal for a dialog correlation, which may be needed to correlate the initial dialog and a
subscription, is not longer part of this draft, this is discussed now in other drafts.

Regards, Martin

-----Ursprüngliche Nachricht-----
Von: IETF I-D Submission Tool [mailto:idsubmission@...] 
Gesendet: Montag, 8. Dezember 2008 17:48
An: Hülsemann, Martin
Cc: dworley@...; Jesske, Roland
Betreff: New Version Notification for draft-ietf-bliss-call-completion-03 

A new version of I-D, draft-ietf-bliss-call-completion-03.txt has been successfuly submitted by
Martin Huelsemann and posted to the IETF repository.

Filename:	 draft-ietf-bliss-call-completion
Revision:	 03
Title:		 Call Completion for Session Initiation Protocol (SIP)
Creation_date:	 2008-12-08
(Continue reading)

Permalink | Reply | 0 comments |
headers
Elwell, John | 9 Dec 2008 14:59
Picon

Next steps with draft-ietf-ach-analysis - consensus call

I would like to get list confirmation of what was agreed in the BLISS
session in Minneapolis concerning this draft. My notes (I don't see any
minutes yet!) indicate the following:

- target the document at BCP rather than informational;
- add normative statements where appropriate (in particular for use of
response codes);
- stick to 480 as the response code for explicit rejection / local;
- make reference to a to-be-written framework draft on REST (Jonathan
Rosenberg / Keith Griffin)
- define URL structures for ACH configuration (forwarding, DND, etc.)
and give examples;
- reference a generic event package for notifications of resource
changes (draft-roach-sip-http-subscribe seems to be a candidate).

Please let me know if you disagree by 2008-12-19.

John
Permalink | Reply | 0 comments |
headers
Theo Zourzouvillys | 11 Dec 2008 06:59
Picon
Favicon

Re: [Fwd: I-D Action:draft-roach-sip-http-subscribe-00.txt]

On Thu, Dec 11, 2008 at 5:48 AM, Mark Nottingham <mnot@...> wrote:

>> That's interesting -- Mark, do you have any input on the topic?
>
> I'm having trouble parsing the above -- is the concern that some people
> might believe that any link in the headers *has* to be mirrored in the
> content? If so, that's the first time I've heard this brought up, and it
> certainly isn't the intent. We can clarify if necessary.

Nope, I was just trying to point out - all be it with some rather
awful grammar - that when a new link type is defined, it can be used
in any of the places links can be used; i.e, in <head>, <atom:link/>,
or Link header (or draft-nottingham-site-meta).

 ~ Theo

--

-- 
Theo Zourzouvillys
Chief Technical Officer
VoIP.co.uk - Commerce House, Telford Road, Bicester, OX26 4LD
Tel: +44 1908 764 196
Permalink | Reply | 1 comment |
headers
Theo Zourzouvillys | 11 Dec 2008 07:14
Picon
Favicon

Re: [Fwd: I-D Action:draft-roach-sip-http-subscribe-00.txt]

On Thu, Dec 11, 2008 at 5:57 AM, Mark Nottingham <mnot@...> wrote:

> * Conversely, if you are you intent on allowing transfer of an entity with a
> notification, you may want to consider allowing the transfer of multiple
> entities, to allow the use of content negotiation (e.g., both an English and
> French representation under the same URI, or a png and a gif).
> application/http would support this.

Although in our own implementation of this internally we transfer a
diff of the body that changes, we're currently only using it for XML
files.  After reading this in relation to something more substantial
like an image, the thought of transferring potentially unbounded
amounts of data for an entity representation in a single SIP
notification scares me - that's what we have HTTP for!

 ~ Theo

--

-- 
Theo Zourzouvillys
Chief Technical Officer
VoIP.co.uk - Commerce House, Telford Road, Bicester, OX26 4LD
Tel: +44 1908 764 196
Permalink | Reply | 0 comments |
headers
Mark Nottingham | 11 Dec 2008 06:48
Favicon
Gravatar

Re: [Fwd: I-D Action:draft-roach-sip-http-subscribe-00.txt]

Sorry for the delay, finally off the road and had a chance to read.

Overall I like this document a lot, and I think it should be easy to  
align its use of the 'monitor' link relation with the Atom-over-HTTP  
protocol described in draft-nottingham-http-cache-channels.

A couple of comments / concerns:

* "...it MUST return a Link: header..." seems like it's too strong;  
servers may want to be selective about when they offer monitoring, and  
there may be other ways to advertise it that are more appropriate.

* Following on that thought, the idea behind the most recent Link  
draft is to talk about link relations generically, and make Link  
headers one use of them. Another use of them is in draft-nottingham- 
site-meta (which is still under pretty active revision); this would  
allow you to advertise a monitoring endpoint for your whole site, for  
example.

* "It MAY return both." is ambiguous; think you mean SIP + SIPS.

* 3.4 Subscription Duration -- just a thought, is it worth tying the  
default subscription duration to the freshness lifetime of the HTTP  
response (as defined by HTTP)?

* 3.5.1 message/httpfrag -- did you consider using application/http  
(defined in RFC2616)? I mention this because HTTP already defines how  
to update a cache entry's headers based upon a HEAD or 304 response;  
it would be nice to reuse that if possible. Also, what does making the  
status-line optional bring? The semantics of the message would be
(Continue reading)

Permalink | Reply | 8 comments |
headers
Mark Nottingham | 11 Dec 2008 06:57
Favicon
Gravatar

Re: [Fwd: I-D Action:draft-roach-sip-http-subscribe-00.txt]

Three more;

* Does the NOTIFY message include the URI of the resource that has  
changed (didn't see it, but I may be missing something). It should be  
added if not; otherwise, you're baking in a one-to-one relationship  
between monitoring channels and http URIs. There will be use cases  
where the receiver of the NOTIFY doesn't have enough context to  
associate the message body you're sending with a URI.

* The simplest and most efficient notification message to send is  
"this resource has changed"; the client can then decide whether or not  
to fetch an update, and combining any old response with a new one is  
simple. It also assures that the subscribing client isn't required to  
implement a cache. I would very much encourage you to support this  
mode of interaction.

* Conversely, if you are you intent on allowing transfer of an entity  
with a notification, you may want to consider allowing the transfer of  
multiple entities, to allow the use of content negotiation (e.g., both  
an English and French representation under the same URI, or a png and  
a gif). application/http would support this.

Cheers,

On 11/12/2008, at 4:48 PM, Mark Nottingham wrote:

> Sorry for the delay, finally off the road and had a chance to read.
>
> Overall I like this document a lot, and I think it should be easy to  
> align its use of the 'monitor' link relation with the Atom-over-HTTP
(Continue reading)

Permalink | Reply | 1 comment |
headers
Mark Nottingham | 11 Dec 2008 07:01
Favicon
Gravatar

Re: [Fwd: I-D Action:draft-roach-sip-http-subscribe-00.txt]

Ah - got it.  Yes, that's the intent, and hopefully more places besides.

Cheers,

On 11/12/2008, at 4:59 PM, Theo Zourzouvillys wrote:

> On Thu, Dec 11, 2008 at 5:48 AM, Mark Nottingham <mnot@...>  
> wrote:
>
>
>>> That's interesting -- Mark, do you have any input on the topic?
>>
>> I'm having trouble parsing the above -- is the concern that some  
>> people
>> might believe that any link in the headers *has* to be mirrored in  
>> the
>> content? If so, that's the first time I've heard this brought up,  
>> and it
>> certainly isn't the intent. We can clarify if necessary.
>
> Nope, I was just trying to point out - all be it with some rather
> awful grammar - that when a new link type is defined, it can be used
> in any of the places links can be used; i.e, in <head>, <atom:link/>,
> or Link header (or draft-nottingham-site-meta).
>
> ~ Theo
>
> -- 
> Theo Zourzouvillys
> Chief Technical Officer
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alan Johnston | 11 Dec 2008 22:36

Re: Shared Appearances Open Issue: Calls without Appearance Numbers

Dale.Worley@... wrote:
>    From: Alan Johnston <alan@...>
>
>    We have come up with an alternative mechanism for this where a 
>    consultation call would be considered "logically" joined to another 
>    appearance.
>
> Does that place any restrictions on the state of the "another
> appearance"?  

I do not believe it does.    Each other appearance could be in any state .

> Presumably not, or the mechanism could not be used in
> all cases.  But if there is no such restriction on the another
> appearance, perhaps we should devise a fixed, dummy appearance
> number/name to use in this construction.
>   

Well, if we need to assign an appearance number, then we might as well 
use a real one.  The hope is that we can avoid having to assign a new 
appearance number by making it "logically joined" with another appearance.

Thanks,
Alan

> Dale
> _______________________________________________
> BLISS mailing list
> BLISS@...
> https://www.ietf.org/mailman/listinfo/bliss
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alan Johnston | 11 Dec 2008 22:39

Re: Shared Appearances Open Issue: Publish to AOR

I tend to agree with Dale here.  Normally, there is no state agent for 
the dialog package, but this is a case where it makes sense, and is 
actually required.  As such, it is worth calling attention to 
implementers that this state agent will need to serve all dialog state 
requests.

For example, a DERIVE subscribe would need to be served by this state agent.

I do not expect any new normative language - this would just be 
explanatory text there to help implementers.

Thanks,
Alan

Dale.Worley@... wrote:
>    From: Jason Fischl <jason@...>
>
>    Why does this draft need to call this out? This is standard
>    behavior.  Do we really think that somebody is ever going to have
>    two state agents with one for dialog events and one for dialog
>    events originating from shared appearances? If that was the case,
>    we wouldn't use dialog event for SA.
>
> It's not particularly standard if one's background is in SIP systems
> that don't use state agents at all.  For instance, I sat through the
> entire IETF presentation without realizing that the shared-appearance
> state agent *of necessity* services all out-of-dialog SUBSCRIBEs and
> PUBLISHes for dialog events (at least for the SA AORs).  This has
> various implications for a system architecture where the domain's
> proxy is a *proxy* that routes all requests to the appropriate UA or
(Continue reading)

Permalink | Reply | 0 comments |

Gmane