Subject: [Ieprep] SIP-T/ISUP/SS7 interworking

From: "James M. Polk" <[email-masked]>
Date: Wed, 19 Jun 2002 11:35:07 -0500

Direct from the (co)author of the RFC and drafts on SIP/ISUP/SS7 interworking

>From: "Peterson, Jon" <[email-masked]>
>
>In addition to RFC3204 (which specifies MIME types for ISUP encapsulation)
>you might want to check out the following:
>
>http://www.ietf.org/internet-drafts/draft-ietf-sipping-sipt-02.txt
>(framework)
>http://www.ietf.org/internet-drafts/draft-ietf-sipping-isup-02.txt
>(translation)
>http://www.ietf.org/internet-drafts/draft-ietf-sipping-overlap-00.txt
>(specific to overlap)

Hence, Fred (and all), I don't believe this WG requires a new ID in this
area. Please let me know if these don't satisfy your ID requirement from
the Interim meeting, but I do believe pointing at the following should
proved the gap fillers we need.

*************************************
"People generally demand more respect for their own rights than they are
willing to allow for others"

James M. Polk
Senior Consulting Engineer
Office of the CTO

Cisco Systems
2200 East President George Bush Turnpike 
Richardson, TX  75082 USA
w) 972.813.5208
f)  972.813.5280
www.cisco.com

_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: "Gunn, Janet NE" <[email-masked]>
Date: Wed, 19 Jun 2002 14:17:09 -0400

I have only skimmed the first, but I have read the second and third
documents.

None of them seem to address the mapping and translation of "Calling Party's
Category" (CPC)(ISUP mandatory parameter), nor of "Precedence" (ISUP
optional parameter). 

Both of these will probably be necessary to support "GETS-like" IP telephony
emergency preparedness services.

Am I missing something?

-----Original Message-----
From: James M. Polk [mailto:[email-masked]]
Sent: Wednesday, June 19, 2002 12:35 PM
To: Berg, Dennis; [email-masked]
Subject: [Ieprep] SIP-T/ISUP/SS7 interworking

Direct from the (co)author of the RFC and drafts on SIP/ISUP/SS7
interworking

James M. Polk

Cisco Systems

---

From: [email-masked]
Date: Wed, 19 Jun 2002 17:59:20 EDT

> emergency preparedness services.

Mike Pierce comments:

I would add to this list the draft for tel:uri, with -05 just issued.

It seems that each of these drafts (SIP-T, ISUP mapping, overlap, tel:uri) 
each deal with one small aspect of interworking between ISUP and SIP. Some 
parts are simple mapping, some parts are encapsulation of information without 
the possibility of interpretation, and some are mapping with information 
lost. Each seems to leave out something that would likely be important in 
some particular situation, since each is only trying to address a limited 
application.

I am afraid that these will never be able to satisfy the general need for 
ISUP to SIP interworking, since none of them appears to be chartered to do 
that. So they leave out things like "precedence", or "calling party's 
category" which are essential to interworking in at least some case. Or they 
do not take into account some realities about the existing PSTN. If it were 
within the charter of any one of these efforts to address the entire ISUP-SIP 
interworking issue, then any specific procedures to carry the priority level 
("precedence" level in ISUP), whether in a new R-P header or some other way, 
would clearly belong in that effort.

Mike Pierce
Artel

---

From: "Folts, Harold" <[email-masked]>
Date: Wed, 19 Jun 2002 19:14:41 -0400

> From: RJ Atkinson [mailto:[email-masked]] 
> Sent: Wednesday, June 19, 2002 4:33 PM
> To: James M. Polk
> Cc: [email-masked]
> Subject: Re: [Ieprep] SIP-T/ISUP/SS7 interworking
> 
>
> 
> It is not unusual for an IETF WG to start with definition of 
> high-level requirements (e.g. for a signalling mechanism's 
> capabilities), then using those high-level requirements as a 
> vehicle for talking with designers in 
> other WGs
> about what kinds of capabilities are missing and perceived as needed.
> 
> This sure seems pretty much like traditional top-down 
> engineering to me, not a catch-22 where there is no way out.

Top down systems engineering it the most effective approach to any problem.
That is what I am attempting with the ETS work.

Hal