RE: [Sipping-tispan] Re: CCBS/CCNR in Version -02f

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

Sebastien,

I was not trying to open up an old debate. I was simply continuing the
recent debate about on whose behalf the service provider is acting, and
whether there are two service providers or one. I can see a role for a
service provider acting on behalf of the callee, since it needs to look out
for different UAs registered for the AoR concerned that might be in a
position to satisfy the CCBS/CCNR request. I am not sure I understand what a
service provider acting on behalf of the caller would do. It would be good
to get an answer to my question about whether a CCBS/CCNR request results in
a call from the same UA as that from which the request was made or any UA
registered as contact for the caller's AoR.

John


> -----Original Message-----
> From: GARCIN Sebastien RD-CORE-ISS 
> [mailto:[e-mail]] 
> Sent: 29 September 2005 09:11
> To: Elwell, John; Miguel Garcia; Michael Hammer (mhammer)
> Cc: Tessa Silvia; [e-mail]
> Subject: RE: [Sipping-tispan] Re: CCBS/CCNR in Version -02f
> 
> John,
> 
> You seems to want try and open the endless debate about where 
> the intelligence should be placed in the network or in the 
> terminals. The approach you are proposing is not something 
> that TISPAN will accept so I suggest that we move out of this debate.
> 
> sébastien 
>  
> 
> -----Message d'origine-----
> De : [e-mail] 
> [mailto:[e-mail]] De la part de Elwell, John
> Envoyé : jeudi 29 septembre 2005 08:20
> À : Miguel Garcia; Michael Hammer (mhammer)
> Cc : Tessa Silvia; [e-mail]
> Objet : RE: [Sipping-tispan] Re: CCBS/CCNR in Version -02f
> 
> Miguel,
> 
> In-line,
> 
> John
> 
> > -----Original Message-----
> > From: Miguel Garcia [mailto:[e-mail]]
> > Sent: 28 September 2005 10:31
> > To: Michael Hammer (mhammer)
> > Cc: Tessa Silvia; [e-mail]
> > Subject: Re: [Sipping-tispan] Re: CCBS/CCNR in Version -02f
> > 
> > Hi Mike:
> > 
> > Inline discussion.
> > 
> > Michael Hammer (mhammer) wrote:
> > 
> > > Miguel,
> > > 
> > > I think there is still a little bit of schizophrenia in the 
> > > requirements.  I assume that a server is acting on behalf
> > of either the
> > > caller or the callee, but not both because each could be 
> served by a 
> > > different host, domain, or organization.  The first
> > requirement seems to
> > > assume that the CCBS is a terminating service of the 
> callee.  Other 
> > > requirements seem to assume that the CCBS is a service of
> > the caller.
> > > Which is it?
> > 
> > Both. It has been demonstrated that CCBS is a service that requires 
> > cooperation of both the originating and terminatine service 
> providers.
> > This cooperation is mostly required to manage queues of both the 
> > caller and callee, and to manage susped/resume states.
> [JRE] It is not clear to me what the involvement of the 
> originating service provider is. Perhaps this comes down to 
> what exactly are the requirements for notifying the caller 
> that a call may now succeed. Is this notification constrained 
> to go to the same UA that requested CCBS/CCNR in the first 
> place, or should it go to any UA currently registered as a 
> contact for the caller's AoR? In my opinion the former is 
> sufficient and indeed probably preferable. If I request 
> CCBS/CCNR from a particular UA I would expect to receive the 
> notification on that same UA and make the new call attempt 
> from there. In the relatively infrequent event that I move to 
> a different UA in the intervening period, I could simply 
> request CCBS/CCNR again from the new UA.
> 
> So on the assumption that CCBS/CCNR involves only a single UA 
> on the caller side, what service does the originating service 
> provider perform? Why can't the UA directly request CCBS/CCNR 
> and communicate with the service provider on the callee side 
> to achieve this? The caller's UA will receive notification 
> when a the call can be made and can present that information 
> to the caller somehow, allowing the caller to choose when to 
> proceed with that call, e.g., whether to interrupt any 
> ongoing communications in order to make that call.
> 
> 
> _______________________________________________
> Sipping-tispan mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/sipping-tispan
> 

_______________________________________________
Sipping-tispan mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/sipping-tispan