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

["Huelsemann, Martin" <[e-mail]>]

Hi,

I have drawn two basic flows for a PSTN interworking, available at 
http://www.softarmor.com/sipping/drafts/Roach%20Call%20Completion%20interworking.pdf.
I think they show an interwoking according to Adams proposal, Adam please correct me if I'm wrong.

The interworking itself seems to be feasible to me, but looking at the flow where CCBS is invoked in the PSTN, I share Johns concern that the call completion INVITE (or respectivly the IAM with the call completion indication) has to be routed exactly via that MGC that has the function of the BFCP client and that handles that specific GRUU/GRID instance, and it's not determinstic that this will be the case in the PSTN as far as I know.
It has to be that particular MGC, because only this MGC knows the GRUU/GRID and could interwork it because of the IAM Calling Party Number and CCSS indication. 

So at least from a PSTN point of view there would be an advantage if the call completion call could be handled independently from a specific GRUU/GRID, perhaps as a kind of fallback mechanism for an interworking with networks that don't support GRUU.



Regards, Martin









> -----Ursprüngliche Nachricht-----
> Von: Adam Roach [mailto:[e-mail]] 
> Gesendet: Donnerstag, 2. November 2006 16:43
> An: Jonathan Rosenberg
> Cc: IETF Sipping List
> Betreff: 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