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

["GARCIN Sebastien RD-CORE-ISS" <[e-mail]>]

Hi Jeroen,

See below,

Regards,
sébastien 

-----Message d'origine-----
De : Jeroen van Bemmel [mailto:[e-mail]] 
Envoyé : mercredi 8 novembre 2006 10:06
À : GARCIN Sebastien RD-CORE-ISS; Michael Hammer (mhammer); Adam Roach; Jonathan Rosenberg (jdrosen)
Cc : IETF Sipping List
Objet : Re: [Sipping] comments on draft-roach-sipping-callcomp-bfcp-00

Sebastien,

It appears to me that the discussion is really not about "work versus not-work", but more about "elegant versus not-elegant" or "in the spirit of SIP(tm)"

My preference is also for a pure SIP-based solution, because adding BFCP adds an additional deployment burden on already feature-heavy SIP devices. 
You will end up with all the nightmares of firewall traversal, privacy features, etc, etc, all of which are (at least in the process of) being resolved within SIP.

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)

[SG: That depends on what you consider being the resource monitored. Basically if you consider that what is being monitored is "access to the B-user according to the CCSS service rules", then it is perfectly OK to send a notification to the "first non-suspended subscriber".]

If instead it was modeled / described as a subscription to a queue
*position* (where the subscriber does not know / need to know which position that is, relative to other subscribers), it makes more sense. IMO it would help if the underlying conceptual model were explicitly described in the draft.

[SG: We might be agreeing here, but further discussion would be needed I guess.]

Then, instead of "queue management", I would suggest to model suspend/resume as event filtering: the subscriber enables/disables his interest in the "available for a call" event.

Identification and prioritization of CCBS/CCNR calls over "regular" calls could be handled as follows: in the NOTIFY for "available for a call", add a URI to which the subscriber must send his INVITE. In this URI, put something (no need for standardization here, can e.g. be in the username ) that the callee can recognise as resulting from a CCBS/CCNR callback (this URI needs to be a GRUU). 

[SG: If a non-GRUU solution works and that the limitations are understood then I don't want to risk jeopardizing the service availability date just for the sake of having an elegant solution based on GRUU. IMHO draft-ploetzl-sipping is not the right place to specify whether GRUU is mandatory to the service or not, all that is needed is the protocol extensions and their limitations, it is not up to IETF to describe CCSS service logic.]

Alternatively, you could specify that the callback needs to take place in the context of the same dialog as the SUBSCRIBE/NOTIFY for the CCBS/CCNR event, but some people dislike such multi-usages.

[SG: You may be assuming that we are in an environment with forking, nonetheless forking is not mandatory and hence using GRUU shouldn't be either in the service implementation.]

Regards,

Jeroen

GARCIN Sebastien RD-CORE-ISS wrote:
> There may have been a slite misunderstanding, I do not believe that 
> using this BCFP mechanisn is the right way.
> The draft-ploetz-ccss based on SUB/NOT is my prefered solution to the 
> problem? Nobody to my knowledge has provided a "non-academic"
> explanation as to why it does not work, so why do I need to look 
> elsewhere?
>
> Moreover, migration from PSTN to SIP does require that the services 
> provided by the underlying SIP and PSTN networks look similar to the 
> users a least during the migration phase, there is not much one can do 
> about it.
>
> sébastien
>
>
> -----Message d'origine-----
> De : Michael Hammer (mhammer) [mailto:[e-mail]] Envoyé : 
> mardi 7 novembre 2006 19:51 À : GARCIN Sebastien RD-CORE-ISS; Adam 
> Roach; Jonathan Rosenberg
> (jdrosen)
> Cc : IETF Sipping List
> Objet : RE: [Sipping] comments on draft-roach-sipping-callcomp-bfcp-00
>
> I still have not seen a convincing explanation that any abuse exists.
> This feature is about meta information; precisely the type of 
> information that the events framework was intended.
>
> When the 486 Busy is received, that call is done.  It is then about 
> what is the state of the queue, and who should initiate the next call 
> involving the called party.
>
> My problem with the way this is headed, is that it is designing a SIP 
> feature using PSTN thinking.  You could get the same user experience, 
> but is modeling this with a mechanism designed for conference calls 
> the way to go?
>
> Mike
>
>
>> -----Original Message-----
>> From: GARCIN Sebastien RD-CORE-ISS
>> [mailto:[e-mail]]
>> Sent: Friday, November 03, 2006 5:17 AM
>> To: Adam Roach; Jonathan Rosenberg (jdrosen)
>> Cc: IETF Sipping List
>> Subject: RE: [Sipping] comments on
>> draft-roach-sipping-callcomp-bfcp-00
>>
>> hi
>>
>>>> The objections that I have repeatedly raised with the "abuse" of 
>>>> SUBSCRIBE to activate a service aren't purely academic
>>
>> I am still missing the "non-academic" arguments that would convince 
>> me not to the procedures in draft-ploetz.
>>
>> Thanks for clarifying that part.
>>
>> sébastien
>>
>> -----Message d'origine-----
>> De : Adam Roach [mailto:[e-mail]] Envoyé : jeudi 2 novembre
>> 2006 16:43 À : Jonathan Rosenberg Cc : IETF Sipping List Objet : Re:
>> [Sipping] comments on draft-roach-sipping-callcomp-bfcp-00
>>
>> Jonathan Rosenberg wrote:
>>> Its not clear to me that this mechanism works well in the face of 
>>> forking. Seems like you could end up with disparate queues
>> for each of
>>> my phones.
>>
>> That's pretty much what I intended, yes. As far as I can tell, the 
>> net result -- that is, the behavior of the system
>> -- would end up being identical (or, at least, substantially the
>> same) with queues maintained on each of your devices versus a single, 
>> centralized queue -- unless there's more than one of you, in which 
>> case neither solution will behave particularly gracefully (although I 
>> believe the forking setup has better recovery properties under such 
>> circumstances).
>>
>> When I get a spare moment, I'll work through a few scenarios to 
>> demonstrate how the externally observed system behavior is the same 
>> between distributed management of several queues and centralized 
>> management of one queue.
>>
>>> Similar issues arise when the originating user has multiple
>> devices.
>>> So if I call you from phone 1, and later you are available,
>> does the
>>> ringback happen only at phone 1 or all of my phones? Seems like the 
>>> latter is much more desirable. That too implies that a UA-based 
>>> solution on the originating side has some problems.
>>
>> That depends. Are you asserting this as a new requirement? No one has 
>> raised this capability as a requirement so far, and the previously 
>> offered solution certainly didn't have this property.
>>
>> To be clear: I agree that this is probably an improvement on the 
>> service; however, the more requirements we pile on, the harder a 
>> solution becomes -- and we've become experts at putting so many 
>> requirements on a problem that the solution space dwindles down to 
>> nothing.
>>
>>> There is clearly a relationship between all of this and presence; I 
>>> think you need to call that out.
>>
>> Martin beat me to it, but I'll reiterate his comment: the 
>> relationship here isn't related as much to presence as it is to 
>> dialog state. And that is called out in the discussion about 
>> centralized queue management.
>>
>>> On whether BFCP is the right thing or not for this problem, I'm not 
>>> sure. In one sense, you could characterize this as really a problem 
>>> with RFC3265 in general; that for certain event packages,
>> notification
>>> of an event to all watchers can cause them to take actions
>> that result
>>> in a further change to that same state. This is a race condition.
>>
>> Not in general -- this race condition arises in the draft-poetzl 
>> document because it's doing something with SUBSCRIBE that SUBSCRIBE 
>> was never meant to do: changing the state of the thing that is 
>> watched.
>>
>> Let's go back to first principles: SUBSCRIBE is a request to retrieve 
>> the state of a resource, and receive that state whenever it changes.
>> It's a way for an observer to *LOOK* at a state.
>>
>> Now, as I'm always having to tell my kids: you look with your eyes, 
>> not with your hands. If the act of subscribing to a state changes 
>> that very state, then you're no longer looking
>> -- you're touching. SUBSCRIBE doesn't touch the state it's 
>> monitoring. (Now, we have defined some
>> *meta* state regarding the very state of that subscription, but you 
>> need to subscribe to that separately, and the act of subscribing to 
>> that meta-state doesn't change the meta-state).
>>
>> If you violate the basic principles on which a protocol was 
>> developed, then, yes, you end up with protocol characteristics that 
>> are highly undesirable. The race condition you describe is one. The 
>> objections that I have repeatedly raised with the "abuse" of 
>> SUBSCRIBE to activate a service aren't purely academic: if you use a 
>> protocol in a way that is well outside its original design, then 
>> clearly identifiable bad things happen.
>>
>>> I share John's concerns as to whether this really
>> interoperates with
>>> the PSTN. Perhaps if you had some call flows demonstrating it, this 
>>> would help.
>>
>> Martin has put together some pretty nice call flows showing how this 
>> interoperates with the PSTN. Perhaps he could be convinced to share 
>> them with the wider group?
>>
>> /a
>>
>> _______________________________________________
>> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
>> This list is for NEW development of the application of SIP Use 
>> [e-mail] for questions on current sip Use 
>> [e-mail] 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 
>> [e-mail] for questions on current sip Use 
>> [e-mail] 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 
> [e-mail] for questions on current sip Use 
> [e-mail] 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 [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP