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

["Elwell, John" <[e-mail]>]

Martin,

Thanks for preparing these examples. Concerning the point about managing
without GRUU/GRID for call completion calls that come in via a different
MGC, how exactly would this work?

By the way, I am not sure if it has already been mentioned in this context,
but GRID is no longer part of GRUU.

John 

> -----Original Message-----
> From: Huelsemann, Martin [mailto:[e-mail]] 
> Sent: 03 November 2006 12:52
> To: [e-mail]
> Cc: [e-mail]
> Subject: AW: [Sipping] comments on 
> draft-roach-sipping-callcomp-bfcp-00
> 
> 
> Hi,
> 
> I have drawn two basic flows for a PSTN interworking, available at 
> http://www.softarmor.com/sipping/drafts/Roach%20Call%20Complet
> ion%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
> 

_______________________________________________
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