Subject: Re: Native-SIP vs. Non-native SIP

From: "Stella Gnepp" <[email-masked]>
Date: Fri, 8 May 2009 17:11:21 -0400

Dear IETF:

I am following up on my April 23, 2009 email (please see below) to see
if there has been any feedback on my question regarding the distinction
between native and non-native SIP.  Please let me know.

Thank you for your assistance.

Sincerely, 

Stella Gnepp

________________________________

From: Stella Gnepp 
Sent: Thursday, April 23, 2009 3:20 PM
To: [email-masked]'
Subject: Native-SIP vs. Non-native SIP

Dear IETF:

I am looking for industry standards related to the definition of
native-SIP and non-native SIP voice communication.  

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.

Any assistance is greatly appreciated.

Thank you,

Stella Gnepp

Stella Gnepp
TNCI - Regulatory Affairs Manager
2 Charlesgate West
Boston, MA 02215
Phone:  617.369.1163
Efax:  617.369.1187
Email:  [email-masked] <mailto:[email-masked]> 
Web:  www.tncii.com <http://www.tncii.com/> 

The information contained in or attached to this email is confidential
and subject to the terms of any contractual agreement between you, your
Company and TNCI.  Please also note that the information contained in
this email is provided for discussion only; it is not an offer, is not
contractually binding on TNCI, and must be separately agreed-to in a
written contract duly negotiated and executed by both parties in order
to bind TNCI.

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 11 May 2009 14:55:47 -0500

Stella

I think the answer to your question depends on your point of view.

If a PSTN originated call connects with a gateway 
(i.e., a translator between two dissimilar 
communications or protocol techniques or methods) 
and converts that can set up into SIP - realizing 
that the SIP part needs to not violate any part 
of our RFCs, then yes, this is native SIP for the SIP leg of the call set up.

Obviously this is not SIP end-to-end (e2e), which 
some personally define as "native SIP".

I am not one.

I believe native SIP is anywhere there is 
standards compliant SIP messaging, even if the call set up is not SIP e2e.

Does answer you question?

James

At 04:11 PM 5/8/2009, Stella Gnepp wrote:
>Content-class: urn:content-classes:message
>Content-Type: multipart/alternative;
>         boundary="----_=_NextPart_001_01C9D021.89A2F61B"
>
>
>Dear IETF:
>
>I am following up on my April 23, 2009 email 
>(please see below) to see if there has been any 
>feedback on my question regarding the 
>distinction between native and non-native SIP.  Please let me know.
>
>----------
>I am looking for industry standards related to 
>the definition of native-SIP and non-native SIP voice communication.
>
>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 thenat the 
>equipment level) for determining whether a call is native-SIP.
>
>TNCI – Regulatory Affairs Manager
>2 Charlesgate West
>Boston, MA 02215
>Phone:  617.369.1163
>Efax:  617.369.1187
>Email:  <mailto:[email-masked]>[email-masked]
>Web:  <http://www.tncii.com/>www.tncii.com
>
>
>
>The information contained in or attached to this 
>email is confidential and subject to the terms 
>of any contractual agreement between you, your 
>Company and TNCI.  Please also note that the 
>information contained in this email is provided 
>for discussion only; it is not an offer, is not 
>contractually binding on TNCI, and must be 
>separately agreed-to in a written contract duly 
>negotiated and executed by both parties in order to bind TNCI.
>
>_______________________________________________
>Ietf mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ietf

---

From: Dean Willis <[email-masked]>
Date: Fri, 22 May 2009 10:15:29 -0500

> premises, or before then-at the equipment level) for determining whether

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