Subject: RE: [Sipping] QSIG Vs DPNSS MIME

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 11 Feb 2003 14:57:46 -0500

I begin to sympathize with those who argued that the ISUP/QSIG MIME type
should have been a more open-ended envelope for telephony signaling
information. I am reluctant to standardize every conceivable sort of
telephony signaling as a MIME type with some profile information for
encapsulating it in SIP.
 
I suppose the question really is one of how great the need is to standardize
this DPNSS encapsulation. I'm not really familiar with it, so I don't have
much of an opinion either way.
 
In any event, as another nit, this document should not define the
Content-Disposition header, it should reference the definition and BNF in
RFC3204.
 
Jon Peterson
NeuStar, Inc.

-----Original Message-----
From: Mark Watson [mailto:[email-masked]]
Sent: Tuesday, February 11, 2003 9:29 AM
To: [email-masked]
Subject: RE: [Sipping] QSIG Vs DPNSS MIME

All,
 
I really can't see any difference between DPNSS and Q.SIG when it comes to
the need for a MIME type for carriage of this within SIP. Can anyone come up
with an argument for/against this draft which does not apply to Q.SIG just
as well ?
 
If not, then I certainly think this should be progressed.
 
I have some comments on the draft:
1) DPNSS has now been published by the UK's Network Interoperability
Consultative Committee as NICC Document 1301:2001/03. You can find it at
http://www.oftel.gov.uk/ind_groups/nicc/Public/interconnectstandards/isc.htm
<http://www.oftel.gov.uk/ind_groups/nicc/Public/interconnectstandards/isc.ht
m>  along with lots of other gems.
 
You should reference this version, rather than the somewhat harder to obtain
BTNR.
 
2) Why do you need a length octet at the front of the message ? Can't you
(or shouldn't you) put a Content-Length in the MIME headers for this MIME
part ?
3) I think given the short length of the messages you could get away with
mandating that segmented DPNSS messages should always be reassembled before
encapsulating in SIP and that receivers must be able to receive such
reassembled messages. This removes some unnecessary complexity.
4) Section 3, under table 1, you say 'Floating Point' when you mean
'Decimal'. I think the words 'contiguously increasing' could probably be
removed here too. You will have trouble finding the next real number after
6.00!
 
Regards...Mark

-----Original Message-----
From: Ranjith Mukundan [mailto:[email-masked]]
Sent: 11 February 2003 08:59
To: [email-masked]
Subject: [Sipping] QSIG Vs DPNSS MIME

we'd appreciate some views on this draft from atleast those who fairly
understand QSIG.

of course, others who feel that this MIME type collides directly with the
purpose of SIP are encouraged to provide alternatives bearing in mind that
providing complete end-to-end service transparency over the intervening SIP
based core would be essential, if we are to provide a seamless migration
path from H.323 based core networks - which already provide equivalent
mechanisms for DSS1 based protocols.

- ranjith..

-----Original Message-----
From:   Ranjith Mukundan
Sent:   Sat 2/8/2003 12:09 AM
To:     [email-masked]
Cc:    
Subject:        RE: [Sipping] I-D ACTION:draft-mukundan-sipping-dpnss-01.txt

Hi,

posting WRT
http://www.ietf.org/internet-drafts/draft-mukundan-sipping-dpnss-01.txt
<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
<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]
<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]
<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
<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 <http://www.ietf.org/shadow.html>  or
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
<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
<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

---

From: "Ranjith Mukundan" <[email-masked]>
Date: Wed, 12 Feb 2003 09:10:03 +0530

QSIG Vs DPNSS MIMEin so far as inter-PBX/Centrex connectivity goes, amongst
the DSS1 derived protocols, DPNSS is, IMO, the *only*  (big) missing piece.
Can anyone think of another, standards-based, telephony signaling, the might
require a MIME carriage?? (atleast, i can't think of any - not even an
arcane, minimally deployed one)

As I mentioned earlier, we dont need MIME types for protocols like DASS2,
PRI and all the other 'conceivable sort' of telephony signaling thats used
for PSTN connectivity (vis-a-vis inter-PBX/centrex connectivity).  Even in
the case of telephony protocols used for inter-PBX/centrex connectivity,
unless it requires the same end to end, complete service transparency as in
the case of private networks interconnected by QSIG or DPNSS, it does not
mandate carriage as MIME type (a simple interworking function to SIP would
suffice).

So I dont think we'll a slew of MIME types...

Content-Disposition header, it should reference the definition and BNF in
RFC3204.
Should've known. thanks - it was an oversight.

cheers,
- ranjith..
  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]]On Behalf Of
Peterson, Jon
  Sent: Wednesday, February 12, 2003 1:28 AM
  To: 'Mark Watson'; [email-masked]
  Subject: RE: [Sipping] QSIG Vs DPNSS MIME

  I suppose the question really is one of how great the need is to
standardize this DPNSS encapsulation. I'm not really familiar with it, so I
don't have much of an opinion either way.

  Jon Peterson
  NeuStar, Inc.
    -----Original Message-----
    From: Mark Watson [mailto:[email-masked]]
    Sent: Tuesday, February 11, 2003 9:29 AM
    To: [email-masked]
    Subject: RE: [Sipping] QSIG Vs DPNSS MIME

    All,

    I really can't see any difference between DPNSS and Q.SIG when it comes
to the need for a MIME type for carriage of this within SIP. Can anyone come
up with an argument for/against this draft which does not apply to Q.SIG
just as well ?

along with lots of other gems.

    You should reference this version, rather than the somewhat harder to
obtain BTNR.

    2) Why do you need a length octet at the front of the message ? Can't
you (or shouldn't you) put a Content-Length in the MIME headers for this
MIME part ?
    3) I think given the short length of the messages you could get away
with mandating that segmented DPNSS messages should always be reassembled
before encapsulating in SIP and that receivers must be able to receive such
reassembled messages. This removes some unnecessary complexity.
    4) Section 3, under table 1, you say 'Floating Point' when you mean
'Decimal'. I think the words 'contiguously increasing' could probably be
removed here too. You will have trouble finding the next real number after
6.00!

    Regards...Mark

      -----Original Message-----
      From: Ranjith Mukundan [mailto:[email-masked]]
      Sent: 11 February 2003 08:59
      To: [email-masked]
      Subject: [Sipping] QSIG Vs DPNSS MIME

      of course, others who feel that this MIME type collides directly with
the purpose of SIP are encouraged to provide alternatives bearing in mind
that providing complete end-to-end service transparency over the intervening
SIP based core would be essential, if we are to provide a seamless migration
path from H.323 based core networks - which already provide equivalent
mechanisms for DSS1 based protocols.

      - ranjith..

      -----Original Message-----
      From:   Ranjith Mukundan
      Sent:   Sat 2/8/2003 12:09 AM
      To:     [email-masked]
      Cc:
      Subject:        RE: [Sipping] I-D
ACTION:draft-mukundan-sipping-dpnss-01.txt

      Hi,

      posting WRT

      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:

      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..

      > From: [email-masked] [mailto:[email-masked]]On
Behalf
      > Subject: RE: [Sipping] I-D
ACTION:draft-mukundan-sipping-dpnss-01.txt
      > From: [email-masked] [mailto:[email-masked]]On
Behalf
      > http://www.ietf.org/shadow.html or

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 12 Feb 2003 00:48:13 -0500

My two cents on this stuff (applies to QSIG too).

The idea behind sip-t was that carriage of the isup bodies made sense 
because the semantics of the sip messages matched the isup; the isup was 
providing "extra" information that was simply carried in its native 
form. Having the semantics match is important for use of services in the 
SIP network.

If these DPNSS bodies have a semantic different than the SIP message 
they are carried in (i.e., call transfer is carried in an INFO), then I 
think thats a bad thing and not in line with the sip-t architecture.

Now, I don't know DPNSS really, so I don't know if this is what you are 
proposing. It is just a comment on the general direction.

-Jonathan R.

Peterson, Jon wrote:
> standardize this DPNSS encapsulation. I'm not really familiar with it, 
> so I don't have much of an opinion either way.
>  
> Content-Disposition header, it should reference the definition and BNF 
> in RFC3204.
>  
> Jon Peterson
> NeuStar, Inc.
> 
>     *From:* Mark Watson [mailto:[email-masked]]
>     *Sent:* Tuesday, February 11, 2003 9:29 AM
>     *To:* [email-masked]
>     *Subject:* RE: [Sipping] QSIG Vs DPNSS MIME
> 
>     All,
>      
>     I really can't see any difference between DPNSS and Q.SIG when it
>     comes to the need for a MIME type for carriage of this within SIP.
>     Can anyone come up with an argument for/against this draft which
>     does not apply to Q.SIG just as well ?
>      
>     http://www.oftel.gov.uk/ind_groups/nicc/Public/interconnectstandards/isc.htm along
>     with lots of other gems.
>      
>     You should reference this version, rather than the somewhat harder
>     to obtain BTNR.
>      
>     2) Why do you need a length octet at the front of the message ?
>     Can't you (or shouldn't you) put a Content-Length in the MIME
>     headers for this MIME part ?
>     with mandating that segmented DPNSS messages should always be
>     reassembled before encapsulating in SIP and that receivers must be
>     able to receive such reassembled messages. This removes some
>     unnecessary complexity.
>     'Decimal'. I think the words 'contiguously increasing' could
>     probably be removed here too. You will have trouble finding the next
>     real number after 6.00!
>      
>     Regards...Mark
>      
> 
>         *From:* Ranjith Mukundan [mailto:[email-masked]]
>         *Sent:* 11 February 2003 08:59
>         *To:* [email-masked]
>         *Subject:* [Sipping] QSIG Vs DPNSS MIME
> 
>         we'd appreciate some views on this draft from atleast those who
>         fairly understand QSIG.
> 
>         of course, others who feel that this MIME type collides directly
>         with the purpose of SIP are encouraged to provide alternatives
>         bearing in mind that providing complete end-to-end service
>         transparency over the intervening SIP based core would be
>         essential, if we are to provide a seamless migration path from
>         H.323 based core networks - which already provide equivalent
>         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.
> 
>         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:
> 
>         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
>         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
>         , 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..
> 
>          > From: [email-masked]
>         [mailto:[email-masked]]On Behalf
>          > Of
>          > Ranjith Mukundan
>          > From: [email-masked]
>         [mailto:[email-masked]]On Behalf
>          > Of
>          > [email-masked]
>          >       "FILE
>         /internet-drafts/draft-mukundan-sipping-dpnss-01.txt".
>          >
>          > Sipping mailing list 
>         https://www1.ietf.org/mailman/listinfo/sipping
>         _______________________________________________ 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 
> 

-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
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: "Ranjith Mukundan" <[email-masked]>
Date: Wed, 12 Feb 2003 12:52:28 +0530

In case of DPNSS too the message semantics matches SIP messages - atleast to
the same extent as it does for ISUP. The primary driver for carrying the
DPNSS objects is to seamlessly transfer the DPNSS supplementary service
information across pockets of DPNSS private networks (including DPNSS based
centrex customer groups) over an intervening SIP based core, in its native
form.

In fact, from the message semantics point of view (as opposed to the
supplementary service procedures and info elements point of view); as far as
the session setup, control and release messages go, DPNSS messages (ISRM -
for setup, NAM-for alerting, CRM/CIM- for rel/rel-ack, ANS, EEM - for end to
end 'pass along' messages etc) are more aligned to ISUP message semantics
than perhaps to QSIG message semantics. For e.g., in case of QSIG some of
the session related service messages like NOTIFY, INFORMATION, FAC - would
all get carried in SIP INFO message, while in the case of DPNSS, only EEM
(equivalent of PAM in ANSI ISUP) would get carried in the SIP INFO and hence
finds a better semantic match to SIP messages - perhaps a better match when
compared to QSIG.

It's only wrt the DPNSS overlap messages and layer 3 maintenance messages
(like LLM, LRM etc) that finding a semantically good message fit to SIP
becomes diffucult - but equivalent constraints exists in case of ISUP
overlap and maintenance messages (Blocking, Reset, Cirtuit Validation Test
etc) too.

We could include some typical service flows in the appendix of the this
draft to reinforce the fact that DPNSS layer 3 messages does in fact render
itself for a better semantic message fit with SIP.

cheers,
- ranjith..

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Jonathan Rosenberg
Sent: Wednesday, February 12, 2003 11:18 AM
To: Peterson, Jon
Cc: 'Mark Watson'; [email-masked]
Subject: Re: [Sipping] QSIG Vs DPNSS MIME

-Jonathan R.

along
>          > Subject: [Sipping] I-D
>          > [email-masked] for questions on current sip
Use