Subject: AW: [Sipping] Re: New Draft on TISPAN analysis for SIPsolutionsco ncerning the simulation Services

From: "Jesske, R" <[email-masked]>
Date: Fri, 8 Jul 2005 11:19:42 +0200

Jeroen,
With regard to the cause values this will be included by an AS by signalling procedures case by case, within Methods it is used.
So does this mean that the AS has to include a URL pointing to an other data base including this information instead of doing it directly and straight?
And if used we have two mechanisms doing the same one for Methods and one for Responses.

How will this be interworkable?

Roland

> -----Ursprüngliche Nachricht-----
> Von: Jeroen van Bemmel [mailto:[email-masked]] 
> Gesendet: Freitag, 8. Juli 2005 08:27
> An: Jeroen van Bemmel; Jesske, Roland; [email-masked]; 
> [email-masked]
> Cc: [email-masked]
> Betreff: Re: [Sipping] Re: New Draft on TISPAN analysis for 
> SIPsolutionsconcerning the simulation Services
> 
> 
> 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
> 
> 
> >> 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
>
> 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
>
>
> _______________________________________________
> 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:22:12 +0200

Roland,

I'm sorry, perhaps my description was a bit too brief. The idea was that the 
gateway would not dereference the URL, but interpret it as a unique 
identifier for a particular feature. Much like URNs and the likes are used 
for XML namespaces.

A UAC receiving this header could in fact dereference the URL, and get an 
explanation on why the call failed. This gives more room than the reason 
text in the response, allows things like internationalization, and the 
syntax (URL) is more suited for machine interpretation than the reason field 
which is free text really intended for display to users only. UAs that are 
not able to dereference the Error-Info could still display the reason text 
instead.

The original Reason header RFC3326 shows ISUP interworking scenarios where 
the gateway inserts a Reason header, with a Q.850 code. To me that is 
acceptable since a PSTN gateway by nature has knowledge of the PSTN network. 
However, when you let an AS insert this header, you require that the AS 
knows about PSTN failure codes, which makes it PSTN specific in a sense.

Jeroen

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

Jeroen,
With regard to the cause values this will be included by an AS by signalling 
procedures case by case, within Methods it is used.
So does this mean that the AS has to include a URL pointing to an other data 
base including this information instead of doing it directly and straight?
And if used we have two mechanisms doing the same one for Methods and one 
for Responses.

Roland

ngn-reason-00.txt