Subject: RE: [Sipping-tispan] Requirements version -02d

From: "GARCIN Sebastien RD-CORE-ISS" <[email-masked]>
Date: Wed, 7 Sep 2005 09:18:32 +0200

Hi,

Yes please delete it, this adds unecessary complexity to the service. 

Also I don't fully agree with CCBS-4 which-4 talks about sending a notification when the caller is busy at the time the calle. If we are talking about sending this notification to the call,  this is again something new and not required here. We don't need to explain what happens when this case occurs we are providing a service descripion only protocol requirements. I hence propose to remove the last sentence as follows: 
 
 REQ-CCBS/CCNR-4:  The entity providing the CCBS/CCNR service needs to
                     know the status of the caller at the time of
                     allocating a initiating the CCBS/CCNR request. 
     
CCBS-6 does not seem to require anything from a protocol perspective, again it seems that we are trying to describe the service. If we feel that something is missing from SIP we need to be more explicit or else delete the requirement.

Regards
sebastien

-----Message d'origine-----
De : Miguel Garcia [mailto:[email-masked]] 
Envoyé : mercredi 7 septembre 2005 08:29
À : GARCIN Sebastien RD-CORE-ISS
Cc : [email-masked]; [email-masked]
Objet : Re: [Sipping-tispan] Requirements version -02d

Sebastien,

Certainly it is not the intention of this work to fit new requirements, but just to reword the TISPAN requirements. As such, if you think that
CCBS-7 is not a requirement for TISPAN we can safely delete it.

/Miguel

GARCIN Sebastien RD-CORE-ISS wrote:

> Miguel, all,
> 
> Looking at this new version of the tispan-requirements draft, I have the clear impression that the activity is getting out of the scope that it was granted both by the TISPAN and IETF SIPPING management. 
> 
> The new version contains a number of new requirements (for example CCBS-7) which have never been discussed in TISPAN. 
> 
> This mailing list activity does not have the mandate the add new requirements, only to clarify the vocabulary and adapt it so that a non-telecom reader is able to understand them.   
> 
> As a TISPAN member, I see those changes as "IETF proposed" changes that will need to be further reviewed and agreed upon in TISPAN by WG3 (at our next week meeting). As a result of this review TISPAN could come up with a new "agreed" draft version to be submitted to IETF.
> 
> Best regards,
> sebastien
> 
> -----Message d'origine-----
> De : [email-masked] 
> [mailto:[email-masked]] De la part de Miguel Garcia 
> Envoyé : mardi 6 septembre 2005 15:07 À : [email-masked]'
> Objet : [Sipping-tispan] Requirements version -02d
> 
> Hi:
> 
> I have placed a working copy of the requirements, just to summarize where we are today.
> 
> http://people.nokia.net/~miguel/drafts/pre/draft-jesske-sipping-tispan
> -requirements-02d.html 
> http://people.nokia.net/~miguel/drafts/pre/draft-jesske-sipping-tispan
> -requirements-02d.txt
> 
> Besides the discussion around ACR and CCBS/CCNR, I have added the MCID requirements. Please indicate if you still have concerns, and perhaps propose text.
> 
> A diff version containing revision marks is also available:
> 
> http://people.nokia.net/~miguel/drafts/pre/draft-jesske-sipping-tispan
> -requirements-02c-to-d.html
> 
> /Miguel

-- 
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: Miguel Garcia <[email-masked]>
Date: Wed, 07 Sep 2005 10:39:30 +0300

Sebastien, some inline comments.

>                      allocating a initiating the CCBS/CCNR request. 

So it seems that in the PSTN in the case the network cancels the 
CCBS/CCNR service request, the caller is never informed. I found this 
awful from the user's experience point of view. So if we want to limit 
to mimic the PSTN service and not adding a single bit of improvement, 
than we can safely delete the sentence as you mention.

In addition to that, if you think of the solution, and if you think that 
this will most likely be implemented as an event package, when the 
network decides to terminate the subscription, it sends a NOTIFY request 
to the subscriber, including a Subscription-State header with the value 
set set to "terminated". The notifier can also include a "reason" 
parameter including the reason for termination.

So honestly speaking, if you think of the solution, the presence or 
absence of this requirement has no changes in the protocol.

> CCBS-6 does not seem to require anything from a protocol perspective, again it seems that we are trying to describe the service. If we feel that something is missing from SIP we need to be more exp…

Probably, I don't know if it requires protocol development or not, but 
if you take a look at the discussion on the list, probably you will 
agree with me that CCBS is not an easy-to-understand service, so we have 
been requested to add a few clarifications of how the service works.

/Miguel