Subject: RE: [Sipping] RE: calling number blocking at sip/isup gateway

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 6 Feb 2002 04:39:55 -0600

Some notes below.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Juha Heinanen [mailto:[email-masked]]
> Sent: Wednesday, February 06, 2002 1:23 AM
> To: Peterson, Jon
> Cc: Jonathan Rosenberg; Tom-PT Taylor; [email-masked]';
> [email-masked]
> Subject: RE: [Sipping] RE: calling number blocking at sip/isup gateway
> 
[snip]
> 
> if presentation restricted mapping is not defined in the sip-isup i-d,
> then there is no hope for interoperability between uas and 
> sip/isup gws
> or between proxies and sip/isup gws.  

In fact, there are already numerous gateways that operate and interoperate
without the benefit of presentation restriction.

> it would mean that i as the
> customer of all this equipment would need to negotiate with 
> each vendor
> and try to make them implement the same mapping.  this would be in
> practise impossible.  therefore, i would not vote for advancing the
> sip/isup i-d before it specifies how restricted number presentation is
> handled.  

I submit I have illustrated amply that you can define how SIP would
interwork with the PSTN without inventing a presentation restriction
mechanism for SIP - please don't just assert the contrary, but let me know
in what respects your analysis differs from mine. 

I'll reiterate - the purpose of the SIP-ISUP mapping project (known
collectively as SIP-T) is not to add new features to SIP - it's to describe
how SIP and SS7, without any modifications on either side, can be
interworked. There are numerous bits of data that appear in SS7 that have no
SIP corrollary today, over and above presentation restriction indicators.
For example, there's an SS7 bit that allows you to specify that a one-way
echo canceller is available on a particular port. You might as well argue
that there can be no SIP-ISUP interoperability until we define an indicator
for the presence of a half-echo canceller somehow in SIP as well. The fact
remains that you don't need this information to interwork.

Anyway, the real problem is the want of a general privacy mechanism in SIP -
this really isn't draft-ietf-sipping-isup-00's problem. If there weren't
even an existing proposal for a presentation restriction mechanism, would
you still insist that the SIP-ISUP mapping draft should block until someone
proposes this feature for SIP? Because FYI, there's nothing comparable to a
continuity check feature proposed for SIP yet either. Nor any standard for
test tones in user agents to measure slope. The fact remains that SIP and
ISUP can usefully be interworked without these things.

Finally, when a general presentation restriction mechanism for SIP is
standardized, a new component of the SIP-ISUP mapping work (which is now
already distributed across four or five documents) could be authored to
describe the standard way of mapping presentation restriction. There's
nothing magical about being a part of draft-ietf-sipping-isup-00. I don't
think this will lead to any interoperability nightmares or undue negotiation
with vendors.

> 
> what comes to the solution, i'm happy with the one proposed by someone
> from cisco on this mailing list.

While I don't have the time to go into a detailed analysis of the existing
privacy proposal, suffice it to say that I understand it to be primarily
applicable to certain architectures in which user agents are untrusted and a
federation of intermediaries under a common policy arbitrarily modifies the
signaling provided by user agents, including asserting identity on the
user's behalf. I don't think that the SIP-ISUP mapping has any need to
acquire a dependency on this network design philosophy. I believe the
sip-privacy draft is admirable, and it no doubt serves the purpose for which
it was created, but I don't believe it has widespread general applicability
for SIP. 

> -- juha

_______________________________________________
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

---

From: Juha Heinanen <[email-masked]>
Date: Thu, 7 Feb 2002 21:26:29 +0200

Peterson, Jon writes:

 > interworked.

in that case, it might be fair to list in the i-d its applicability,
i.e., which ss7 capabilities are not supported by this i-d.

 > proposes this feature for SIP?

no, it would be ok to go forward as long as the things that can't be
mapped are listed.

-- juha