Subject: RE: [Sipping] Re: New Draft on TISPAN analysis for SIP solutionsc oncerning the simulation Services

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Wed, 6 Jul 2005 13:25:07 +0100

In general, we believe we have reused existing headers and so on to meeting requirements either appearing in the requirements draft, or not appearing at all, because we believe that the solution is met by existing SIP.

Thus for example there are no requirements relating to the bulk of passing forwarding information around, because that is substantially met by an already approved extension defining the History-Info solution; as a result of no requirements, there is no need to invent a solution.

While I agree there is little discussion of alternatives in the solutions draft, much of that is due to existing capabilities quite obviously not meeting the requirements, and therefore there seemed little point in creating documentation to reflect that.

However if you believe there are existing SIP solutions to the requirements in the requirements draft, then we will be only too happy to take them into account. You may have some knowledge of the way things are already applied in SIP that meet the requirements.

regards

Keith

Keith Drage
Lucent Technologies
[email-masked]
tel: +44 1793 776249

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Jeroen van Bemmel
> Sent: 05 July 2005 19:00
> To: Miguel Garcia
> Cc: [email-masked]
> Subject: Re: [Sipping] Re: New Draft on TISPAN analysis for SIP
> solutionsconcerning the simulation Services
> 
> 
> Roland,
> 
> My general comment would be: if it can be implemented using existing 
> mechanisms / headers / body formats / protocols, that would always be 
> preferrable. If not, then there should be a detailed and convincing 
> motivation on why not, listing all alternatives considered 
> and stating what 
> makes them inappropriate
> 
> I feel that the current drafts mentioned below too easily propose new 
> headers, without sufficient reflection on existing work
> 
> I think this principle would hold in general, for anyone 
> authoring a draft
> 
> Regards,
> 
> Jeroen
> 
> 
> > Jesske, R wrote:
> >
> > > Dear all,
> > > A new draft regarding the analysis of the requirements on TISPAN
> > > simulation services as described in
> > > draft-jesske-sipping-tispan-requirements-01  is now available.
> > >
> > > It can be fond under:
> > > 
> http://www.ietf.org/internet-drafts/draft-jesske-sipping-tispa
> n-analysis-00.txt
> > >
> > >
> > > We would like to start the discussion on solutions for 
> the requirements
> > > we stated in draft-jesske-sipping-tispan-requirements-01
> > > 
> (http://www.ietf.org/internet-drafts/draft-jesske-sipping-tisp
> an-requirements-01.txt).
> > >
> > > This draft should be seen as a discussion basis and 
> brainstorming of
> > > some people thinking about SIP solutions.
> > >
> > > Every comment and discussion is welcome and helps to find 
> a solution.
> > >
> > > Thank you.
> > >
> > > Best Regards
> > >
> > > Roland
> > >
> > >
> > >
> > >
> > > Deutsche Telekom AG
> > > T-Com Zentrale
> > > Roland Jesske, TE332-2
> > > Section TE33; Signalling, Gateways and Switching Systems
> > > Am Kavalleriesand 3, 64295 Darmstadt, Germany
> > > Phone:  +49 6151 83-5940
> > > Fax:      +49 6151 83-4577
> > > email:   [email-masked]
> > >
> >
> > --
> > Miguel A. Garcia           tel:+358-50-4804586
> > sip:[email-masked]
> > Nokia Research Center      Helsinki, Finland
> >
> >
> > _______________________________________________
> > 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
> >
> 
> 
> -- 
> Arjun Roychowdhury
> 
> _______________________________________________
> 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
> 

_______________________________________________
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: "Jeroen van Bemmel" <[email-masked]>
Date: Wed, 6 Jul 2005 17:54:14 +0200

Keith,

It was not my intention to question the effort and time spent in preparation 
of the drafts. However, if alternatives have been considered and rejected 
already without documenting this, it will be difficult for people not 
involved in that process (like myself) to comment on and contribute to the 
discussion. So the point of creating this documentation would be to enable 
meaningful public discussion, which I assumed was the intention given that 
the drafts are distributed on the SIPPING mailinglist.

To me the requirements draft is quite dense, in the sense that it presents a 
large set of features with (as far as I can tell) significant potential 
impact. In 13 pages the requirements for 14 simulation services are 
presented, a somewhat overwhelming amount. For the definition of the 
services themselves reference is made to ETSI documents [ which are 
available free of charge but require registration with ETSI to access, which 
I personally find annoying ].

If I take for example the "Anonymous Communication Rejection" service:

 [REQ-ACR-1]
   The ACR simulation service requires the caller to be informed that
   the communication was rejected due to this service. This is needed to
   inform the upstream elements (UAC, e.g., a PSTN/ISDN gateway) about
   the reason for the rejection.

Thinking in terms of a SIP solution my first thought would be: put it in the 
reason text of a 603 Decline, e.g. "Call was rejected because callee does 
not accept anonymous calls". This text could be presented to the caller to 
fulfil the requirement. However, the second sentence talks about "upstream 
elements" that would need to be informed. So in fact this is a second 
requirement, apparently the rejection reason must be interpretable both by 
humans (caller) and machines. Now why is that? The calling user I can 
understand, he could try again without anonimity. But what would the gateway 
do, other than signalling failure to a calling user on the ISDN? Would it 
have to map the failure code onto something specific in the PSTN/ISDN 
domain? Apparently so (reading from the analysis draft) but it is not listed 
as a requirement.

 [REQ-ACR-2]
   It must be possible that authorized callers are not subject to the
   ACR service, thus, allowing the callee to receive anonymous requests
   from authorized callers. This effectively requires a mechanism to
   override the ACR service depending on the identity and authorization
   of the caller.

  This is needed, e.g., for when a police officer or any other
  authority is anonymously calling to a user having the ACR simulation
  service enabled.

This brings a lot of questions to mind. First of all, there is a paradox in 
"anonymous requests from authorized callers". How are anonymous requests 
recognised, what makes them anonymous? The concept of an "authority" is not 
really defined in SIP, but I could see trait-based authorization being put 
to use here. I also imagine that the use case for overriding 
features/services that would otherwise block communication is more general 
than just ACR. For this and several other reasons I do not like the 'P-ACR' 
header suggested in the analysis draft (what would the trusted entity do, 
append a P-something header for each service that the callee might have 
which would otherwise block communication?)

And these are just some thoughts on 1 of the proposed services. My point 
here is: I think there is enough room for discussion on each service to fill 
several drafts. There may have been ETSI internal discussions on this (and 
I'm sure there have been), but it is not apparent from the drafts provided. 
This leaves people on this mailinglist with few alternatives besides giving 
general comments (or simply ignoring it)

Regards,

jeroen

----- Original Message ----- 
From: "Drage, Keith (Keith)" <[email-masked]>
To: "Jeroen van Bemmel" <[email-masked]>; "Miguel Garcia" 
<[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, July 06, 2005 2:25 PM
Subject: RE: [Sipping] Re: New Draft on TISPAN analysis for SIP 
solutionsconcerning the simulation Services

> In general, we believe we have reused existing headers and so on to 
> meeting requirements either appearing in the requirements draft, or not 
> appearing at all, because we believe that the solution is met by existing 
> SIP.
>
> Thus for example there are no requirements relating to the bulk of passing 
> forwarding information around, because that is substantially met by an 
> already approved extension defining the History-Info solution; as a result 
> of no requirements, there is no need to invent a solution.
>
> While I agree there is little discussion of alternatives in the solutions 
> draft, much of that is due to existing capabilities quite obviously not 
> meeting the requirements, and therefore there seemed little point in 
> creating documentation to reflect that.
>
> However if you believe there are existing SIP solutions to the 
> requirements in the requirements draft, then we will be only too happy to 
> take them into account. You may have some knowledge of the way things are 
> already applied in SIP that meet the requirements.
>
> regards
>
> Keith
>
> Keith Drage
> Lucent Technologies
> [email-masked]
> tel: +44 1793 776249
>
>
>
>