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

From: "Jesske, R" <[email-masked]>
Date: Fri, 8 Jul 2005 12:56:29 +0200

Jeroen,
ACR is a subset of a service called ICB (Incomming communication barring). Blacklist Service that will be administered in a AS on behalf of the user.
This restriction of incoming communications is based on the P-Asserted-ID.
For ACR we are using the privacy header field to restrict communications.
So for the overwriting of ACR the idea appeared to use a priv value like "network" (as it is within the PSTN/ISDN) to say that the privacy restriction was caused by network purposes (including such police calls). But we saw that this could contradict with the definition of the privacy header so we came up with this bypass header.

We have also a Service called Outgoing Communication barring that restricts communication to special numbers/URI's for the caller. This is was defined due to the fact to be sure that children do not call high priced numbers.

So you see we put together several barring services.

Best Regards

> -----Ursprüngliche Nachricht-----
> Von: Jeroen van Bemmel [mailto:[email-masked]] 
> Gesendet: Donnerstag, 7. Juli 2005 19:55
> An: Jesske, Roland; [email-masked]; [email-masked]
> Cc: [email-masked]
> Betreff: Re: [Sipping] Re: New Draft on TISPAN analysis for 
> SIP solutionsc oncerning the simulation Services
> 
> 
> Roland,
> 
> I was thinking about the trait-based authorization framework 
> (see email on 
> this list 20-6-2005 : 
> http://www.ietf.org/internet-drafts/draft-ietf-sipping-trait-a
> uthz-01.txt) 
> to convey 'authority' along with a request. But in an 
> operator controlled 
> network you may be better of with a trusted entity that 
> appends some header 
> instead, e.g. P-Authority : police
> 
> The ACR service implementation would then have to behave accordingly
> 
> My point was that rather than defining something specific for the ACR 
> service, why not use something a bit more general. I could 
> imagine for 
> example a 'caller restriction' feature that would allow 
> subscribers to 
> specify a white list of identities from whom they wish to 
> receive calls, all 
> others are blocked. Also such a service would need an 
> override mechanism
> 
> Regards,
> 
> Jeroen
> 
> ----- Original Message ----- 
> From: "Jesske, R" <[email-masked]>
> To: <[email-masked]>; <[email-masked]>; 
> <[email-masked]>
> Cc: <[email-masked]>
> Sent: Thursday, July 07, 2005 1:02 PM
> Subject: AW: [Sipping] Re: New Draft on TISPAN analysis for 
> SIP solutionsc 
> oncerning the simulation Services
> 
> 
> Jeroen,
> I'm happy about SIP extensions that can be used for our 
> services so if you 
> have something in mind please guide us.
> 
> Thanks
> 
> Roland
> 
> > -----Ursprüngliche Nachricht-----
> > Von: [email-masked]
> > [mailto:[email-masked]] Im Auftrag von Drage, 
> Keith (Keith)
> > Gesendet: Mittwoch, 6. Juli 2005 14:25
> > An: Jeroen van Bemmel; Miguel Garcia
> > Cc: [email-masked]
> > Betreff: RE: [Sipping] Re: New Draft on TISPAN analysis for
> > SIP solutionsc oncerning 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
> >
> >
> >
> >
> > > -----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
> > 
> 

_______________________________________________
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: Fri, 8 Jul 2005 21:27:31 +0200

Roland,

So wouldn't the same requirement (authority bypass) apply to ICB as well 
then? There appear to be no requirements for ICB in the draft

Jeroen

----- Original Message ----- 
From: "Jesske, R" <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, July 08, 2005 12:56 PM
Subject: AW: [Sipping] Re: New Draft on TISPAN analysis for SIP solutionsc 

Jeroen,
ACR is a subset of a service called ICB (Incomming communication barring). 
Blacklist Service that will be administered in a AS on behalf of the user.
This restriction of incoming communications is based on the P-Asserted-ID.
For ACR we are using the privacy header field to restrict communications.
So for the overwriting of ACR the idea appeared to use a priv value like 
"network" (as it is within the PSTN/ISDN) to say that the privacy 
restriction was caused by network purposes (including such police calls). 
But we saw that this could contradict with the definition of the privacy 
header so we came up with this bypass header.

We have also a Service called Outgoing Communication barring that restricts 
communication to special numbers/URI's for the caller. This is was defined 
due to the fact to be sure that children do not call high priced numbers.

Best Regards