Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04

["Elwell, John" <[e-mail]>]

 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of [e-mail]
> Sent: 10 November 2009 08:39
> To: [e-mail]; [e-mail]
> Cc: [e-mail]; [e-mail]; 
> [e-mail]
> Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04
> 
> 
> 
> Adam wrote:
> > My point is that increasing the amount of ISUP information that we 
> > include in SIP message headers is going down a slippery slope, the 
> > ultimate conclusion of which is including SIP header fields 
> for every 
> > ISUP parameter.
> This is a valid point, but the proposed alternative has 
> severe problems.
> If the reason header is the only piece of ISUP information we need,
> carrying the whole ISUP message is not really elegant. SIP application
> servers (AS) would have to implement ISUP parsing just to 
> check a simple
> value. The content of a Reason header could be checked and used by any
> plain AS. Do we really want to perpetuate ISUP code in SIP networks?
> 
> > We have a means for sending ISUP fields transparently through a SIP 
> > network (RFC 3398). I think it's folly to revisit that set of
> decisions 
> > simply because someone wants a less-general point solution.
> We were talking about scenarios where the PSTN gateway does not know
> whether a call will be terminated by a different PSTN gateway, or by a
> SIP user agent. So the originating gateway would have to encapsulate
> ISUP in SIP, and SIP user agents would receive it. This would violate
> regulatory requirements in various countries. As S/MIME is 
> not feasible,
> we would have to introduce yet another B2BUA just to filter ISUP from
> SIP messages for end user devices.
[JRE] SIP UAs would receive the Reason header field too, unless the last proxy/B2BUA strips it out. The only difference is that a body part can only be stripped by a B2BUA, not by a proxy. Do you need a solution that will work with proxies?

John