Stella Gnepp wrote:
Specifically, I am trying to determine whether a call is still
considered native-SIP if a call originates as TDM, but is converted from
TDM to data before leaving the customer's premises. I am hoping that
there is a standard definition that states the point of origination
(whether it is at the point of where the call leaves the customer
premises, or before then-at the equipment level) for determining whether
a call is native-SIP.
To the best of my knowledge, IETF documents do not make a distinction
between "native" and "non-native" modalities as you describe them.
On my desk here, I have a Linksys terminal adapter with an analog phone
plugged into it. Is that native SIP or not? To a third party observer,
there is no apparent difference between this arrangement and a nearby
Linksys SIP phone. So at this level, I'd argue that the distinction
between native and non-native has no useful meaning.
However, IETF does talk about the PSTN-anchored identity problem. For
example, if a call originates in TDM space and uses a PSTN telephone
number as its source identifier, can we really trust that identifier for
use in an RFC 4474 Identity header? Caller-ID is notoriously easy to spoof.
In the case you outline above, the customer premises may provide an RFC
4474 authentication server that signs the call after it is converted
from TDM to SIP. It's up to them to decide whether they trust their TDM
infrastructure well enough to assert strong identity on calls coming
from TDM.
In my Linksys case, since I know the physical arrangement between my
phone handset and my Linksys ATA (I can see the whole cable from here)
and believe it to be secure, it would be reasonable for me to assert
identity based on the Linksys ATA. If it supported the behavior,m it
could act as an RFC 4474 authentication service, or it could use digest
authentication to prove identity to an upstream proxy which could in
turn add an RFC 4474 Identity header.
But if I were to provide a dial-in phone line to that Linksys ATA and
configure it as a gateway, there's no good way to support RFC 4474.
Certainly the identity of the gateway could be expressed, but we don't
have a way to authnticate the calling party on the originating end of
the PSTN connection other than caller-ID, and we know that's too weak to
rely on.
So I think that the problem you're attempting to describe as "native"
and "non-native" SIP is better expressed in terms of whether or not the
originating party can be strongly authenticated. We know this is a
problem for PSTN cases, and we don't have a good general answer.
--
Dean Willis
former SIP WG chair
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf