Subject: [Sipping] Re: mike pierce issue summary (item #3)

From: [email-masked]
Date: Fri, 16 Aug 2002 15:33:40 EDT

In a message dated 8/15/02 5:11:13 PM Eastern Daylight Time, 
[email-masked] writes:

> 3. Cut-through of the backward path can be misused. SIP introduces 
> significant additional risks that do not exist in Q.931-ISUP mapping. The 
> solution in the PSTN world partly depended on the concept of defining 
> different types of exchanges (originating, terminating, transit, 
> international gateways, etc) and identifying trausted and non-trusted 
> entities. SIP tries to avoid such a distinction, with a GW not knowing how 
it 
> fits in the call setup, therefore, unaware of any special requirement it 
has 
> regarding cut-through. The model in the PSTN was based on knowing that the
> call progess tones before answer came from a "trusted" entity, which wasn't 
> going to misuse the transmission path to instead pass data. When the 
> destination was not trusted, the final trusted switch would not cut-through 
> until answer was returned so that billing could be started. It applied the
> call progress tones, and was allowed a very short time to remove that tone
> and cut-through locally. SIP doesn't have this concept, and the 
architecture 
> and protocol do not allow for a fast cut-through upon answer, hence, the 
> difficulty trying to deal with this problem.
> 

[JP] The mechanism in your point (4) below provide clear recommendations that
would satisfy this concern. No mechanism needs to be added to address your
concerns (nor do you suggest one). You're just throwing up more dust because
you dislike the SIP architecture, which allows (gasp) a network of equals.
This creates challenges and opportunities for designer. In any event, we're
not going to change the SIP architecture, especially not in this document.

[MAP] It isn't a question of whether or not I "dislike the SIP architecture". 
I try to keep emotion out of this.

It's a question of whether there are some agreed requirements that must be 
met for any technology/architecture that is trying to provide human-to-human 
telephone service, especially one that needs to interwork with the existing, 
ubiquitous, well-functioning network. And it's a question of whether any new 
architectural concept can meet those requirements.

Part of the fundamental problem in this discussion is that some of the more 
vocal participants are not willing to admit that the existing network was 
well-designed to do what it was intended to do. I won't bore you with some of 
the quotes I have accumulated regarding some people's admitted 
dislike/disdain for what currently exists. I don't believe I have ever 
expressed such derogatory statements about SIP. I have only posed techincal 
issues.

The subject of when to cut-through the media path took up a significant 
amount of time in the development of existing telephone standards, and was 
based on some common understanding of the requirements. Billing, fraud, 
maximum speech clipping, etc. were considered. I sense that there is not a 
similar understanding (or agreement) of the requirements in this similar 
discussion in SIP. I am unaware of a statement of the requirements for call 
setup time or for media cut-through upon answer. My comment above was trying 
to focus on at least one of the "challenges and opportunities" related to 
meeting requirements for speech clipping while still addressing fraud 
prevention through control of the media connect time.

But, this can not be left as a challenge "for the designer". It must be 
solved in the standard, in a normative way, or we'll never expect to have 
interoperability.

Mike Pierce
Artel

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 16 Aug 2002 16:44:54 -0500

I agree that the interplay of Internet-based trust models with the existing
(and highly successful, we all conceed) trust models of the PSTN is a
fascinating subject for future inquiry, but I don't think we need to boil
that ocean before a single SIP-ISUP gateway can be deployed (existence
proofs suggest otherwise, anyway). Returning from the 10,000 foot level, the
issue at hand is whether or not a gateway operator can utilitize a policy
that would not cut through media until ANM/200, at their discretion, to
combat possible fraud resulting from early backwards media, etc. Your demand
that this 'must be removed' (in item #4) speaks, as you tend to, for all
operators of gateways in the world. We provide a couple of alternatives,
including timers, and since in your estimation none of them meet the high
standards of the PSTN we should obviously scuttle the mapping draft and sit
on our hands. But gateway operators have already chosen to deploy this
technology. Over time, I believe that we will invent better ways to manage
these risks. For now, that we have noted the risks, and that we have
provided a few rough mechanisms that are adequate to answer them, is enough,
I think.

Jon Peterson
NeuStar, Inc.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, August 16, 2002 12:34 PM
To: [email-masked]; [email-masked]
Subject: Re: mike pierce issue summary (item #3)

it 
has 

architecture 
> difficulty trying to deal with this problem. 

[JP] The mechanism in your point (4) below provide clear recommendations
that 
would satisfy this concern. No mechanism needs to be added to address your 
concerns (nor do you suggest one). You're just throwing up more dust because

[MAP] It isn't a question of whether or not I "dislike the SIP
architecture". I try to keep emotion out of this. 

Part of the fundamental problem in this discussion is that some of the more
vocal participants are not willing to admit that the existing network was
well-designed to do what it was intended to do. I won't bore you with some
of the quotes I have accumulated regarding some people's admitted
dislike/disdain for what currently exists. I don't believe I have ever
expressed such derogatory statements about SIP. I have only posed techincal
issues. 

Mike Pierce 
Artel 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP