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

From: Miguel Garcia <[email-masked]>
Date: Mon, 03 Oct 2005 14:40:35 +0300

Hi John:

It should be part of the vesion -02h.

http://people.nokia.net/~miguel/drafts/pre/draft-jesske-sipping-tispan-requirements-02h.html

Check out REQ-CCBS/CCNR-12

/Miguel

Elwell, John wrote:

> Jean-Marie,
> 
> Thanks for your help. This needs to get reflected in the requirements (not
> necessarily the susbscription option stuff, but the ability to be able to
> send the recall notification to either the UA that requested CCBS/CCNR or to
> all UAs).
> 
> John
>  
> 
> 
>>-----Original Message-----
>>From: Stupka, Jean-Marie [mailto:[email-masked]] 
>>Sent: 30 September 2005 08:58
>>To: Elwell, John; Paul Kyzivat; GARCIN Sebastien RD-CORE-ISS
>>Cc: [email-masked]; Tessa Silvia
>>Subject: RE: [Sipping-tispan] Re: CCBS/CCNR in Version -02f
>>
>>John,
>>
>>ETSI EN 300 357 (V1.2.1): "Integrated Services Digital 
>>Network (ISDN); Completion of Calls to Busy Subscriber (CCBS) 
>>supplementary service; Service description" says in subclause 
>>5.1, Provision/withdrawal:
>>
>>--
>>As a service provider option, the CCBS supplementary service 
>>can be offered with a subscription option which shall apply 
>>to the whole access of user A. The subscription option is 
>>detailed in Table 1.
>>
>>Table 1
>>Subscription option: Recall mode
>>Values:
>>- Global, i.e. CCBS recall offered to all terminals
>>- Specific, i.e. CCBS recall offered to the terminal, which 
>>activated the CCBS supplementary service
>>
>>If the subscription option is not offered, one of the two 
>>values shall be chosen by the service provider.
>>--
>>
>>I believe this answers your question.
>>
>>Best regards,
>>Jean-Marie
>> 
>>-----Original Message-----
>>From: [email-masked] 
>>[mailto:[email-masked]] On Behalf Of Elwell, John
>>Sent: Friday, September 30, 2005 8:47 AM
>>To: Paul Kyzivat; GARCIN Sebastien RD-CORE-ISS
>>Cc: [email-masked]; Tessa Silvia
>>Subject: RE: [Sipping-tispan] Re: CCBS/CCNR in Version -02f
>>
>>Exactly. We need to know the full set of requirements in 
>>order to select a
>>protocol solution, and only then can we see whether we need 
>>any protocol
>>extensions or not. So is it one UA or all UAs at the caller 
>>side that need
>>to know that the callee is available?
>>
>>John
>>
>>
>>>-----Original Message-----
>>>From: Paul Kyzivat [mailto:[email-masked]] 
>>>Sent: 29 September 2005 17:44
>>>To: GARCIN Sebastien RD-CORE-ISS
>>>Cc: [email-masked]; Tessa Silvia
>>>Subject: Re: [Sipping-tispan] Re: CCBS/CCNR in Version -02f
>>>
>>>
>>>
>>>GARCIN Sebastien RD-CORE-ISS wrote:
>>>
>>>>Paul,
>>>>
>>>>As far as I know there has been yet no firm decision from 
>>>
>>>TISPAN on this particular point. 
>>>
>>>>On this mailing list our efforts should focuse on getting 
>>>
>>>the necessary SIP extension understood and agreed, the 
>>>competent body for taking service decisions is clearly not IETF.
>>>
>>>I have agreed with you on this.
>>>
>>>
>>>>The problem we are discussing here requires no protocol 
>>>
>>>extension and hence should not be inserted in the draft.   
>>>
>>>But I don't know how you can say no protocol extension is required 
>>>without knowing what decision will be taken to this point.
>>>
>>>In general, I don't see how we can agree whether protocol 
>>>extensions are 
>>>required or not without understanding the definition of the service.
>>>
>>>In fact, I think one must consider the possible 
>>>implementations to the 
>>>service definition before one can decide that an extension is 
>>>or is not 
>>>needed. (One solution may require an extension, while another 
>>>solution 
>>>does not.)
>>>
>>>I am not happy with the way this exercise is going. It seems to be 
>>>trying to avoid stating the details of the service 
>>>requirements, or the 
>>>proposed solution, while stating requirements for extensions 
>>>needed for 
>>>some unstated solution.
>>>
>>>I think what we need is:
>>>
>>>1. a thorough statement of the how the feature is expected to
>>>    appear to users. (Not PSTN users, but users of sip 
>>>devices that have
>>>    the emulated services.)
>>>
>>>2. an outline of a proposed implementation (or alternative
>>>    implementations)
>>>
>>>3. a list of the requirements for currently nonexistent sip features
>>>    that prevent 2 from being implemented.
>>>
>>>4. specifications for new extensions that satisfy 2&3.
>>>
>>>I believe the very first submission came close to providing 
>>
>>2&4, but 
>>
>>>lacked 1&3. I had thought the intent was to provide 1, and 
>>>then to move 
>>>on to 2,3&4. But instead it seems like now the goal is to 
>>>just do 3&4, 
>>>without 1&2.
>>>
>>>I just don't see how we can make an informed decision on that basis.
>>>
>>>	Paul
>>>
>>>
>>>>sébastien
>>>>
>>>>-----Message d'origine-----
>>>>De : Paul Kyzivat [mailto:[email-masked]] 
>>>>Envoyé : jeudi 29 septembre 2005 16:47
>>>>À : GARCIN Sebastien RD-CORE-ISS
>>>>Cc : Tom-PT Taylor; Tessa Silvia; [email-masked]
>>>>Objet : Re: [Sipping-tispan] Re: CCBS/CCNR in Version -02f
>>>>
>>>>
>>>>
>>>>GARCIN Sebastien RD-CORE-ISS wrote:
>>>>
>>>>
>>>>>Thanks for clarifying the question which is of interest but 
>>>
>>>out of scope of the mailing list. 
>>>
>>>>>I invite John and anybody else interested to participate to 
>>>
>>>TISPAN meetings were those questions are debated.
>>>
>>>>
>>>>I agree that debating which way TISPAN *wants* this to work 
>>>
>>>is out of scope here.
>>>
>>>>But it seems there is still confusion about which choice 
>>
>>TISPAN *has
>>
>>>>made* about this. That needs to be cleared up here.
>>>>
>>>>I'm now pretty sure that TISPAN wants all the caller's UAs 
>>>
>>>to alert when it is time for the CCBS/CCNR request to be 
>>>completed, but I think my understanding of this is via 
>>>discussion rather than what is in the document. (I just 
>>>checked the -02g document and I can find nothing that states 
>>>which choice is intended.)
>>>
>>>>So I believe the document needs to be updated to reflect 
>>>
>>>this in the description of the service, and via explicit 
>>
>>requirements.
>>
>>>>	Paul
>>>>
>>>>
>>>>
>>>>>sebastien
>>>>>
>>>>>
>>>>>-----Message d'origine-----
>>>>>De : Tom-PT Taylor [mailto:[email-masked]] Envoyé : jeudi 29 
>>>>>septembre 2005 15:46 À : GARCIN Sebastien RD-CORE-ISS Cc 
>>
>>: Elwell, 
>>
>>>>>John; Miguel Garcia; Michael Hammer (mhammer); Tessa Silvia; 
>>>>>[email-masked] Objet : Re: [Sipping-tispan] Re: 
>>>
>>>CCBS/CCNR in 
>>>
>>>>>Version -02f
>>>>>
>>>>>Paul has already given his response to the substance of 
>>>
>>>John's question, but I thought I would try to make it clearer 
>>>to you.  Suppose the caller has multiple devices, say a cell 
>>>phone and a fixed line, as possible contacts, all through the 
>>>same address of record.  John is asking whether the call 
>>>returned by CCBS must come back to the cell phone if that is 
>>>where the original call came from, or whether any of the 
>>>devices associated with that address of record could receive 
>>>the return call.
>>>
>>>>>GARCIN Sebastien RD-CORE-ISS wrote:
>>>>>
>>>>>
>>>>>
>>>>>>John,
>>>>>>
>>>>>>I am not sure I understand your question. I assume you are 
>>>
>>>asking about how the O-AS gets the calling party issue the 
>>>CCBS/CCNR recall or ...?
>>>
>>>>>>If this is the case, we are studying several possibilities 
>>>
>>>(3rd party call, REFER...) in TISPAN but none of them have 
>>>SIP extension requirements.
>>>
>>>>>>Could you please be more specific as to what requirement 
>>>
>>>you feel needs to be captured?
>>>
>>>>>>sébastien
>>>>>>
>>>>>>
>>>>>>
>>>>>>-----Message d'origine-----
>>>>>>De : Elwell, John [mailto:[email-masked]] Envoyé 
>>>
>>>: jeudi 29 
>>>
>>>>>>septembre 2005 14:22 À : GARCIN Sebastien RD-CORE-ISS; 
>>>
>>>Miguel Garcia; 
>>>
>>>>>>Michael Hammer (mhammer) Cc : Tessa Silvia; 
>>>
>>>[email-masked] 
>>>
>>>>>>Objet : 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:[email-masked]]
>>>>>>>Sent: 29 September 2005 12:58
>>>>>>>To: Elwell, John; Miguel Garcia; Michael Hammer (mhammer)
>>>>>>>Cc: Tessa Silvia; [email-masked]
>>>>>>>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:[email-masked]] Envoyé 
>>>
>>>: jeudi 29 
>>>
>>>>>>>septembre 2005 13:11 À : GARCIN Sebastien RD-CORE-ISS; 
>>>
>>>Miguel Garcia; 
>>>
>>>>>>>Michael Hammer (mhammer) Cc : Tessa Silvia; 
>>>
>>>[email-masked] 
>>>
>>>>>>>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:[email-masked]]
>>>>>>>>Sent: 29 September 2005 09:11
>>>>>>>>To: Elwell, John; Miguel Garcia; Michael Hammer (mhammer)
>>>>>>>>Cc: Tessa Silvia; [email-masked]
>>>>>>>>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 : [email-masked] 
>>>>>>>>[mailto:[email-masked]] De la part de 
>>>
>>>Elwell, John 
>>>
>>>>>>>>Envoyé : jeudi 29 septembre 2005 08:20 À : Miguel 
>>>
>>>Garcia; Michael 
>>>
>>>>>>>>Hammer (mhammer) Cc : Tessa Silvia; 
>>>
>>>[email-masked] Objet :
>>>
>>>>>>>>RE: [Sipping-tispan] Re: CCBS/CCNR in Version -02f
>>>>>>>>
>>>>>>>>Miguel,
>>>>>>>>
>>>>>>>>In-line,
>>>>>>>>
>>>>>>>>John
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>-----Original Message-----
>>>>>>>>>From: Miguel Garcia [mailto:[email-masked]]
>>>>>>>>>Sent: 28 September 2005 10:31
>>>>>>>>>To: Michael Hammer (mhammer)
>>>>>>>>>Cc: Tessa Silvia; [email-masked]
>>>>>>>>>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
>>>>>>>>[email-masked]
>>>>>>>>https://www1.ietf.org/mailman/listinfo/sipping-tispan
>>>>>>>>
>>>>>>>
>>>>>>_______________________________________________
>>>>>>Sipping-tispan mailing list
>>>>>>[email-masked]
>>>>>>https://www1.ietf.org/mailman/listinfo/sipping-tispan
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>_______________________________________________
>>>>>Sipping-tispan mailing list
>>>>>[email-masked]
>>>>>https://www1.ietf.org/mailman/listinfo/sipping-tispan
>>>>>
>>>>
>>>>
>>>_______________________________________________
>>>Sipping-tispan mailing list
>>>[email-masked]
>>>https://www1.ietf.org/mailman/listinfo/sipping-tispan
>>>
>>
>>_______________________________________________
>>Sipping-tispan mailing list
>>[email-masked]
>>https://www1.ietf.org/mailman/listinfo/sipping-tispan
>>
> 
> 
> 
> _______________________________________________
> Sipping-tispan mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sipping-tispan

-- 
Miguel A. Garcia           tel:+358-50-4804586
sip:[email-masked]
Nokia Research Center      Helsinki, Finland

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

---

From: "Stupka, Jean-Marie" <[email-masked]>
Date: Tue, 4 Oct 2005 13:39:35 +0200

The mail exchange server has removed the subject line of my previous mail - sorry

For me "terminal" and "UA" are equivalent  -- I would like to continue using
the same features if I replace my ISDN terminals with SIP terminals.
       
            Jean-Marie

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Friday, September 30, 2005 4:48 PM
To: Elwell, John
Cc: Stupka, Jean-Marie; GARCIN Sebastien RD-CORE-ISS; [email-masked]; Tessa Silvia
Subject: Re: [Sipping-tispan] Re: CCBS/CCNR in Version -02f

Yes. Thank you Jean-Marie. I think I understand the implications of that 
for this discussion, but I am not certain. (I speak SIP, but I don't 
speak ISDN.) For instance I don't know if there is a complete 
equivalence between "terminal" and "UA".

That is why I think these requirements need to be translated from 
ISDN-speak to SIP-speak. I trust there are some people fluent in both 
who can do a correct translation.

	Paul

---

From: "GARCIN Sebastien RD-CORE-ISS" <[email-masked]>
Date: Tue, 4 Oct 2005 16:40:15 +0200

Paul,

The functionalites could be expanded provided they do not cause problems and delay the whole process. My suggestion is that if we cannot find solutions to every issue raised, we simply state the particular limitations we have identified. 

After all, the SIP community didn't seem to bother much about CCBS for the past few years so I believe that we should try and find reasonable solution in reasonable time scales.

sebastien

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Paul Kyzivat
Envoyé : mardi 4 octobre 2005 16:11
À : Stupka, Jean-Marie
Cc : [email-masked]
Objet : Re: [Sipping-tispan] Re: CCBS/CCNR in Version -02f

Stupka, Jean-Marie wrote:
> For me "terminal" and "UA" are equivalent  -- I would like to continue 
> using the same features if I replace my ISDN terminals with SIP terminals.

Sounds like you want a softswitch. If you want full emulation of features, then that is probably what it is going to take. And then you probably won't get any of the benefits of moving to sip.

But I thought the groundrules of this exercise included expanding the functionality so that it included new things, such as "terminals" that support other media, etc. As soon as you do that, you have to at least reinterpret the feature specifications, that never took such things into account.

For instance, suppose I have a terminal that does both voice and session mode IM. It is currently active in a session, doing only IM, not voice. 
Then someone attempts to invoke the CCBS feature toward it, for the purpose of making a voice call. Should it be considered busy, or not?

Do the Telcordia specs address such a case?

	Paul

> Yes. Thank you Jean-Marie. I think I understand the implications of 
> that for this discussion, but I am not certain. (I speak SIP, but I 
> don't speak ISDN.) For instance I don't know if there is a complete 
>>Thanks for your help. This needs to get reflected in the requirements 
>>(not necessarily the susbscription option stuff, but the ability to be 
>>able to send the recall notification to either the UA that requested 
>>CCBS/CCNR or to all UAs).
>>
>>John
>> 
>>
>>
>>
>>>ETSI EN 300 357 (V1.2.1): "Integrated Services Digital Network 
>>>(ISDN); Completion of Calls to Busy Subscriber (CCBS) supplementary 
>>>service; Service description" says in subclause 5.1, 
>>>Provision/withdrawal:
>>>
>>>--
>>>As a service provider option, the CCBS supplementary service can be 
>>>offered with a subscription option which shall apply to the whole 
>>>access of user A. The subscription option is detailed in Table 1.
>>>
>>>Table 1
>>>- Specific, i.e. CCBS recall offered to the terminal, which activated 
>>>the CCBS supplementary service
>>>
>>>If the subscription option is not offered, one of the two values 
>>>shall be chosen by the service provider.
>>>--
>>>
>>>Exactly. We need to know the full set of requirements in order to 
>>>select a protocol solution, and only then can we see whether we need 
>>>any protocol extensions or not. So is it one UA or all UAs at the 
>>>caller side that need to know that the callee is available?
>>>
>>>John
>>>
>>>
>>>
>>>>the necessary SIP extension understood and agreed, the competent 
>>>>body for taking service decisions is clearly not IETF.
>>>>
>>>>In general, I don't see how we can agree whether protocol extensions 
>>>>are required or not without understanding the definition of the 
>>>>service.
>>>>
>>>>In fact, I think one must consider the possible implementations to 
>>>>the service definition before one can decide that an extension is or 
>>>>is not needed. (One solution may require an extension, while another 
>>>>solution does not.)
>>>>
>>>>trying to avoid stating the details of the service requirements, or 
>>>>the proposed solution, while stating requirements for extensions 
>>>>needed for some unstated solution.
>>>>
>>>>I think what we need is:
>>>>
>>>>   appear to users. (Not PSTN users, but users of sip devices that 
>>>>have
>>>>   the emulated services.)
>>>>
>>>>lacked 1&3. I had thought the intent was to provide 1, and then to 
>>>>move on to 2,3&4. But instead it seems like now the goal is to just 
>>>>do 3&4, without 1&2.
>>>>
>>>>>De : Paul Kyzivat [mailto:[email-masked]] Envoyé : jeudi 29 
>>>>>septembre 2005 16:47 À : GARCIN Sebastien RD-CORE-ISS Cc : Tom-PT 
>>>>>Taylor; Tessa Silvia; [email-masked] Objet : Re: 
>>>>>[Sipping-tispan] Re: CCBS/CCNR in Version -02f
>>>>>
>>>>>
>>>>>
>>>>to alert when it is time for the CCBS/CCNR request to be completed, 
>>>>but I think my understanding of this is via discussion rather than 
>>>>what is in the document. (I just checked the -02g document and I can 
>>>>find nothing that states which choice is intended.)
>>>>
>>>>

---

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Tue, 4 Oct 2005 18:11:37 +0100

Joining in this thread at the point where I think it started going wrong.

As far as the called user is concerned there are two points where decision points can exist:

-	when the service is invoked, and the call is stacked at the B user
-	when the B user becomes free, the A user is recalled, and the resultant call is presented to B.

If you look at the ISDN stage 3 requirements for network B accepting the request, which I believe reflect the stage 1 requirements, we have the following:

"A request to activate CCBS to a given destination shall be accepted by network B and queued if:
- user B has subscribed to the given basic service; and,
- the limit on the number of CCBS requests to the given destination has not been exceeded (this limit is a network
provider option with a maximum value of 5); and,
- user B has not invoked a supplementary service which prohibits the activation of the CCBS supplementary
service against that destination; and,
- user B compatibility requirements are met."

The supplementary services that prevent invocation are not specified, and can be implementation specific. 

When the call completes, it appears to user B as any other call request, i.e. not specifically a CCBS call, although this information is known to the network of B because it has to be removed from queues and so on if it is successful.

I believe we should consider the issue as follows, following the precedent set by the ISDN service designers. If the CCBS call should fail because the called user does not require this type of call to be a CCBS request, then that should be performed at time of CCBS request, e.g. if the calling user is on a black list of telemarketeers or has not provided an identity, or whatever.

If the call should fail for the same reason as any other incoming call, e.g. the user no longer has a terminal registered with a compatible set of media capabilities, then that obviously takes place additionally at the time the CCBS call is made.

As Sebastien has already correctly stated, queued CCBS requests do not block any other incoming call, except at for the time that the B user has insufficient resources to deal with the incoming call. These are normal things like some terminals not being able to handle two incoming calls at once.

regards

Keith

> [mailto:[email-masked]]On Behalf Of Paul Kyzivat
> Sent: 28 September 2005 15:36
> I agree with mike.
> In the end, to the callee there is little difference between somebody 
> queued for CCBS and somebody ringing or queued on call 
> waiting. If you 
> have a phone with a good enough UI, it would probably be best 
> to see a 
> list of everyone waiting to talk to you, and to pick among 
> them, whether 
> that means they need to be rung back or not. That of course demands a 
> better UI than a black phone. If you have a black phone, then 
> you need 
> some other plan.
> 
> It seems that when designing the call waiting service, 
> somebody decided 
> that you could only deal with two calls at a time. But for 
> CCBS somebody 
> decided otherwise. Seems pretty braindead to me.
> 
> 	Paul
> 
> > Even with the stacking limit of 5, I still don't want to 
> have to answer
> > and hangup on 5 telemarketers to get to answer my friends 
> phone call.  I
> > accept that TISPAN can propose something bad, just don't 
> expect it to
> > stand in the final analysis.  I don't buy the argument that 
> because the
> > caller paid more, it is in the interest of the callee to 
> listen to him.
> > I think there is room for improvement on the experience of the
> > terminating callee, and that there needs to be balance here 
> between the
> > interests of the caller and callee.
> > 
> > Mike
> >  
> > 
> > 
> >>Sent: Wednesday, September 28, 2005 5:31 AM
> >>Cc: Schmidt, Christian; Tessa Silvia; [email-masked]
> 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.
> >>
> >>
> >>>This can be modeled as a feature of the caller only, the 
> >>
> >>callee, or a 
> >>
> >>>feature interaction between two services of the caller and callee.
> >>>Note, that once you involve a service that serves a callee 
> into the 
> >>>picture, then that server better keep straight what master 
> >>
> >>it serves.
> >>
> >>>I find it problematic that it is suggested that as a callee 
> >>
> >>I should 
> >>
> >>>be paying for a service, yet constrained by some other 
> >>
> >>caller that I 
> >>
> >>>perhaps have no relation to, or worse is belligerant 
> >>
> >>towards me.  What 
> >>
> >>>stops some collusion of callers from stacking up CCBS 
> >>
> >>requests to the 
> >>
> >>>point where I can not receive any incoming calls?
> >>
> >>With respect the charging aspects, I don't know much about 
> >>it, and they are mostly outside the scope of the 
> >>specification. It may happen that you pay only for 
> >>successfully completed calls. Or, as I have noticed in some 
> >>countries, the service is offered for free, since it is the 
> >>interest of the operator that you complete the call, and at 
> >>that time, you are charged.
> >>
> >>The other aspect you are discussing relatest to the security 
> >>aspects of the service, or, in other words, a malicious 
> >>usage. I believe the PSTN/ISDN CCBS service provides for a 
> >>maximum number of stacked CCBS requests for a given user (it 
> >>sounds to me that the number is 5), so that if the limit is 
> >>reached, CCBS requests are rejected. In any case, there is no 
> >>protocol impact, just an implementation of a policy to avoid 
> >>misuse of the service.
> >>
> >>
> >>
> >>>I think that this whole mechanism may come down to whether 
> a callee 
> >>>accepts or rejects subscriptions to their dialog state.  To 
> >>
> >>say that a 
> >>
> >>>callee can not reject the CCBS request is akin to saying 
> >>
> >>that he can 
> >>
> >>>not reject a Subscription request to dialog state.  I don't 
> >>
> >>think that 
> >>
> >>>holds water.
> >>
> >>No, no, I didn't say that the callee cannot reject a 
> >>subscription request to the dialog state. I said that TISPAN 
> >>does not have such requirement. It does not mean that, if the 
> >>protocol allows it, the request can be rejected if the callee 
> >>desires it. But TISPAN does not have that requirement, so it 
> >>shouldn't be included in the TISPAN requirements document.
> >>
> >>
> >>>Arguments to the effect that ETSI ETS XXX didn't think of this are 
> >>>unpersuasive.  The logic of the requirements should stand alone.
> >>
> >>But as I said, these are the TISPAN requirements. Other 
> >>individual or organizations may have similar, complementary, 
> >>and hopefully non-contradictory requirements. I don't see a 
> >>problem with that approach.
> >>
> >>
> >>>I may be unclear about how many actors are involved here 
> >>
> >>(2, 3, 4?), 
> >>
> >>>but hopefully this will be sorted out.
> >>>
> >>>Cheers,
> >>>Mike
> >>>
> >>>
> >>
> >>BR,
> >>
> >>         Miguel
> >>
> >>--

---

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Tue, 4 Oct 2005 18:11:37 +0100

As Jean Marie has already pointed out, if you look at the ISDN service, and the dreaded point-to-multipoint access, you will find that there is a subscription option there for network A to either offer the CCBS recall to all compatible terminals, or to offer the CCBS recall to the specific terminal that activated the service. (Note that the network provider does not have to offer this option, but it is provided for in the specification, and the ISDN protocol elements to support it exist).

The direct SIP analogy would be to offer the call to the invoking terminal, or to all registered terminals of the invoking user with the same contact address, and with appropriate preferences. 

When the call is offered to all terminals, we therefore possibly need to look at whether we need other caller preferences, or whether the media related preferences are sufficient.

regards

Keith

> Sent: 29 September 2005 15:47
> I agree that debating which way TISPAN *wants* this to work is out of 
> scope here.
> 
> But it seems there is still confusion about which choice TISPAN *has 
> I'm now pretty sure that TISPAN wants all the caller's UAs to 
> alert when 
> it is time for the CCBS/CCNR request to be completed, but I think my 
> understanding of this is via discussion rather than what is in the 
> document. (I just checked the -02g document and I can find 
> nothing that 
> states which choice is intended.)
> 
> So I believe the document needs to be updated to reflect this in the 
> description of the service, and via explicit requirements.
> 
> 	Paul
> 
> > sebastien
> >  
> > 
> > De : Tom-PT Taylor [mailto:[email-masked]] 
> > Envoyé : jeudi 29 septembre 2005 15:46
> > Cc : Elwell, John; Miguel Garcia; Michael Hammer (mhammer); 
> Tessa Silvia; [email-masked]
> >>De : Elwell, John [mailto:[email-masked]] Envoyé : 
> jeudi 29 
> >>Michael Hammer (mhammer) Cc : Tessa Silvia; [email-masked] 
> >>>If you want a more detailed to understand the role of the service 
> 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 
> >>
> >>>>You seems to want try and open the endless debate about where the 
> >>>>Envoyé : jeudi 29 septembre 2005 08:20 À : Miguel Garcia; Michael 
> >>>>>This cooperation is mostly required to manage queues of both the 
> >>>>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 
> >>>>relatively infrequent event that I move to a different UA in the 
> >>>>caller side, what service does the originating service provider 
> >>>>with the service provider on the callee side to achieve this? The 
> >>>>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.
> >>>>
> >>>>