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

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

Mike,

Hopefully the so-called recall would be presented to the user as a CCBS
recall and not just as a normal incoming call. This would allow the
appropriate user to identify it as such (if there are multiple users) and
would also allow that user to prioritise the handling of the recall with
respect to any other activities he/she is performing at the time.

John

> -----Original Message-----
> From: Michael Hammer (mhammer) [mailto:[e-mail]] 
> Sent: 29 September 2005 15:28
> To: Elwell, John; GARCIN Sebastien RD-CORE-ISS; Miguel Garcia
> Cc: Tessa Silvia; [e-mail]
> Subject: RE: [Sipping-tispan] Re: CCBS/CCNR in Version -02f
> 
> It seems to make more sense to focus on the request being 
> from a specific terminal of the user.  I can picture the call 
> completed to another terminal with a second person and the 
> ensuing, "no you called me" confusion.
> 
> Mike
>  
> 
> > -----Original Message-----
> > From: Elwell, John [mailto:[e-mail]] 
> > Sent: Thursday, September 29, 2005 8:22 AM
> > To: GARCIN Sebastien RD-CORE-ISS; Miguel Garcia; Michael 
> > Hammer (mhammer)
> > Cc: Tessa Silvia; [e-mail]
> > Subject: RE: [Sipping-tispan] Re: CCBS/CCNR in Version -02f
> > 
> > Sebastien,
> > 
> > Irrespective of the need for a service provider on the caller 
> > side, what is the requirement concerning the call resulting 
> > from CCBS/CCNR - should it use the same caller UA as that 
> > which issued the CCBS/CCNR request, or should it use any UA 
> > registered as contact for the AoR concerned?
> > 
> > John
> >  
> > 
> > > -----Original Message-----
> > > From: GARCIN Sebastien RD-CORE-ISS
> > > [mailto:[e-mail]]
> > > Sent: 29 September 2005 12:58
> > > To: Elwell, John; Miguel Garcia; Michael Hammer (mhammer)
> > > Cc: Tessa Silvia; [e-mail]
> > > Subject: RE: [Sipping-tispan] Re: CCBS/CCNR in Version -02f
> > > 
> > > John,
> > > 
> > > Basically it enables "service interactions", "charging model", 
> > > "control of subscriber rights to the service", "playing 
> > CCBS related 
> > > announcement"...Having the service logic embedded in an 
> Application 
> > > Server serving the originating user makes all this possible.
> > > 
> > > If you want a more detailed to understand the role of the service 
> > > provider acting of behalf of the caller, I suggest you read the 
> > > related section dealing with the originating exchange in 
> > ITU-T Q.733 
> > > or contact your Siemens collegues that participate to TISPAN.
> > > 
> > > Regards,
> > > sébastien
> > > 
> > > 
> > > 
> > > 
> > > -----Message d'origine-----
> > > De : Elwell, John [mailto:[e-mail]] Envoyé : 
> > jeudi 29 
> > > septembre 2005 13:11 À : GARCIN Sebastien RD-CORE-ISS; 
> > Miguel Garcia; 
> > > Michael Hammer (mhammer) Cc : Tessa Silvia; 
> [e-mail] 
> > > Objet : RE: [Sipping-tispan] Re: CCBS/CCNR in Version -02f
> > > 
> > > 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