Subject: AW: [Sipping] Re: I-D ACTION:draft-jesske-sipping-tispan-requirem ents-01.txt

From: "Jesske, R" <[email-masked]>
Date: Fri, 17 Jun 2005 06:39:21 +0200

Tank you for your comments

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] 
> [mailto:[email-masked]] Im Auftrag von Paul Kyzivat
> Gesendet: Donnerstag, 16. Juni 2005 00:40
> An: 'Sipping (E-mail)'
> Betreff: [Sipping] Re: I-D 
> ACTION:draft-jesske-sipping-tispan-requirements-01.txt
> 
> 
> Thank you - this version is much more to the point than the prior one!
> 
> I still find some context lacking for interpretting what is being 
> requested. Primarily I don't understand who these requirements are 
> intended to apply to. It seems that you are seeking 
> mechanisms that can 
> be used to carry out the simulation requirments. But these mechanisms 
> will have to be deployed in some operating environment to be 
> effective. 
The operating environment is the TISPAN IMS Architecture that is based on the Architecture of 3GPP. The Services are processed within an Application Server.

> And what your assumptions are about that will influence the kinds of 
> mechanisms that are suitable.

We tried to express what is needed from a UA's and AS. E.g CCBS (Communication Completion on Busy Subscriber) needs additional mechanisms from UA's and AS. 

Would it be useful to have such kind of Architecture within the requirements draft?
> 
> Pretty much all of these requirements involve the cooperation of 
> multiple parties - either a caller and a callee, caller and 
> some network 
> component, or callee and some network component. Are you satisfied to 
> have these features work only when all parties in the call cooperate?
At least we want to have such features to interoperate proper with the PSTN/ISDN where it is needed. 

> 
> For instance, consider [REQ-CDIV-1] and [REQ-CDIV-3]. If the 
> callee does 
> not cooperate and diverts the call without the proper 
> indications then 
> it will be impossible to meet the requirements. 

We know of course that there are several possibilities to divert a communication like 302 or divert it directly by a UA. Our Services will run on an Application Server that reacts on behalf of the UA.
For CDIV we are using the History Draft. Of course if a UA diverts directly without including a History the Caller will never informed about the diversion. But if the network does it then the caller will be informed. Within the PSTN/ISDN we have the same possibilities.

The simulation services we are defining in TISPAN are network based services. For that we are looking for new or existing SIP mechanisms to fulfil our requirements.
>Are you seeking 
> something that is intended to apply to all sip implementation 
> in order 
> to make your service work? Or are you willing to have it only 
> work with 
> cooperative callees. (Note that it is generally impossible to 
> guarantee 
> that all callees will cooperate unless you have physical 
> control of all 
> components including the endpoints.

As you said we never will have the full control of callees and callers. Neither in the PSTN/ISDN nor in the NGN. But we (Operators) want to have the ability to provide services to our customers as we do it within the PSTN/ISDN network. 

> 
> So it would be helpful to have some indication of the kinds of 
> restrictions you are prepared to impose on the system for 
> these features 
> to be fully operable. And if you would like to allow 
> different classes 
> of restrictions, and corresponding differences in features, then that 
> would also be useful to know.

That depend on the operator what kind of restrictions he want to set on the customers. E.g allowing 302 for redirection or creating a Reason Header including a Cause Value. 
More important is that the operator has the ability to set restrictions or not.

In some cases we need restrictions or correct handling like regulatory services like ACR (Anonymous Communication Rejection) or MCID (Malicious Communication Identification). In other cases we have the choice (Operator depended) to allow different possibilities like CDIV.

I hope this helps a little.

We hope that we can come up within the next week with a analysis draft of the services and the thoughts we have about possible mechanisme to fulfill the requirements. We try to describe and include all coments we get. 
 
Thank you 
Roland

> 
> 	Thanks,
> 	Paul
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments of core SIP
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 17 Jun 2005 11:28:57 -0400

More inline.

	Paul

> Would it be useful to have such kind of Architecture within the requirements draft?

I think it would be helpful to have something to set the context within 
which the requirements and their solutions are expected to apply. The 
value will be best if this can be expressed concisely. It doesn't have 
to be exactly the environment you intend - it ideally will be an 
abstraction of that.

> At least we want to have such features to interoperate proper with the PSTN/ISDN where it is needed. 

Well, I suppose you might assume that the gateways to the PSTN/ISDN will 
be cooperative. But that often will only be one of the parties in the 
call. E.g. suppose the gateway is the callee and the caller is an 
uncooperative sip UA. You might not be able to accurately simulate all 
the features that the PSTN end wants. Is that OK? Or would you require 
that uncooperative callers not be allowed to use the gateway?

> For CDIV we are using the History Draft. Of course if a UA diverts directly without including a History the Caller will never informed about the diversion. But if the network does it then the calle…

So you are willing to accept that diversion information may not always 
be provided if the called party is not cooperative?

> More important is that the operator has the ability to set restrictions or not.

Well, the operator has the ability to *try* to set restrictions.
Unless all the equipment is managed by the operator and is tamper proof 
there is the possibility that user equipment may violate the restrictions.

The only other sure way is to implement all the required aspects of the 
services in the network, in components that cannot be bypassed.