Subject: AW: AW: AW: AW: [Sipping] Re: New Draft on TISPAN analysis for SI P so luti onsc oncerning the simulation Services

From: "Jesske, R" <[email-masked]>
Date: Fri, 15 Jul 2005 09:14:09 +0200

-----Originalnachricht-----
Von: Paul Kyzivat
An: Jesske, Roland
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Gesendet: 13.07.05 19:01
Betreff: Re: AW: AW: AW: [Sipping] Re: New Draft on TISPAN analysis for SIP so	luti onsc oncerning the simulation Services

>Roland,

>We still don't seem to be communicating effectively.

>My question is: do you expect (or desire, or require) native sip 
>components (not conforming to TISPAN specifications) to insert these 
>reason codes?

Yes 
it shall be included by UA (a TISPAN AS could be a UA also a ISUP Gateway acts as UA) 
and 
it shall be included or forwarded by Proxies.

TISPAN profiles then the use of the RFC for their purposes as it was done with other RFCs.

I know that this generic aproach allows the inclusion by each endclient. Of course then the PSTN/ISDN Gateway or Gateway to a private network (e.G ETSI TISPAN NGN) has to take care it. If the Reason shall be mapped or not. 
 
I think it is better to have a generic aproach with UA and Proxy behavior.

>If so, I think you must eventually produce a standards track document 
>that specifies the desired behavior. AFAIK there currently exists no 
>document that specifies when and if a sip node should insert Q.850 
>reason codes into its sip messages.

The Reason RFC 3326  is very vague with regard of entities including the Reason header. From my interpretation of RFC3326 a Reason header can be included by UA's and Proxies.  

So to be inline with RFC 3326 I have nothing against to keep this as it was defined.

>	Paul

Jesske, R wrote:

_______________________________________________
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: Fri, 15 Jul 2005 09:54:53 -0400

> I think it is better to have a generic aproach with UA and Proxy behavior.

I still don't see how this can work except in a closed network where all 
the endpoints conform to your specific requirements.

Specifically, suppose a TISPAN conforming sip endpoint on a TISPAN 
conforming sip network calls a sip endpoint that is outside of the 
TISPAN network, and that conforms only to basic 3261. (This would 
perhaps be via some sip peering agreement, or simply by having the 
TISPAN network resolve a foreign sip address according to 3263.

The request from the TISPAN endpoint indicates that it wants to block 
transmission of its address, and so the request, when it reaches the 
target, specifies an anonymous address. The target sip endpoint does not 
accept calls from anonymous callers. So perhaps it responds with a 403 
Forbidden. It does not include a Reason header, especially not one with 
a Q.850 error code 24, because it is not a party to TISPAN agreements 
that it should do so.

As a result, the TISPAN caller has its call rejected, but does not get 
the indication that this was due to anonymous call rejection, even 
though that was in fact the reason.

This same situation holds if the "TISPAN caller" is in fact a PSTN 
gateway, so that PSTN callers may also not get the indication of 
anonymous call rejection.

So either you must be content that indication of anonymous call 
rejection only works when SIP participants conform to the TISPAN 
profile, or else you are going to have to get all the sip endpoints in 
the world to conform to some TISPAN requirements.

I just want to understand if that is the situation as you understand it.

	Paul