Subject: RE: [Sipping] I-D ACTION:draft-mukundan-sipping-dpnss-01.txt

From: "Ranjith Mukundan" <[email-masked]>
Date: Sat, 8 Feb 2003 00:09:50 +0530

Hi,

posting WRT http://www.ietf.org/internet-drafts/draft-mukundan-sipping-dpnss-01.txt

>> Why is it so important to be able to tunnel DPNSS in SIP?  I'd prefer

>> that folks implement a translation to SIP, where SIP can natively carry

>> all the information that DPNSS is trying to convey.

To put things in perspective:

1- DPNSS is a protocol (deployed primarily in UK, NZ, Australia and parts of NA) very similar to QSIG (deployed primarily Europe) for interconnecting PBXs or centrex customers hosted off LEs. DPNSS (like QSIG) finds enormous application towards realizing a local VPN or network-wide VPN services.

2- This draft aims to do exactly what RFC 3204 (MIME objects for QSIG/ISUP) does for QSIG with appropriate/relevant customization for DPNSS - i.e., to provide end-to-end & *complete*, DPNSS Service transparency between pockets of DPNSS based private networks over a SIP based core.

3- Currently, circuit-switched SS7 based cores, provide equivalent DPNSS tunneling mechanisms through (ETSI & ANSI) ISUP *apart from* the concomitant translation/interworking mechanisms to ISUP. The translation/interworking mechanism to ISUP is limited to the basic call and certain ISUP supplementary services where there is a direct/easy equivalent.

4- H.323 also provides equivalent tunneling mechanisms (via the H.450 Annexe procedures) for transparently carrying DSS1 based signaling between DSS1-based network elements/gateways, over a H.323 core.

Some specifics:

1- DPNSS supports, as specified in BTNR 188, approximately 240+ supplementary features/services (like Call Back When Free, Call Back When Next Used, Executive Intrusion, Travelling Class of Service, Do Not Disturb, Night Service, Private Network Route Optimization, Centralized Operator, Three Party Takeover, Remote Diversion Registration etc). It would be almost impossible to interwork to equivalent mechanisms in SIP, without losing the service transparency when using an intervening SIP based core.

2- Yes, we definitely need an interworking/translation mechanism to map all the basic call/service paremeters, and procedures for mapping the messages. But this does not preclude the need for a DPNSS MIME type, but would rather be complimentary to the MIME type mechanism. Similar to http://www.ietf.org/internet-drafts/draft-ietf-sipping-qsig2sip-00.txt , for QSIG, we are in the process of putting together an interworking draft for DPNSS as well - but rather than making it DPNSS specific, we are trying to make it a common draft to cover PRI, DPNSS & DASS2 [as Q.SIG interworking is already a SIPPING WG ID]. Note that, PRI and DASS2 will not need a MIME type as these are, as one might be aware, for PSTN access, unlike DPNSS and QSIG (which are private network protocols).

3- From the SIP perspective, carrying non-SIP applications as MIME objects to ensure end to end service transparency is architecturally less appalling than, say for e.g., tunneling DSS1 protocols in H.323 based network - so the SIP DPNSS MIME proposition as per this I-D is the obvious way forward for DPNSS service transparency over a SIP based core, especially now that we see acute deployment needs to be met.

cheers,

ranjith..

> -----Original Message-----

> From: [email-masked] [mailto:[email-masked]]On Behalf

> Of

> Ranjith Mukundan

> Sent: Tuesday, February 04, 2003 5:32 PM

> To: [email-masked]

> Subject: RE: [Sipping] I-D ACTION:draft-mukundan-sipping-dpnss-01.txt

> Hi List,

> We would like you take a look at this draft and revert with any

> comments/queries that you might have.

> SIPPING Chairs,

> The authors feel that the requirement and the need for this MIME type

> is

> quite acute. Hence we'd like you to consider this for inclusion as a

> WG I-D

> and suggest the way forward.

> - ranjith..

> -----Original Message-----

> From: [email-masked] [mailto:[email-masked]]On Behalf

> Of

> [email-masked]

> Sent: Tuesday, February 04, 2003 5:14 PM

> To: IETF-Announce:

> Cc: [email-masked]

> Subject: [Sipping] I-D ACTION:draft-mukundan-sipping-dpnss-01.txt

> A New Internet-Draft is available from the on-line Internet-Drafts

> directories.

>       Title           : MIME media types for DPNSS Objects

>       Author(s)       : R. Mukundan et al.

>       Filename        : draft-mukundan-sipping-dpnss-01.txt

>       Pages           : 9

>       Date            : 2003-2-3

> This document describes Multipart Internet Mail Extensions (MIME) type

> for application/Digital Private Network Signaling System (DPNSS)

> objects for use in Session Initiation Protocol (SIP) applications,

> according to the rules defined in RFC 2048. These types can be used to

> identify Digital Private Network Signaling System 1 (DPNSS 1) objects

> within a SIP message such as INVITE or INFO, as might be implemented

> when using SIP in an environment where part of the call involves

> interworking to DPNSS 1 based Private Networks. RFC 3204 addresses a

> similar need for Integrated Service Digital Network User Part (ISUP)

> and Q Signaling (QSIG).

> A URL for this Internet-Draft is:

> http://www.ietf.org/internet-drafts/draft-mukundan-sipping-dpnss-01.tx

> t

> To remove yourself from the IETF Announcement list, send a message to

> ietf-announce-request with the word unsubscribe in the body of the

> message.

> Internet-Drafts are also available by anonymous FTP. Login with the

> username

> "anonymous" and a password of your e-mail address. After logging in,

> type "cd internet-drafts" and then

>       "get draft-mukundan-sipping-dpnss-01.txt".

> A list of Internet-Drafts directories can be found in

> http://www.ietf.org/shadow.html or

> ftp://ftp.ietf.org/ietf/1shadow-sites.txt

> Internet-Drafts can also be obtained by e-mail.

> Send a message to:

>       [email-masked].

> In the body type:

>       "FILE /internet-drafts/draft-mukundan-sipping-dpnss-01.txt".

> NOTE: The mail server at ietf.org can return the document in

>       MIME-encoded form by using the "mpack" utility.  To use this

>       feature, insert the command "ENCODING mime" before the "FILE"

>       command.  To decode the response(s), you will need "munpack" or

>       a MIME-compliant mail reader.  Different MIME-compliant mail readers

>       exhibit different behavior, especially when dealing with

>       "multipart" MIME messages (i.e. documents which have been split

>       up into multiple messages), so check your local documentation on

>       how to manipulate these messages.

> Below is the data which will enable a MIME compliant mail reader

> implementation to automatically retrieve the ASCII version of the

> Internet-Draft.

> _______________________________________________

> 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

_______________________________________________
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