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

From: "Jesske, R" <[email-masked]>
Date: Mon, 11 Jul 2005 18:40:17 +0200

Yes #24 is a Q.850 cause.
With regard to your Question:
So how would a sip 
endpoint know which Q.850 code to use for any given situation?

My Question back is why the Reason header was defined at least?

>From my understanding this definition was done to give the UA the vchance to show up some more information or a AS can react on such a information.

At least RFC3326 says:
   Clients and servers are free to ignore this header field.  It has no
   impact on protocol processing.

So there is no impact on such a Header within the SIP network.

For us it is importand to have addtional information for the AS. Or a AS providing simulation services give information to a user/entity sitting in the PSTN/ISDN.

Also such information could be used to pass it to an other AS e.G. providing Anouncements to the end client.

Roland

-----Originalnachricht-----
Von: Paul Kyzivat
An: Jesske, Roland
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Gesendet: 08.07.05 21:05
Betreff: Re: AW: [Sipping] Re: New Draft on TISPAN analysis for SIP solutionsc oncerning the simulation Services

Jesske, R wrote:

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

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

_______________________________________________
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: Paul Kyzivat <[email-masked]>
Date: Mon, 11 Jul 2005 14:50:44 -0400

> So there is no impact on such a Header within the SIP network.

I understand there is no impact in sense that anyone is free to ignore 
the header. So maybe I can insert a reason header with some random Q.850 
code and those servers that receive and ignore it will be unaffected.

But apparently you want these codes to be used so that nodes that 
receive it can interpret the code as something meaningful and alter 
their behavior as a result. This of course only works if:
- the reason code is inserted
- the value chosen is appropriate to the circumstance

So consider the case where you have a node conforming to this TISPAN use 
of Reason that is trying to call an address served by some native SIP 
server that never heard of Q.850. That server may decide to reject your 
anonymous call, sending a 603 response. But what would motivate it to 
include a Reason header with a Q.850 #24 reason code? What is the caller 
to do if it doesn't get this?

> For us it is importand to have addtional information for the AS. Or a AS providing simulation services give information to a user/entity sitting in the PSTN/ISDN.

So you are content that this *optional* information can be provided by 
the devices supporting the simulation services, and not by others?

	Paul