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

From: "Warren, Dan, VF UK - Technology \(TS\)" <[email-masked]>
Date: Fri, 15 Jul 2005 15:35:17 +0100

Paul, all

That sounds about right to me as analysis of this goes, and I think it has to be ok with TISPAN because it is the situation that would occur today, if instead of a 'TISPAN conforming sip endpoint on a TISPAN conforming sip network', the call is originated from a PSTN using ISUP.  

Fundamentally, I think TISPAN's concern is with regard to loss of existing functionality or degradation of end user experience because of what regulators would have to say about this.  The fact that no indication is returned from the vanilla-SIP UA isn't a degradation since there would be no indication today, right?

Dan

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Paul Kyzivat
> Sent: 15 July 2005 14:55
> To: Jesske, R
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: AW: AW: AW: AW: [Sipping] Re: New Draft on 
> TISPAN analysis
> forSI P so luti onsc oncerning the simulation Services
> 
> 
> 
> 
> Jesske, R wrote:
> 
> >>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.
> 
> 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
> 
> >>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
> 

_______________________________________________
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 11:21:47 -0400

I hope so. It is very difficult for me to tell what the expectations are 
here. It seems that we don't speak the same language.

	Paul