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

From: "Jesske, R" <[email-masked]>
Date: Thu, 7 Jul 2005 13:02:31 +0200

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: Thu, 7 Jul 2005 19:54:50 +0200

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-authz-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

---

From: Arjun Roychowdhury <[email-masked]>
Date: Thu, 7 Jul 2005 14:21:05 -0400

Hi,
I agree. As I mentioned before, I don't think the focus here is the
ACR. The focus here, is that the call needs to directly reach the
endpoint irrespective of any policy rules.

Therefore, P-ACR is very limiting - instead, it should just be a
general mechanism that is a guideline for the serving AS (or proxy or
whatever) to know that this call needs to be 'short-circuited' .

In addition, the draft talks about this interface being required for
situations when, say, the police calls you. Is just specifying P-ACR
(or similar) enought ? What about the fact that the called UA may
already be in a call ? What if resource prioritization is required ?
Can this not be classified as an 'emergency' call and follow the
directives laid out by the processing requirements of an 'emergency'
call ? IEPREP WG published RFC 3487 for emergency requirements though
I have not yet seen a realization of the requirements - but does it
make sense to refer to their work instead of creating a new 'emergency
like' intended header ?

regds
arjun

-- 
Arjun Roychowdhury

---

From: "David C. Robbins" <[email-masked]>
Date: Fri, 8 Jul 2005 08:30:29 -0400

Comments inline.

>endpoint irrespective of any policy rules.

Rather than thinking of this as "irrespective of any policy rules," 
wouldn't it be more appropriate to think of this in terms of living 
within policy rules regarding which INVITEs are accepted?  For 
example, in one regulatory regime, policy is that *all* anonymous 
communications are rejected, while in another, certain authorized 
callers are accepted -- as a matter of policy -- even though they are 
not identified in the usual manner.  The service is not so much 
bypassing policy rules as it is modifying policy rules by making 
certain exceptions to a general rule.

What about a communication in which the two parties are in different 
regulatory regimes with different policies?  Whose policy applies? 
And what if the policies conflict?

ACR is just one instance of the general case of policies that 
determine whether a call is accepted.  (And here, "accepted" means 
"permitted to alert the user" -- no policy can force the user to 
actually answer the call.)  So wouldn't we recommend that ACR be 
realized in terms of some policy framework?  And to support such a 
policy, w.r.t. the recipient of the call, the caller would have to 
provide sufficient information that the policy can be applied 
appropriately.  Which may get back to the idea about the caller being 
identified by a distinguished URI such as [email-masked].  And for 
the policy to be truly useful, that identity would need to be 
authenticated.

As to the policy framework itself, a mechanism for specifying and 
applying policy is probably outside the scope of SIPPING.

>make sense to refer to their work instead of creating a new 'emergency

Here are more factors that may be taken into account by the policy. 
The more you think about it, the more complex it gets, and the more 
you see that the simple notion of a header that says "bypass ACR" is 
of very limited utility.

-- 
-------------------------------------------------------------------------
Dave Robbins                                         Verizon Laboratories
E-mail: [email-masked]    40 Sylvan Rd., Waltham, MA 02451-1128

---

From: "Henry Sinnreich" <[email-masked]>
Date: Fri, 8 Jul 2005 15:16:35 -0500

This discussion is fascinating, since it is so "1980s ISDN telephony
oriented". As if Presence all its implications would not exist, with regard
to influencing our behavior in communications, when selecting who can see my
presence and from who I will accept a call.

Thanks, Henry

---

From: Michael Slavitch <[email-masked]>
Date: Fri, 8 Jul 2005 16:33:47 -0400

That may be fine in a scalar, individual case with a live user but it 
certainly doesn't apply for organizations or for cases requiring automation.

Regards

Michael

-- 
Michael Slavitch
Ottawa, Ontario Canada