Subject: [Sipping] QSIG Vs DPNSS MIME

From: "Ranjith Mukundan" <[email-masked]>
Date: Tue, 11 Feb 2003 14:29:02 +0530

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

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

---

From: "Mark Watson" <[email-masked]>
Date: Tue, 11 Feb 2003 17:29:06 -0000

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> 

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

> From: [email-masked] [ mailto:[email-masked]
<mailto:[email-masked]> ]On Behalf
> From: [email-masked] [ mailto:[email-masked]
<mailto:[email-masked]> ]On Behalf
> http://www.ietf.org/internet-drafts/draft-mukundan-sipping-dpnss-01.tx
<http://www.ietf.org/internet-drafts/draft-mukundan-sipping-dpnss-01.tx> 
> http://www.ietf.org/shadow.html <http://www.ietf.org/shadow.html>  or
<ftp://ftp.ietf.org/ietf/1shadow-sites.txt> 
> implementation to automatically retrieve the ASCII version of the
<https://www1.ietf.org/mailman/listinfo/sipping> 
> [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: Tue, 11 Feb 2003 23:49:31 +0530

Mark,

>> part ?

[ranjith]

The MIME Content-length is for the entire MIME object and represents the cumulative lenght of the MIME content. There is no MIME length field specifically for one of the many potential MIME objects that could have been encapsulated. For e.g., in the examples illustrated in the draft, the content length would be indicative of the SDP and the DPNSS PDU put together. Given this, for implementation ease, the length field will be highly desirable. We are also drawing upon our implementation experience from an equivalent mechanism that is employed while carrying DPNSS in ANSI ISUP - where, a length field is (logically) prepended along the encapsulated DPNSS PDU.

>> reassembled messages. This removes some unnecessary complexity.

[ranjith]

The carriage of segmented DPNSS messages was retained, albeit leading to inefficient network usage, as an *option* to primarily, accomodate existing DPNSS layer 3 gateway implementations, where the DPNSS message processing (either as transit or end-node function) is primarily based on segmented DPNSS messages. Even in DPNSS - H.323 gateway implementations that exist, segmented DPNSS messages are not re-assembled. In order to keep the migration (towards SIP based core) for the existing DPNSS gateway implementations seamless, it would indeed be better to retain carriage of segmented DPNSS messages as an *option* BUT *strongly recommend* to reassemble DPNSS messages before encapsulation in SIP. We'll modify the text in the draft accordingly.

cheers,

- ranjith..

-----Original Message-----

From:   Mark Watson [mailto:[email-masked]]

Sent:   Tue 2/11/2003 10:59 PM

To:     [email-masked]

Cc:

Subject:        RE: [Sipping] QSIG Vs DPNSS MIME

All,

as well ?

BTNR.

part ?

6.00!

Regards...Mark

-----Original Message-----

To: [email-masked]

understand QSIG.

- ranjith..

-----Original Message-----

From:   Ranjith Mukundan

To:     [email-masked]

Cc:

Hi,

posting WRT

Some specifics:

cheers,

ranjith..

SIP

---

From: "Ranjith Mukundan" <[email-masked]>
Date: Wed, 12 Feb 2003 00:27:17 +0530

John,

>> 4. During this work we found it necessary to specify that a QSIG-SIP gateway

>> should behave as a transit PBX from the perspective of the QSIG protocol.

[ranjith]

Yes, as in the case of QSIG, the DPNSS-SIP gateway too is expected to behave as a 'transit' from the DPNSS point of view. Thats a good point you raised. We need to look harder at this aspect and incorporate the required text in the draft (esp regarding the transit timers etc).

>> 6. The message buffering option may not be suitable for buffering ISRM(I)

>> and SSRM(I) messages. These messages are not only used to overcome the 45

>> octet message limit but are also used for overlap sending. Consequently a

>> SSRM(C) will not necessarily be expected.

[ranjith]

Agreed. The buffering option makes sense for segmented messages alone. Extending it to overlap signaling will unnecessarily complicate the gateway implementation and also defeats the purpose of overlap signaling. As you suggest, I guess we should restrict the buffering option to segmented messages alone.

>> I suspect that you will wish to limit DPNSS tunnelling to

>> option 1 - otherwise you will need to carry additional information that is

>> normally available from DPNSS layer 2. This needs to be stated.

[ranjith]

Currently, Yes. But you've raised an interesting point. We'll explore the possibility of option 2; unless it complicates the protocol aspects vis-a-vis the advantages.

Thanks for the inputs.

cheers,

- ranjith..

-----Original Message-----

From: Elwell, John [mailto:[email-masked]]

Sent: Tuesday, February 11, 2003 4:59 PM

To: 'Ranjith Mukundan'

Ranjith,

Just a few remarks.

1. DPNSS is no longer published by BT. The latest version (version 7) is

DPNSS[188] published by Oftel sub-committee NICC (Network Interoperability

Consultative Committee). This has also has an internal reference number

ND1301:2001/03. The current URL is:

m>

but this is liable to change (e.g., Oftel will change to Ofcom) and should

not be quoted in any long-term document.

I don't think previous versions (1 to 6) are available any more, but of

course there will be implementations. However, most people will be aware

only of the BTNRs, so it would still be worth mentioning "formerly BTNR

188".

2. If version number is to be carried, then version 7 should be added.

3. For QSIG tunneling over SIP we found that the RFC specifying the MIME

type is insufficient for achieving correct operation in multi-vendor

networks. Therefore in ECMA we are working on an additional specification

that will detail procedures to be adopted at the QSIG-SIP gateway.

4. During this work we found it necessary to specify that a QSIG-SIP gateway

should behave as a transit PBX from the perspective of the QSIG protocol. I

think this was mainly to make sure that all timers worked correctly. You

might wish to explore whether the same statement needs to be made for DPNSS

gateways. For example, by making a gateway behave as a transit PBX, it would

be required to respond with a CIM when a CRM is received, rather than simply

passing on the CRM.

5. This may also have impact on the message buffering option. A gateway may

need to run a timer if it receives EEM(I) to guard against failure to

receive EEM(C).

6. The message buffering option may not be suitable for buffering ISRM(I)

and SSRM(I) messages. These messages are not only used to overcome the 45

octet message limit but are also used for overlap sending. Consequently a

SSRM(C) will not necessarily be expected.

7. For QSIG we are considering two options: option 1 is to tunnel only one

QSIG call over a single SIP dialogue. Option 2 is to tunnel an arbitrary

number of QSIG calls in series and/or in parallel over a semi-permanent SIP

dialogue. Option 2 uses the QSIG call reference to identify the call and the

QSIG channel identification information element to identify the particular

RTP session. I suspect that you will wish to limit DPNSS tunnelling to

option 1 - otherwise you will need to carry additional information that is

normally available from DPNSS layer 2. This needs to be stated.

I hope this is of use to you.

John

John Elwell - Technical Consultant

Tel: +44 (0)115 943 4989

Fax: +44 (0)115 943 4969

e-mail: mailto:[email-masked] <mailto:[email-masked]>

web: http://www.siemens-design-services.com

<http://www.siemens-design-services.com/>

Siemens Communications

Technology Drive, Beeston, Nottingham, NG9 1LA.  England.

"Siemens Communications - a division of Siemens plc,  Registered No: 727817,

England. Registered office: Siemens House, Oldbury, Bracknell, Berkshire,

RG12 8FZ.

-----Original Message-----

To: [email-masked]

understand QSIG.

- ranjith..

-----Original Message-----

From:   Ranjith Mukundan

To:     [email-masked]

Cc:

Hi,

posting WRT

Some specifics:

cheers,

ranjith..

Sipping mailing list

SIP

---

From: "Mark Watson" <[email-masked]>
Date: Wed, 12 Feb 2003 09:10:38 -0000

I can't think of any other telephony signalling protocols which would
warrent MIME encapsulation in SIP either. Service Transparency is only an
issue when it's a peer-to-peer protocol that you are considering (if it's
not peer-to-peer e.g. DSS1, then there's no transparency concept in the
original protocol to be carried over into SIP - every node needs to
understand every feature, in which case a SIP gateway can interwork to
appropriate SIP features or correctly terminate the feature on the telephony
side).
 
National legacy PSTN signalling aside, the only standard public network
signalling is ISUP.
 
The only standard private network signalling systems that I know of are
Q.SIG and DPNSS. Of coure there are lot of proprietary ones, but I don't
think we should consider MIME types for these.
 
...Mark

-----Original Message-----
From: Ranjith Mukundan [mailto:[email-masked]]
Sent: 12 February 2003 03:40
To: Peterson, Jon; Watson, Mark [MOP:EP10:EXCH]; [email-masked]
Subject: RE: [Sipping] QSIG Vs DPNSS MIME

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

>> In any event, as another nit, this document should not define the
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 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,

 

 
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

- 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

Some specifics:

cheers,
ranjith..

---

From: "Mark Ashworth" <[email-masked]>
Date: Wed, 12 Feb 2003 17:07:22 -0000

Ranjith,
 
Seems like a reasonable thing to do. A few comments which I hope are
helpful...
 
1) The discussion of handling segmented information might be clearer if you
were to use the terminology of the DPNSS specification such as Selection
Block/Selection Field and Information Block/Information Field to refer to
the items being manipulated. In the case of the ISRM/SSRM, as others have
already commented, you would need to distinguish between the Supplementary
Information and the Destination Address which make up the Selection Block;
the Supplementary Information can be safely buffered but the Destination
Address needs to be handled according to overlap procedures.
 
2) Using that terminology might make clearer how you propose to perform the
buffering. I think you are proposing to concatenate the Information Fields
from a sequence of messages to assemble a complete Information Block (or
segment thereof if it exceeds your 255 octet limit) with a single message
type octet, although I don't see this stated explicitly. If so, then I think
your example is slightly inaccurate: combining a sequence of five EEMs each
of 45 octets would produce an EEM of 221 octets (as four message type octets
are removed)?
 
3) I'm not sure there is really any need for a version number, since DPNSS
has comprehensive compatibility mechanisms?
 
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

- 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

Some specifics:

cheers,
ranjith..

---

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

Mark,

OK, 1) & 2) seems to be a good suggestion as it would indeed help clarify the buffering mechanism better. Yes, you are right, the example is inaccurate - it would add up to 221 instead of 225.

regarding 3), though the version field would seem apparently redundant (as you've aptly noted the protocol is, spec-wise, perfectly compatible with other versions), we believe that it would help debug the protocol better - esp, when connecting networks implementing different versions. We've known, in the legacy implementations, some debugging issues that cropped up, whilst interwoking issue 4 PBX to an issue 6 PBX. So, we'd suggest that we retain this parameter. But as Mark (Watson) pointed out, the text describing the version field type needs to be made more accurate

cheers,

- ranjith..

-----Original Message-----

From:   Ashworth, Mark [MOP:MA01:EXCH] [mailto:[email-masked]]

Sent:   Wed 2/12/2003 10:37 PM

To:     Ranjith Mukundan

Cc:     [email-masked]

Ranjith,

helpful...

are removed)?

Regards,

Mark.

-----Original Message-----

To: [email-masked]

understand QSIG.

- ranjith..

-----Original Message-----

From:   Ranjith Mukundan

To:     [email-masked]

Cc:

Hi,

posting WRT

Some specifics:

cheers,

ranjith..

SIP