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:25:35 +0200

Comments inline

Roland

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] 
> [mailto:[email-masked]] Im Auftrag von Jeroen van Bemmel
> Gesendet: Mittwoch, 6. Juli 2005 17:54
> An: Drage, Keith (Keith); Miguel Garcia
> Cc: [email-masked]
> Betreff: Re: [Sipping] Re: New Draft on TISPAN analysis for 
> SIP solutionsconcerning the simulation Services
> 
> 
> 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.

Within the PSTN/ISDN network the information is needed with regard to the rejection cause. This is Cause value "24".
It could be that the PSTN/ISDN includes a announcement in the bearer path.

So this is the main behind the requirement. We are proposing to use the Reason header in responses where I wrote a Draft:
http://www.ietf.org/internet-drafts/draft-jesske-sipping-etsi-ngn-reason-00.txt

That allows Reason headers in responses, because within RFC3326 this is not really allowed only if it is explicitly documented within a RFC.

At the moment we are using the 603 decline with a Warning header including some text.
But with regard to the mapping we will such a response not to cause value 24 because the 603 is more general than to anonymous communications.

> 
>  [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)

I think I already comented a proposal that we will discuss surly next week in the TISPAN meeting.

> 
> 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
> >
> >
> >
> >
> >> -----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 21:30:43 +0200

> So this is the main behind the requirement. We are proposing to use the 
> Reason header in responses where I wrote a Draft:

What I don't like about this proposal, is that it puts ISDN specific 
requirements on a potentially generic service (assuming for the moment that 
ACR would be a desirable one).  Q.850 codes like #24 are specific to ISDN, 
so I would expect the gateway to make such a mapping based on a more generic 
failure reason. I imagine that such a failure reason would refer to the 
feature that caused the failure, by name or other identifying mechanism, 
rather than some obscure code

I don't have a concrete example right now but suppose there were a second 
type of network that wants to interoperate with these SIP based services. In 
this network, failure due to ACR is #34. I will admit this is somewhat 
hypothetical, but I hope you get the drift

I do believe there is a general need for more detailed reason codes, the 
response code space is small and it would not be desirable (nor feasible) to 
reserve a new code for each new feature that may cause errors. So I would 
expect something like the Reason header proposed could be put to use, albeit 
in a more generic access-independent form

Regards,

jeroen

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Fri, 8 Jul 2005 08:27:19 +0200

Perhaps you could use the Error-Info header for this. It is originally 
intended to provide information to the end user, but if you would adopt a 
URL convention (say http://etsi.org/simulationservices/acr.html) it could 
serve both purposes

Jeroen

----- Original Message ----- 
From: "Jeroen van Bemmel" <[email-masked]>
To: "Jesske, R" <[email-masked]>; <[email-masked]>; 
<[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, July 07, 2005 9:30 PM
Subject: Re: [Sipping] Re: New Draft on TISPAN analysis for 
SIPsolutionsconcerning the simulation Services

> requirements on a potentially generic service (assuming for the moment 
> that ACR would be a desirable one).  Q.850 codes like #24 are specific to 
> ISDN, so I would expect the gateway to make such a mapping based on a more 
> generic failure reason. I imagine that such a failure reason would refer 
> to the feature that caused the failure, by name or other identifying 
> mechanism, rather than some obscure code
>
> type of network that wants to interoperate with these SIP based services. 
> In this network, failure due to ACR is #34. I will admit this is somewhat 
> response code space is small and it would not be desirable (nor feasible) 
> to reserve a new code for each new feature that may cause errors. So I 
> would expect something like the Reason header proposed could be put to 
> use, albeit in a more generic access-independent form
>
> Regards,
>
> jeroen
>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 08 Jul 2005 15:05:54 -0400

> That allows Reason headers in responses, because within RFC3326 this is not really allowed only if it is explicitly documented within a RFC.

I guess this #24 is a Q.850 code???

This isn't the first time use of these has been proposed. And if you are 
just using sip to tunnel a request between two networks where such codes 
are understood that might be fine.

But here you are trying to define interoperation with sip nodes, and to 
define how those sip nodes should work. But the meaning and 
applicability of Q.850 codes is not defined for SIP. So how would a sip 
endpoint know which Q.850 code to use for any given situation?

I think you at least need to have some definition of when particular 
codes are applicable.

	Paul