Subject: [Sip] two things (was Introducing the "new bis" - draft-ietf-sip-rfc2543bis-05)

From: Scott Bradner <[email-masked]>
Date: Thu, 1 Nov 2001 18:01:32 -0500 (EST)

Re; "791-style values"
seems passing strange to focus too much on a 1981 understanding of 
what network priorities might be 20 years later

Re: IEPS
we are thinking of having an IEPS BOF to think about the IEPS problem
as a whole - it is premature to look at IEPS-like issues on an application
by application basis

Scott

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

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 01 Nov 2001 18:03:26 -0600

Scott

Understand your confusion -- however, this thread is rooted in the topic of
MLPP and the need for strict mapping of a modified set of Priority values
within SIP. ANSI T1.619 (and 619A), or MLPP, picked RFC791's Priority scheme
for its interworking by assigning a Precedence value for every phone call of 4
(or 791's 000 "Routine") to the highest value in the network of 0 (or 719's 101
"Flash Override). ANSI defined a descending order to their Precedence scheme so
that nothing was higher in the handset than 0 ("Flash Override"). ANSI also
chose to not define the remainder of RFC791 values -- I wasn't there in 1992
and don't know why.

Interaction between the existing MLPP enabled networks and IP networks need to
map directly if VoIP is to augment, transition off of, or replace existing
TDM/ISDN-based MLPP infrastructure (per customer requirements which are fairly
unforgiving and rigid). 

With this requirement known, I set out (starting in Adelaide) and submitted
several ID's mapping the Signaling of SIP to my proposed 5 corresponding
Priority Values that happen to match RFC791 (without the 3 higher vales, of
course). I know and admit it's awkward doing it this way -- but sometimes you
bring Mohammed to the mountain, and other times you bring the mountain to
Mohammed.

Here we have existing functionalities that must remain to the endpoints even if
they are transitioned to IP-based solutions. It's not as simple as building a
great GW between TDM and IP networks.

Writing the effort in SIP is not going to solve the whole issue, hence I wrote
another ID: mlpp-over-ip, which I'm updating now in time for SLC.

Comments?

>as a whole - it is premature to look at IEPS-like issues on an application

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

James M. Polk
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

---

From: Henry Sinnreich <[email-masked]>
Date: Thu, 01 Nov 2001 18:26:10 -0600

>ANSI also chose to not define the remainder of RFC791 

I don't understand the involvement of ANSI in Internet standards. Would
think the IETF has moved the Internet ahead well enough, without the
interference from every regional standards body. Balkanize the Internet
with ANSI, ETSI and Asia-Pacific, etc. regional standards?

Henry

Henry Sinnreich
WorldCom
400 International Parkway
Richardson, Texas 75081
USA  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of James
M. Polk
Sent: Thursday, November 01, 2001 6:03 PM
To: Scott Bradner; [email-masked]
Subject: Re: [Sip] two things (was Introducing the "new bis" -
draft-ietf-sip-rfc2543bis-05)

Scott

Understand your confusion -- however, this thread is rooted in the topic
of MLPP and the need for strict mapping of a modified set of Priority
values within SIP. ANSI T1.619 (and 619A), or MLPP, picked RFC791's
Priority scheme for its interworking by assigning a Precedence value for
every phone call of 4 (or 791's 000 "Routine") to the highest value in
the network of 0 (or 719's 101 "Flash Override). ANSI defined a
descending order to their Precedence scheme so that nothing was higher
in the handset than 0 ("Flash Override"). ANSI also chose to not define
the remainder of RFC791 values -- I wasn't there in 1992 and don't know
why.

Interaction between the existing MLPP enabled networks and IP networks
need to map directly if VoIP is to augment, transition off of, or
replace existing TDM/ISDN-based MLPP infrastructure (per customer
requirements which are fairly unforgiving and rigid). 

With this requirement known, I set out (starting in Adelaide) and
submitted several ID's mapping the Signaling of SIP to my proposed 5
corresponding Priority Values that happen to match RFC791 (without the 3
higher vales, of course). I know and admit it's awkward doing it this
way -- but sometimes you bring Mohammed to the mountain, and other times
you bring the mountain to Mohammed.

Here we have existing functionalities that must remain to the endpoints
even if they are transitioned to IP-based solutions. It's not as simple
as building a great GW between TDM and IP networks.

Writing the effort in SIP is not going to solve the whole issue, hence I
wrote another ID: mlpp-over-ip, which I'm updating now in time for SLC.

Comments?

James M. Polk
Consulting Engineer
Office of the CTO

Cisco Systems