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

["Stupka, Jean-Marie" <[e-mail]>]

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:[e-mail]] 
Sent: Friday, September 30, 2005 4:48 PM
To: Elwell, John
Cc: Stupka, Jean-Marie; GARCIN Sebastien RD-CORE-ISS; [e-mail]; 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

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:[e-mail]] 
>>Sent: 30 September 2005 08:58
>>To: Elwell, John; Paul Kyzivat; GARCIN Sebastien RD-CORE-ISS
>>Cc: [e-mail]; 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: [e-mail] 
>>[mailto:[e-mail]] On Behalf Of Elwell, John
>>Sent: Friday, September 30, 2005 8:47 AM
>>To: Paul Kyzivat; GARCIN Sebastien RD-CORE-ISS
>>Cc: [e-mail]; 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:[e-mail]] 
>>>Sent: 29 September 2005 17:44
>>>To: GARCIN Sebastien RD-CORE-ISS
>>>Cc: [e-mail]; 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:[e-mail]] 
>>>>Envoyé : jeudi 29 septembre 2005 16:47
>>>>À : GARCIN Sebastien RD-CORE-ISS
>>>>Cc : Tom-PT Taylor; Tessa Silvia; [e-mail]
>>>>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:[e-mail]] Envoyé : jeudi 29 
>>>>>septembre 2005 15:46 À : GARCIN Sebastien RD-CORE-ISS Cc 
>>
>>: Elwell, 
>>
>>>>>John; Miguel Garcia; Michael Hammer (mhammer); Tessa Silvia; 
>>>>>[e-mail] 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:[e-mail]] Envoyé 
>>>
>>>: jeudi 29 
>>>
>>>>>>septembre 2005 14:22 À : 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,
>>>>>>
>>>>>>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
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>_______________________________________________
>>>>>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
>>>
>>
>>_______________________________________________
>>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