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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf