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

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

Hi,

it seems that would be a general problem, how to interwork a GRUU to a network that doesn't support GRUU, and which parameters are available to reassemble a GRUU at the interworking function. Of course that is a problem of the 'non-GRUU' network, but I think at least in the PSTN this problem cannot be solved.
So from the PSTN point of view I would suggest a solution that works - as a alternative or fallback mechanism - with that part of the GRUU that can be interworked and perhaps with a general call completion indication for the prioritization.

Regards, Martin





> -----Ursprüngliche Nachricht-----
> Von: Elwell, John [mailto:[e-mail]] 
> Gesendet: Freitag, 3. November 2006 15:47
> An: Hülsemann, Martin; [e-mail]
> Cc: [e-mail]
> Betreff: RE: [Sipping] comments on 
> draft-roach-sipping-callcomp-bfcp-00
> 
> 
> 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%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
> > 
> 

_______________________________________________
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