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

From: "Schmidt, Christian" <[email-masked]>
Date: Tue, 27 Sep 2005 14:31:33 +0200

That proposal sounds good for me.
Only a short tiping error: prioritize instead of priotirize.

Regards,
Christian

Schmidt, Christian wrote:

> 
> 
> We have already have REQ 12 stating that
> 	 Any communication performed as a result of the execution of a
> CCBS/CCNR request should be distinguishable from regular
communications.
> 
> So,  all terminating call are "distinguishable" and any policy a
network
> might have could be easily based on this, without further
requirements.
> Other views ?
> 
> Christian: I see, perhaps you can add a short explanation for this
purpose:
> 	 Any communication performed as a result of the execution of a
> CCBS/CCNR request should be distinguishable from regular
communications.
> This can be used to priorize CCBS/CCNR calls towards the callee.
> What do you think?
> 

I have a proposal for this requirement:

    REQ-CCBS/CCNR-12:
    It must be possible for the network to priotirize CCBS/CCNR recalls
    towards the callee, above regular calls. This implies that any
    communication performed as a result of the execution of a CCBS/CCNR
    request should be distinguishable from regular communications.

/Miguel

> Regards
> Silvia

-- 
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: "Schmidt, Christian" <[email-masked]>
Date: Wed, 28 Sep 2005 07:58:07 +0200

CCBS/CCNR are features of the caller only, so the callee never 
have to pay for this.

Priority of CCBS/CCNR call does not mean, that normal calls are not
offered to the callee at all, only with lower priority. What this
mean in practice is implementation choice.

But on one thing I agree, the callee should have the choice, to
allow / disallow CCBS/CCNR calls with him as callee in general.
Would this help?

Christian

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Paul Kyzivat
Gesendet: Dienstag, 27. September 2005 23:28
An: Michael Hammer (mhammer)
Cc: Tessa Silvia; [email-masked]
Betreff: Re: [Sipping-tispan] Re: CCBS/CCNR in Version -02f

I agree with mike. Especially, I think it is important to be clear about 
  what is the responsibility of a service operating for the caller and 
what is the responsibility of a service operating for the callee. It 
might be best to model this as two services.

	Paul

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?
> 
> 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?
> 
> 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.
> 
> Arguments to the effect that ETSI ETS XXX didn't think of this are
> unpersuasive.  The logic of the requirements should stand alone.
> 
> I may be unclear about how many actors are involved here (2, 3, 4?), but
> hopefully this will be sorted out.
> 
> Cheers,
> Mike
> 
> 
> 
>>-----Original Message-----
>>From: Miguel Garcia [mailto:[email-masked]] 
>>Sent: Tuesday, September 27, 2005 7:37 AM
>>To: Michael Hammer (mhammer)
>>Cc: Schmidt, Christian; Tessa Silvia; [email-masked]
>>Subject: Re: [Sipping-tispan] Re: CCBS/CCNR in Version -02f
>>
>>Mike, see inline comments.
>>
>>[email-masked] wrote:
>>
>>
>>
>>>The behavior of the terminating caller should be based on 
>>
>>the operation and policy of the terminating user, who should 
>>have the option to reject such a request.  The current 
>>wording seems vague on this point.  How about:
>>
>>I am afraid that TISPAN does not have a requirement to give 
>>the possibility of the callee to reject a CCBS request. By 
>>reading ETSI ETS 300 357 I didn't find such requirement.
>>
>>Since this document covers the Input requirements from 
>>TISPAN, I am afraid we cannot write that requirement on the document.
>>
>>
>>>REQ-CCBS/CCNR-yy: If the callee accepts invocation of a 
>>
>>CCBS service, 
>>
>>>other terminating calls to this callee should be treated as 
>>
>>though the callee was already busy.
>>
>>More or less... the text is fine if it is worded with respect 
>>the caller:
>>
>>"If the caller accepts a CCBS recall, other terminating calls 
>>towards the callee should be treated as if the callee were 
>>already busy".
>>
>>Note that this requires to add a definition of the "CCBS 
>>recall", which dependes on "CCBS call":
>>
>>CCBS call: a communnication generated by the network 
>>connecting the caller to the callee resulting from the 
>>callers' acceptance of a CCBS recall.
>>
>>CCBS recall: an indication informing the caller that the 
>>network is ready to initiate a CCBS call to the callee and 
>>that the network is awaiting a response to this indication.
>>
>>How about that?
>>
>>
>>>Note, there are a number of depedencies (feature 
>>
>>interactions) here.  Callee could be capable of receiving 
>>multiple calls, may have forwarding on busy set, etc.
>>
>>True... for all services. We don't discuss service 
>>interaction in the draft, unless we see a need for protocol 
>>development.
>>
>>/Miguel
>>
>>
>>>Mike
>>>
>>
>>--

---

From: "GARCIN Sebastien RD-CORE-ISS" <[email-masked]>
Date: Wed, 28 Sep 2005 17:33:52 +0200

Mike,

I fully agree that this is an issue we need to consider. However, the scenario you are describing is already taken care of by existing CCBS service logic. In the PSTN, upon determination that the callee has become free, the destination exchange starts a timer in order for the callee to have a chance of passing calls before being "CCBS-recalled". 

This timer is known as the "Destination B Idle Guard Timer" and should last between 0 and 15 seconds (see Q.733)

This behavior will of course be simulated in case of SIP.   

Regards
sebastien

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Michael Hammer (mhammer)
Envoyé : mercredi 28 septembre 2005 16:15
À : Miguel Garcia
Cc : Tessa Silvia; [email-masked]
Objet : RE: [Sipping-tispan] Re: CCBS/CCNR in Version -02f

Miguel,

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
> Hi Mike:
> Inline discussion.
> > 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.
> 
> > 
> > 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
> 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.
> 
> 
> > 
> > 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.
> 
> > 
> 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: "GARCIN Sebastien RD-CORE-ISS" <[email-masked]>
Date: Thu, 29 Sep 2005 10:10:58 +0200

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

> Sent: 28 September 2005 10:31
[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.

---

From: "GARCIN Sebastien RD-CORE-ISS" <[email-masked]>
Date: Thu, 29 Sep 2005 13:57:43 +0200

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

> From: GARCIN Sebastien RD-CORE-ISS
> [mailto:[email-masked]]
> Sent: 29 September 2005 09:11
> To: Elwell, John; Miguel Garcia; Michael Hammer (mhammer)
> 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
>  
> 
> 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
> 
> [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.
> 
>

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 29 Sep 2005 13:22:06 +0100

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

> Sent: 29 September 2005 12:58
> 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
> 
> 
> 
> 
> 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
> 
>

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Thu, 29 Sep 2005 10:26:06 -0400

Thanks for pointing that out.  So, the requirement is there.

Mike

> From: Jesske, R [mailto:[email-masked]] 
> Sent: Thursday, September 29, 2005 12:19 AM
> To: [email-masked]; Michael Hammer (mhammer)
> Cc: [email-masked]; [email-masked]
> Subject: AW: [Sipping-tispan] Re: CCBS/CCNR in Version -02f
> 
> Dear Miguel and Mike,
> The ETSI specification is based on Q.733.3. Within this 
> specification it is described how a CCBS call can be rejected 
> by the user B. 
> 
> ...For example if the destination local exchange knows that 
> the CCBS is forbidden on the destination B user, then the 
> diagnostic field shall be set to "CCBS not possible". 
> Otherwise the diagnostic field shall be set to "CCBS possible"....
> 
> So this describes if user be does not allows a CCBS call. 
> This is a little hidden within the spec. But it is stated. So 
> we can write  such a requirement. So either we need such an 
> indication  "CCBS possible" or the CCBS request shall be 
> rejected by the AS of the callee.
> 
> Best Regards
> 
> Roland
> 
> > Von: [email-masked]
> > [mailto:[email-masked]] Im Auftrag von 
> Miguel Garcia
> > Gesendet: Dienstag, 27. September 2005 13:37
> > An: [email-masked]
> > the operation and policy of the terminating user, who 
> should have the 
> > option to reject such a request.  The current wording seems 
> vague on 
> > this point.  How about:
> > 
> > I am afraid that TISPAN does not have a requirement to give the 
> > possibility of the callee to reject a CCBS request. By reading ETSI 
> > ETS 300 357 I didn't find such requirement.
> > 
> > Since this document covers the Input requirements from TISPAN, I am 
> > afraid we cannot write that requirement on the document.
> > 
> > > 
> > CCBS service, other
> > > terminating calls to this callee should be treated as
> > More or less... the text is fine if it is worded with respect the 
> > caller:
> > 
> > "If the caller accepts a CCBS recall, other terminating 
> calls towards 
> > the callee should be treated as if the callee were already busy".
> > 
> > Note that this requires to add a definition of the "CCBS recall", 
> > which dependes on "CCBS call":
> > 
> > CCBS call: a communnication generated by the network connecting the 
> > caller to the callee resulting from the callers' acceptance 
> of a CCBS 
> > recall.
> > 
> > CCBS recall: an indication informing the caller that the network is 
> > ready to initiate a CCBS call to the callee and that the network is 
> > awaiting a response to this indication.
> > 
> > How about that?
> > 
> > > 
> > interactions) here.  Callee could be capable of receiving multiple 
> > calls, may have forwarding on busy set, etc.
> > 
> interaction in the 
> > draft, unless we see a need for protocol development.
> > 
> > /Miguel
> > 
> > > 
> > > Mike
> > > 
> > 
> > --

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Thu, 29 Sep 2005 10:28:25 -0400

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

> From: Elwell, John [mailto:[email-masked]] 
> Sent: Thursday, September 29, 2005 8:22 AM
> To: GARCIN Sebastien RD-CORE-ISS; Miguel Garcia; Michael 
> Hammer (mhammer)
> 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
>  
> 
> > 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
> > 
> > 
> > 
> > 
> > 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] 
> 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
> > 
> >

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 29 Sep 2005 16:03:54 +0100

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

> From: Michael Hammer (mhammer) [mailto:[email-masked]] 
> Sent: 29 September 2005 15:28
> To: Elwell, John; GARCIN Sebastien RD-CORE-ISS; Miguel Garcia
> 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
>  
>

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Thu, 29 Sep 2005 11:53:57 -0400

I can go along with the direction this thread has taken.  I guess I am mainly pointing out that this in effect is an interaction with what in the PSTN are implemented as hunt group features.  The nature of a call to a SIP AOR is broader than what was typically to a PSTN line.  Just wanted to take such things into account.

Mike

> Sent: Thursday, September 29, 2005 11:04 AM
> To: Michael Hammer (mhammer); GARCIN Sebastien RD-CORE-ISS; 
> Miguel Garcia
> 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
> 
> > 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
> >  
> > 
> > > To: GARCIN Sebastien RD-CORE-ISS; Miguel Garcia; Michael Hammer 
> > > (mhammer)
> > > 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
> > >  
> > >

---

From: "Hans Erik van Elburg (RY/ETM)" <[email-masked]>
Date: Thu, 29 Sep 2005 20:43:44 +0200

A way out of this is to update the informational text so that it satisfies (1). I doubt that we should hint at the solution (2) in a requirements document, we can discuss (2) on the list though.

(3) should be represented as requirements.

and (4) is the step to take after we have agreed upon the requirements draft.

Otherwise this conversation will go on forever... blocking progress of all requirements which is in nobodies interest.

Best Regards,

/Hans Erik

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Paul Kyzivat
Sent: Thursday, September 29, 2005 8:06 PM
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,
> 
> The process you describe 1,2,3, and 4 sounds nice. The trouble is that 1&2 is something that TISPAN has been working upon for some time now for a number of legacy services some of them not even mentionned in the requirements draft.  
> 
> Would it not be possible for IETF to reference to TISPAN documentation as far as 1&2 are concerned and focuse on 3&4 ? Of course the TISPAN people are there to answer any questions which can help when working upon 3&4.

If you want IETF participation here it would be good to make it easy.

I looked up the references for this feature. I got what appear to be 
ISDN specifications. They in no way consider how the feature is impacted 
by the environment of a SIP environment. So IMO they don't don't come 
close to addressing 1&2.

I have no doubt that you have discussed 1&2 in some forum, but I don't 
see how I would discover the results of that. Am I not properly 
following the references?

	Paul

> De : Paul Kyzivat [mailto:[email-masked]] 
> Envoyé : jeudi 29 septembre 2005 18:44
> À : 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:
> 
>>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
>>
>>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
>>>
>>>
>>>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
>>>>
>>>>
>>>>
>>>>De : Elwell, John [mailto:[email-masked]] Envoyé : jeudi 29 
>>>>septembre 2005 14:22 À : GARCIN Sebastien RD-CORE-ISS; Miguel Garcia; 
>>>>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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>"control of subscriber rights to the service", "playing CCBS related 
>>>>>related section dealing with the originating exchange in ITU-T Q.733 
>>>>>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
>>>>
>>>>>>intelligence should be placed in the network or in the
>>>>>
>>>>>terminals. The
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>approach you are proposing is not something that TISPAN
>>>>>
>>>>>will accept so
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>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.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>service provider is. Perhaps this comes down to what
>>>>>
>>>>>exactly are the
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>requirements for notifying the caller that a call may now
>>>>>
>>>>>succeed. Is
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>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
>>>>>
>>>>>>So on the assumption that CCBS/CCNR involves only a single
>>>>>
>>>>>UA on the
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>perform? Why can't the UA directly request CCBS/CCNR and
>>>>>
>>>>>communicate
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>caller's UA will receive notification when a the call can
>>>>>
>>>>>be made and
>>>>>
>>>>>
>>>>>
>>>>>

---

From: "Jesske, R" <[email-masked]>
Date: Fri, 30 Sep 2005 08:33:00 +0200

> Von: Paul Kyzivat [mailto:[email-masked]] 
> Gesendet: Donnerstag, 29. September 2005 14:53
> An: Jesske, Roland
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Betreff: Re: AW: [Sipping-tispan] Re: CCBS/CCNR in Version -02f
> 
> 
> 
> 
> Jesske, R wrote:
> > Dear Miguel and Mike,
> I can't quite tell from this description, but it sounds like 
> this covers 
> the case where CCBS is universally forbidden at destination 
> B. Does it 
> also cover the case where user B decides on a case by case 
> basis not to 
> accept a CCBS from a particular caller, at a particular point in time?

Within the PSTN/ISDN it is a permanent status. But I think we can open it for the SIP service. We can use XCAP for provisioning purposes so the user can decide when he want to be reached by CCBS calls and when not.
A call by call soultion is from my point of view not needed and wishful.

Roland
> 
> (This would require user B to be made aware of the CCBS when it is 
> queued, rather than only when user B is alerted for the 
> resulting call. 
> Its not something that would easily be done on a black phone, 
> but might 
> be considered similar to call waiting.)
> 
> 	Paul
>

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 30 Sep 2005 07:46:39 +0100

Sebastien,

Sorry, but I don't understand why this is outside the scope of the mailing
list, which is there to clarify TISPAN requirements. Why should I attend
TISPAN meetings in order to learn the result of TISPAN decisions on this
matter?

John

> Sent: 29 September 2005 15:09
> To: Tom-PT Taylor
> Cc: Elwell, John; Miguel Garcia; Michael Hammer (mhammer); 
> Tessa Silvia; [email-masked]
> I invite John and anybody else interested to participate to 
> TISPAN meetings were those questions are debated.
> 
> 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]
> 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.
> 
> > 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.
> > 
> 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
> >  
> > 
> >

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 30 Sep 2005 07:46:39 +0100

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

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: 29 September 2005 17:44
> > 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.
> 
> > 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:
> 
> 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.
> 
> > Envoyé : jeudi 29 septembre 2005 16:47
> > 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
> >> 
> >>
> continuing 
> >>>>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 
> >>>>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: "Stupka, Jean-Marie" <[email-masked]>
Date: Fri, 30 Sep 2005 09:57:59 +0200

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

John

---

From: "GARCIN Sebastien RD-CORE-ISS" <[email-masked]>
Date: Fri, 30 Sep 2005 10:26:15 +0200

John,

To clarify...What SIP extension do you foresee ?

Thanks
sebastien 

-----Message d'origine-----
De : Elwell, John [mailto:[email-masked]] 
Envoyé : vendredi 30 septembre 2005 08:47
À : GARCIN Sebastien RD-CORE-ISS; Tom-PT Taylor
Cc : Miguel Garcia; Michael Hammer (mhammer); Tessa Silvia; [email-masked]
Objet : RE: [Sipping-tispan] Re: CCBS/CCNR in Version -02f

Sebastien,

Sorry, but I don't understand why this is outside the scope of the mailing list, which is there to clarify TISPAN requirements. Why should I attend TISPAN meetings in order to learn the result of TISPAN decisions on this matter?

John

> Cc: Elwell, John; Miguel Garcia; Michael Hammer (mhammer); Tessa 
> Silvia; [email-masked]
> I invite John and anybody else interested to participate to TISPAN 
> meetings were those questions are debated.
> 
> sebastien
>  
> 
> 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.
> 
> asking about how the O-AS gets the calling party issue the CCBS/CCNR 
> recall or ...?
> > 
> (3rd party call, REFER...) in TISPAN but none of them have SIP 
> extension requirements.
> > 
> 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
> >  
> > 
> >

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 30 Sep 2005 12:55:59 +0100

Sebastien,

I do not necessarily see any SIP extensions, but I need to understand the
SIP mechanism that will be used before I can determine whether any
extensions are required. For example, if only one UA is to be notified, that
UA could subscribe to receive that notification, but if multiple UAs are to
receive that notification it is not so clear how this could work.

John

> Sent: 30 September 2005 09:26
> To: Elwell, John; Tom-PT Taylor
> Cc: Miguel Garcia; Michael Hammer (mhammer); Tessa Silvia; 
> [email-masked]
> Sorry, but I don't understand why this is outside the scope 
> of the mailing list, which is there to clarify TISPAN 
> requirements. Why should I attend TISPAN meetings in order to 
> learn the result of TISPAN decisions on this matter?
> 
> John
>  
> 
> which issued