[SIPForum-techwg] Question re Application Server

[Chris Sibley]

Hey Paul,

Comments in-line..

Thanks,

--Chris

> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat at cisco.com]
> Sent: Monday, September 11, 2006 10:11 AM
> To: Chris Sibley
> Cc: 'Hadriel Kaplan'; 'SIP Forum Tech WG'
> Subject: Re: [SIPForum-techwg] Question re Application Server
> 
> 
> 
> Chris Sibley wrote:
> 
> >> Yup, and the part that creates the problem is the doc specifies
what
> the
> >> To/From MUST look like when coming from the SP.  We don't have to
cover
> >> any
> >> specific "scenario" if we just say something like: "This section
> specifies
> >> what the To/From MUST look like for PSTN-originated calls from the
> Service
> >> Provider.  The To and From headers may be different from those
> specified,
> >> for other call path scenarios.  For example, the requests may not
come
> >> from
> >> an Application Server at all, but rather through Proxies.  A PBX
MUST
> be
> >> capable of using the Request-URI as the target identifier and not
the
> >> To-URI."  Or something like that.
> >
> > Actually, I think there is considerable value in defining what the
'To:'
> and
> > 'From:' fields will look like when coming from the SP. The whole
point
> of
> > this specification is to define a "profile" of SIP that can be used
to
> > accomplish a specific function, PSTN interconnection. If we restrict
> > ourselves to only defining rules for the Request URI then IMO we
> > significantly "water down" the spec.
> >
> > At the very least, I think it is very important for the PBX to know
in
> > advance what URIs will look like in the 'From:' field so that they
will
> have
> > a predictable format that can be used to properly deliver calling
number
> > and/or name identification to the callee. Knowing in advance that an
> E.164
> > address will be present in this field is highly useful for
delivering
> that
> > feature. I'm pretty sure it would also be useful for a myriad of
other
> > traditional PBX features.
> 
> Chris, I think this highlights a real problem regarding callerid
> processing. What algorithm *should* the PBX use to decide what to
> display as the calling identity?
> 
> As things stand, it must base this on From. But is the From value to
be
> trusted?
> 

Not any more or less so than the caller-ID information delivered from
the PSTN (over a TDM connection) today... 

> I guess if the PBX has a contract with the SP, then the contract could
> state that the SP warrants that the From value is valid, and then the
> PBX could trust it for purpose of generating a callerid display. That
> would work for the gateway case that is covered.
> 

Since the SP can't 100% verify the CID information received from the
PSTN then I don't think that it could warrant to an enterprise that the
contents of the 'From:' field will be valid in any case.

> But then what about the inter-enterprise case where the SP is acting
as
> a proxy? Does the SP warrant the From value in that case? It *could*,
to
> some extent, by rejecting any incoming calls from a PBX where the From
> domain is not consistent with the authentication of the source PBX. I
> guess that is out of scope of this document, and could be added later
as
> a compatible upgrade. But is it consistent with the expectations of
the
> authors?
> 

Well, I guess the SP could verify that the domain in the 'From:' field
is valid for the originating enterprise but this would still not prevent
the enterprise from asserting an E.164 address in the user portion of
the URI that didn't belong to it (on the PSTN).

I think this would also be the case even if the identity headers are
used. When identity is used, I believe that the responsibility for
inserting the 'Identity:' and 'Indentity-Info:' headers would be on the
originating enterprise's proxy server, not the SP's. 

> A related issue is if the UAS is only capable of displaying callerid
as
> a number, rather than as a URI. Is it expected to extract the number
> from the From URI whenenver that looks like a number, and/or has
> user=phone, *regardless* of the domain of the URI? In general you are
> not supposed to "interpret" the user part unless it is your own
domain,
> even if it has user=phone. I think that can be stretched to allow
> interpreting the user part when one has specific knowledge of the
> conventions used by the domain, which could be assumed when it is the
SP
> domain. But I don't think it can be stretched to allow interpretation
of
> random other domains, unless part of SIPConnect is a requirement that
> all players have this convention.
> 

Since this is just a profile of SIP, I don't think it is unreasonable to
say that all players must be using the conventions as defined. That
said, the PBX needs some way of determining when to apply the
rules/conventions associated with the profile. Perhaps we should add
some guidelines around checking the 'Via:' header to make sure the
request came from the SP's proxy vs. some other proxy (that doesn't
implement the profile.)

> I know there is currently no general concensus on exactly how callerid
> should be handled. But I find it very suspect to ever trust using From
> for this unless it is supported by SIP Identity. It would be better if
>  From was always a TEL URI when it is a phone number, and the SP
refused
> requests when the From wasn't a phone number assigned to the source.
It
> would also be better if P-Asserted-ID was passed to the target PBX,
and
> was considered the only trustworthy source of caller identity.
> 

I'm not sure that using a tel: URI in the 'From:' field is a good idea
if we want to start using the identity headers in the future. 

<snip from RFC 4474>

.
Implementations that intend to send their requests through an
authentication service SHOULD put telephone numbers in the From header
field into SIP or SIPS URIs whenever possible.
.

</snip>

> 	Paul


**********************************************************************
This email may contain confidential information. If you are not
the intended recipient, please advise by return email and delete
immediately without reading or forwarding to others.
 -- Cbeyond 
**********************************************************************