Subject: RE: [Sipping] comments on draft-roach-sipping-callcomp-bfcp-00

From: "Elwell, John" <[email-masked]>
Date: Wed, 08 Nov 2006 21:39:07 +0000

As I stated at the mic yesterday and also in an earlier email, I do not
think the BFCP approach is a sensible way of solving the call completion
problem.

Setting aside alternative solutions that might be more appropriate in a pure
SIP environment, if the main driver is to provide a solution that can
interwork with PSTN CCBS/CCNR, we should try to satisfy this requirement in
the simplest way possible. IMO, BFCP is not the simplest approach and
introduces unwanted complexity, particularly at a gateway. I think the
Poetzle draft is a far better starting point, especially if we could try to
align it better with the principles of RFC 3265, for example following some
of the suggestions of Jeroen.

John   

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: 08 November 2006 13:49
> To: Jeroen van Bemmel
> Cc: IETF Sipping List; Adam Roach; Michael Hammer (mhammer)
> Subject: Re: [Sipping] comments on 
> draft-roach-sipping-callcomp-bfcp-00
> 
> About the usage of BFCP, chairs started a poll yesterday during the 
> meeting, but decided to stop it after 5/10 people raised 
> their hand to 
> vote for "this is a good approach"...
> Then, Rohan(I think) asked "who understand  / is interested by the 
> problem"?, and since few people were responding, nobody got 
> the chance 
> to vote for "this is NOT a good approach"...
> 
> So, maybe we can start a new poll on mailing list with 
> *interested* people?
> 
> Jeroen van Bemmel wrote:
> 
> > That being said, I believe what is triggering the 
> "academic" objections is the underlying model of 
> draft-poetzl-sipping-call-completion-01: multiple 
> subscriptions to a single resource (the CCBS/CCNR queue) but 
> a single notification to the "first, non-suspended 
> subscriber". That goes against
> > RFC3265 (in more than one ways)
> >   
> Can you clatify this statement? for me, this  is not 
> completely clear why...
> 
> 
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments of core SIP
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 8 Nov 2006 16:16:54 -0600

Embedded below. 

> From: Elwell, John [mailto:[email-masked]] 
> Sent: Wednesday, November 08, 2006 13:39
> To: [email-masked]; Jeroen van Bemmel
> Cc: Adam Roach; IETF Sipping List; Michael Hammer (mhammer)
> Subject: RE: [Sipping] comments on 
> As I stated at the mic yesterday and also in an earlier 
> email, I do not think the BFCP approach is a sensible way of 
> solving the call completion problem.

As I also said at the mike, I agree 100% with John. Using 
a separate protocol like BFCP for CCBS+CCNR does not seem to
be a sensible way of solving this problem.

> Setting aside alternative solutions that might be more 
> appropriate in a pure SIP environment, if the main driver is 
> to provide a solution that can interwork with PSTN CCBS/CCNR, 
> we should try to satisfy this requirement in the simplest way 
> possible. IMO, BFCP is not the simplest approach and 
> introduces unwanted complexity, particularly at a gateway. I 
> think the Poetzle draft is a far better starting point, 
> especially if we could try to align it better with the 
> principles of RFC 3265, for example following some of the 
> suggestions of Jeroen.

I completely agree again. 

I would also like to start with a native SIP approach based on
something like the Poetzle draft. If we want to start with a really
simple approach we can also look at section 2.17 of 
http://www.ietf.org/internet-drafts/draft-ietf-sipping-service-examples-
11.txt
as a starting point.

But yes, if a plain dialog-package approach is not sufficient, then 
defining a package like in
http://tools.ietf.org/wg/sipping/draft-poetzl-sipping-call-completion-01
.txt seems much more appealing than using BFCP.