Subject: M3UA Issue 4: Payload Format - poll

From: Lyndon Ong <[email-masked]>
Date: Mon, 17 Sep 2001 15:00:26 -0700 (PDT)

Folks,

I'd like to check on views about the payload
format.  The current spec has Payload 1 and Payload
2, depending on whether or not the Length Ind. 
needs to be added because it contains priority.

The alternative proposal is to have a Payload 3
which is broken out into 4 byte subfields for
OPC, DPC and SIO/Priority/SLS.

We've already had support from Brian and Kurt
for Payload 3 (Javier also), I would like to
get other views on the floor.

Cheers,

L. Ong

__________________________________________________
Terrorist Attacks on U.S. - How can you help?
Donate cash, emergency relief information
http://dailynews.yahoo.com/fc/US/Emergency_Information/

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to [email-masked]

---

From: [email-masked]
Date: Tue, 18 Sep 2001 08:48:38 -0400

Lyndon,

Why isn't my proposed option, forwarded below, included in the data format 
poll that you started yesterday? I think people should at least be allowed 
to vote on it.

Barry Nagelberg

----- Forwarded by Barry Nagelberg/Radisys_Corporation/US on 09/18/01 
08:49 AM -----

[email-masked]
08/17/01 03:45 PM
Please respond to sigtran

        To:     "sigtran" <[email-masked]>
        cc: 
        Subject:        Re: M3UA Issues List

Greg,

Good list! Thanks.

About #4: Format of Routing Label/SIO in DATA message. Status: 
Open
Options: New Protocol Data 3 parameter or just have one choice with all
Routing Label/SIO elements parameterized.

I would like to add a third option: No routing parameters at all. My 
rationale is that M3UA shouldn't deal with or try to specify contents of 
MTP3 data packets, including the routing label. M3UA just forwards them to 

the MTP3-user at the ASP or to the MTP3 layer at the SG.

We talked about this a lot at the bakeoff, among ourselves and with you. 
You put an initial format in v5, and then tried to correct it in v6. But 
according to Kurt and Brian, both versions were incorrect. My feeling is 
that whatever you put in the draft, there will always be some variant, 
somewhere in the world, for which the specified format will be incorrect. 

Furthermore, the routing label is NOT needed by the receiver of the DATA 
message. The originator of the DATA message simply peeks at the routing 
label of the MTP3 packet to determine the correct ASP/SGP to receive the 
message.

Barry Nagelberg
Software Engineer
RadiSys, Corp.
Signaling Products Design Center
[email-masked]
+1-856-642-9229 x237

Lyndon Ong <[email-masked]>
09/17/01 06:00 PM
Please respond to sigtran

        To:     "sigtran" <[email-masked]>
        cc: 
        Subject:        M3UA Issue 4: Payload Format - poll

Folks,

Cheers,

L. Ong

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to 
[email-masked]

---

---

From: Lyndon Ong <[email-masked]>
Date: Wed, 19 Sep 2001 12:10:03 -0700 (PDT)

Well, there has been very underwhelming response
to this poll :o)

To raise the level of debate, then, my current
thought (taking off the chair hat) is that the
SG will need to parse the routing label in any
case and separate out the fields for DPC, OPC,
SIO and SLS, so it seems to me that there is
not much lost in encoding these into 4 byte
fields in the payload and possibly simplifying
the ASP.

Note - this does not mean that the protocol
becomes truly variant-independent, as the SG
and either AS or ASP will still need to know
the format of the point code.  Affected 
Destination in SNMM messages, for example, 
is always 32 bits but its format depends on
whether the point code is ANSI or ITU.

Incorporating priority into the SIO/SLS field
also removes the requirement to have two formats,
with and without the Length Indicator.  The one
format would be 4 bytes longer, of course.

Eliminating the routing label, as Barry suggests,
seems like it would just hide the problem in the
Protocol Data subfield.

Comments?

Cheers,

Lyndon

> 
> 
> ---
> You are currently subscribed to sigtran as:
> [email-masked]

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 19 Sep 2001 16:20:31 -0500

Lyndon,

I agree with your statements.  The unpacked RL
does permit an ASP and the ASP/AS interface to
be protocol variant neutral, although the AS
itself will naturally need to know the format
within the unpacked fields after it receives
them and to generate them in the first place.

This would also make M3UA consistent with SUA
in regard to address handling.

Barry does have one point: the NI, DPC and SI
need not always be sent from SG to ASP, because
they are often implied in RC.  If these are made
independent fields, they could be optionally
included in the DATA message.  For many DATA
messages it could actually reduce the length of
the resulting message rather than increasing the
length (if that matters).

--brian

Lyndon Ong wrote:               (Wed, 19 Sep 2001 12:10:03)
> You are currently subscribed to sigtran as: [email-masked]

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

---

From: "Schantz, John" <[email-masked]>
Date: Wed, 19 Sep 2001 14:23:42 -0700

Well, I guess you wanted a response (I finally got home).

Why can't we adopt DATA 2, it has the extra byte that Japan needs.  It
would not hurt to always carry this extra byte around.  The
implementation will always have to know what protocol format is used for
the messages.

I don't see any justification for a DATA type that has reformats the MTP
parameters (you may miss some since some networks "hide" info in some
the spare bits).  The payload will still have the original format in
ISUP or SCCP & TCAP.  Reformatting is a waste of time and processing.

John

> -----Original Message-----
> From: Lyndon Ong [mailto:[email-masked]]
> Sent: Wednesday, September 19, 2001 2:10 PM
> To: sigtran
> Subject: Re: M3UA Issue 4: Payload Format - poll
> 
> 
> You are currently subscribed to sigtran as: [email-masked]

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 19 Sep 2001 21:32:14 -0500

John,

> the spare bits).

All bits are represented in the MTP-TRANSFER primitive parameters.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

---

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Thu, 20 Sep 2001 18:26:22 +0200

Hi John, 

Answers below...

> From: Schantz, John [mailto:[email-masked]]
> Sent: Wednesday, September 19, 2001 11:24 PM
> To: sigtran
> Subject: RE: M3UA Issue 4: Payload Format - poll
> 
> 

The process of reformatting will take more or less time depending on the implementation, but as you have to copy them to your memory space, it will only change the way you copy them to and from.

	- When an SS7 message comes from the SS7 network, at the SG, the parameters can be passed in an unpacked way (depends on the implementation). Therefore the SG wouldn't have to unpack before re-formatting them into the payload 3. It could be a straightforward process.
	- It is implementation dependant which format the SS7 application is expecting from MTP3, so that this criteria is no valid for the election.

Besides this I see some more advantages:

	- Managing different kinds of payload types is more complicated that only one. Implementation gets more complicated
	- There would be no need to define new payload types to conform to new national variants, since the payload 3 is general enough.

From the point of view of standards, and not from particular application's, I see the payload 3 as the best choice... :-)

Cheers // Javier.

> [email-masked]

---

---

From: Dan Brendes <[email-masked]>
Date: Thu, 20 Sep 2001 13:15:55 -0400

Eliminating the routing label completely will never work from the perspective of
the SG.  For the ASP -> SG direction the SG would not have enough information to
re-build the MTP3 routing label so that the received MSU can be passed from M3UA
-> Interworking Function -> MTP3 layer on another link within the SG.  There may
be situations where the SG could use the RC of the DATA message to build the
MTP3 hdr, but it doesn't work for every type of routing key (doesn't work for a
DPC only routing key from SG -> ASP, on traffic in the asp->sg direction the SG
knows which OPC to use by looking at the DPC of the RC, but has no idea where
the MSU is headed).

As far as payload data format 1 (starts at mtp3 routing label), format 2 (length
byte + mtp3 routing label), or format 3 (SG breaks routing label into individual
fields) goes
- I don't think you are going to reach agreement on just 1 format.  There are
going to be implementations that want format 1 because they already have a
functioning mtp3 stack and just want an ip/sctp/m3ua transport.  Other
implementations have the mtp3 stack and also need the mtp2 length field.  And
other course other implementations want everything parameterized.
- Which payload format to use should be configurable on a per routing key basis.
There should be appropriate error codes added to the MTP3 protocol.  For static
configurations, it should be added as a configurable field at both the SG and
ASP.
- If you feel like you have to pick one, I vote for format 1.  The extra
time/processing is eliminated in situations where it is not needed.  The ASP
side needs to be aware of the NA for each RC anyway.  The NA implies how the
MTP3 layer is formatted.  Hence the ASP should be able to get the info it needs
without the SG doing all the dirty work for it.

Lyndon Ong <[email-masked]> on 09/19/2001 03:10:03 PM

Please respond to [email-masked]

To:   "sigtran" <[email-masked]>
cc:    (bcc: Dan Brendes/Raleigh/TEKELEC)
Subject:  Re: M3UA Issue 4: Payload Format - poll

Comments?

Cheers,

Lyndon

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to
[email-masked]

---

---

From: Lyndon Ong <[email-masked]>
Date: Thu, 20 Sep 2001 13:31:54 -0700 (PDT)

Hi Dan,

-- It seems to me that we should be trying to reduce
 the number of formats if we can, to help with
 interoperability.  The preference would be 1 if 
 we could agree on which (big if).

-- Wouldn't Payload 2 be more generic than Payload 1,
 since Payload 1 doesn't include the length byte?

Cheers,

Lyndon

---

---

From: [email-masked]
Date: Fri, 21 Sep 2001 07:35:52 -0400

resending...

Dan,

Lyndon mistated my suggestion. I did not suggest that we "eliminate" the 
routing label.

I suggested that in the DATA message we merely transmit the MTP-TRANSFER primitive as it was composed by the MTP3 layer, without extracting and duplicating 
any of the routing information. 

Barry Nagelberg
Software Engineer
RadiSys, Corp.

Dan Brendes <[email-masked]>
09/20/01 01:15 PM
Please respond to sigtran

Eliminating the routing label completely will never work from the 
perspective of
the SG.  For the ASP -> SG direction the SG would not have enough 
information to
re-build the MTP3 routing label so that the received MSU can be passed 
from M3UA
-> Interworking Function -> MTP3 layer on another link within the SG. 
There may
be situations where the SG could use the RC of the DATA message to build 
the
MTP3 hdr, but it doesn't work for every type of routing key (doesn't work 
for a
DPC only routing key from SG -> ASP, on traffic in the asp->sg direction 
the SG
knows which OPC to use by looking at the DPC of the RC, but has no idea 
where
the MSU is headed).

As far as payload data format 1 (starts at mtp3 routing label), format 2 
(length
byte + mtp3 routing label), or format 3 (SG breaks routing label into 
individual
fields) goes
- I don't think you are going to reach agreement on just 1 format.  There 
are
going to be implementations that want format 1 because they already have a
functioning mtp3 stack and just want an ip/sctp/m3ua transport.  Other
implementations have the mtp3 stack and also need the mtp2 length field. 
And
other course other implementations want everything parameterized.
- Which payload format to use should be configurable on a per routing key 
basis.
There should be appropriate error codes added to the MTP3 protocol.  For 
static
configurations, it should be added as a configurable field at both the SG 
and
ASP.
- If you feel like you have to pick one, I vote for format 1.  The extra
time/processing is eliminated in situations where it is not needed.  The 
ASP
side needs to be aware of the NA for each RC anyway.  The NA implies how 
the
MTP3 layer is formatted.  Hence the ASP should be able to get the info it 
needs
without the SG doing all the dirty work for it.

Comments?

Cheers,

Lyndon

---

---

From: Dan Brendes <[email-masked]>
Date: Fri, 21 Sep 2001 08:02:09 -0400

Barry -
Thanks for clearing that up.
I guess you and I are both in agreement and favor protocol data 1.

[email-masked] on 09/21/2001 07:35:52 AM

resending...

Dan,

I suggested that in the DATA message we merely transmit the MTP-TRANSFER
primitive as it was composed by the MTP3 layer, without extracting and
duplicating
any of the routing information.

Barry Nagelberg
Software Engineer
RadiSys, Corp.

Comments?

Cheers,

Lyndon

---

---

---

From: [email-masked]
Date: Fri, 21 Sep 2001 08:36:28 -0400

Dan,

No, I don't support protocol data 1. My whole point is that NO protocol 
data structure should be defined by Sigtran. The M3UA spec should not 
attempt to define the Signal Unit format. That is the job of ITU, ANSI, 
etc. Our attempts to define (redefine?) the SU structure have not 
succeeded.

My suggestion is that the definition of the DATA msg simply reflect what 
is written in section 1.3.2.1 (Support for the Transport of MTP3-User Messages):

"The MTP-TRANSFER primitive information is encoded as in MTP3-User 
messages.  In this way, the User Part messages received from the SS7 
network by the SGP are not re-encoded into a different format for transport between the M3UA peers."

Barry Nagelberg

09/21/01 08:02 AM

Dan,

Barry Nagelberg
Software Engineer
RadiSys, Corp.

Comments?

Cheers,

Lyndon

---

---

From: Greg Sidebottom <[email-masked]>
Date: Fri, 21 Sep 2001 15:24:09 -0400

Hi Barry,

I really think you and Dan are saying the same thing.  Would I be incorrect
to interpret your input as supporting Protocol Data 1 format without an
description of the ITU and ANSI Routing Label examples?

I say this because the Signal Unit data structure shown in Protocol Data 1
of M3UA was never intended to be a re-definition of the SS7 format.  It was
always an attempt to describe the unchanged Routing Label format in IETF
terms for the ITU and ANSI SS7 examples and is, at least in intent, totally
consistent with your quoted text from 1.3.2.1.

Of course I would agree that this attempt has not always been successful
(understatement of the day)!   It was always very tricky to describe and
explain why the format looks so messy in the IETF terms.  (Some people still
remain convinced that it is incorrect).  In the Issue 9 text it looks a
little better as the ITU example was clarified based on the e-mail from
Hanns-Juergen on Sept 10th (i.e., that ITU Q.708 (03/99) no longer contains
the zone/region concept).

I could certainly live with removing the examples if that would progress
things although personally I am now leaning more and more every day to
Payload Data 3!

Cheers,

    Greg

----- Original Message -----
From: <[email-masked]>
To: "sigtran" <[email-masked]>
Sent: Friday, September 21, 2001 8:36 AM
Subject: Re: M3UA Issue 4: Payload Format - poll

> You are currently subscribed to sigtran as: [email-masked]

---

---

From: [email-masked]
Date: Fri, 21 Sep 2001 16:13:06 -0400

Hi Greg,

Is this a trick question? :<) 

I don't like Data 1 or 2 because they DO attempt to describe the ITU and 
ANSI routing labels.

Like you, I could live with Data 3, because it:

a)  is SS7 variant-neutral and 
b) would save processing time by allowing the recipient to avoid having to 
repeat the parsing of the real SS7 RL that the sender must do.

Barry Nagelberg
Software Engineer
RadiSys, Corp.

Greg Sidebottom <[email-masked]>
09/21/01 03:24 PM
Please respond to sigtran

Hi Barry,

I really think you and Dan are saying the same thing.  Would I be 
incorrect
to interpret your input as supporting Protocol Data 1 format without an
description of the ITU and ANSI Routing Label examples?

I say this because the Signal Unit data structure shown in Protocol Data 1
of M3UA was never intended to be a re-definition of the SS7 format.  It 
was
always an attempt to describe the unchanged Routing Label format in IETF
terms for the ITU and ANSI SS7 examples and is, at least in intent, 
totally
consistent with your quoted text from 1.3.2.1.

Of course I would agree that this attempt has not always been successful
(understatement of the day)!   It was always very tricky to describe and
explain why the format looks so messy in the IETF terms.  (Some people 
still
remain convinced that it is incorrect).  In the Issue 9 text it looks a
little better as the ITU example was clarified based on the e-mail from
Hanns-Juergen on Sept 10th (i.e., that ITU Q.708 (03/99) no longer 
contains
the zone/region concept).

Cheers,

    Greg

----- Original Message -----
From: <[email-masked]>
To: "sigtran" <[email-masked]>
Sent: Friday, September 21, 2001 8:36 AM
Subject: Re: M3UA Issue 4: Payload Format - poll

---

---

---

From: "Schantz, John" <[email-masked]>
Date: Fri, 21 Sep 2001 13:26:18 -0700

In the long run, Data 3 is NOT variant neutral and it does not save
time.  When you pass the message onto the user or into the SS7 network,
its format must return to the SS7 variant.  So what have you gained?
You LOST time formatting Data 3 at the sending node and LOST time at the
receiving node to "undo" the formatting.  LOST time does not equal saved
processing time.

John

> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, September 21, 2001 3:13 PM
> To: sigtran
> > is written in section 1.3.2.1 (Support for the Transport of 
> MTP3-User
> Messages):
> >
> > MTP3 hdr, but it doesn't work for every type of routing key 
> (doesn't 
> work
> > for a
> > going to be implementations that want format 1 because they 
> already have 
> a
> > - Which payload format to use should be configurable on a 
> per routing 
> key
> > basis.
> > configurations, it should be added as a configurable field 
> at both the 
> SG
> > and
> > ASP.
> > MTP3 layer is formatted.  Hence the ASP should be able to 
> get the info 
> it
> > needs

---

---

From: [email-masked]
Date: Fri, 21 Sep 2001 16:35:29 -0400

John,

I am assuming that the Data 3 parameters are in addition to the full 
MTP-TRANSFER primitive. The receiver discards the Data 3 parameters after 
reading them, and doesn't have to reformat anything.

Barry Nagelberg
Software Engineer
RadiSys, Corp.

"Schantz, John" <[email-masked]>
09/21/01 04:26 PM
Please respond to sigtran

John

---

---

From: "Gradischnig, Klaus" <[email-masked]>
Date: Fri, 21 Sep 2001 15:39:38 -0500

Well, I could live with Data 3 -- though, strictly speaking, it violates
Q.701 as it restricts possible "national" routing label formats.

Klaus

> Sent: September 21, 2001 4:26 PM
> To: sigtran
> [email-masked]

---

---

From: Amish Chana <[email-masked]>
Date: Mon, 24 Sep 2001 13:47:21 +0100

Barry,

>reading them, and doesn't have to reformat anything.

What do you expect the receiving M3UA to do with the DPC, OPC, SIO and SLS?

Amish

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

---

---

From: [email-masked]
Date: Mon, 24 Sep 2001 10:43:28 -0400

John is right about the Data msg receiver having to reformat. I thought 
that Data 3 RL parameters were IN ADDITION to the MTP3-TRANSFER primitive. 
However, after looking again at Brian's Data 3 proposal from August 9, I 
now realize that this is not the case.

I would support Data format 3 only if the RL parameters were IN ADDITION 
to the complete MTP3-TRANSFER primitive.

Barry Nagelberg

John

---

---

---

From: Lyndon Ong <[email-masked]>
Date: Mon, 24 Sep 2001 11:16:43 -0700 (PDT)

Folks,

Let's try and clarify Payload 3, then.

The MTP-Transfer primitive from Q.701 lists
the following contents:
OPC
DPC
SLS
SIO
User Data

User Data references section 2.3.8 of Q.703,
which describes the Signaling Information
Field, which includes the routing label 
(DPC, OPC, SLS).

If payload 3 follows the format of the MTP-
Transfer primitive it would have
OPC
DPC
SLS/SIO/(priority)
User Data

where User Data provides the SIF.  Is that
what people need for payload 3?

Cheers,

Lyndon

__________________________________________________
Do You Yahoo!?
Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger. http://im.yahoo.com

---

---

From: [email-masked]
Date: Mon, 24 Sep 2001 15:52:38 -0400

Lyndon,

We must be careful here. I think your interpretation is wrong. There is a 
disconnect in the ITU documents, which leaves an opening for different 
interpretations.

Table 1/Q.701 refers the reader to 2.3.8/Q.703 for a definition of "User 
Data". However 2.3.8/Q.703 refers to "Signalling Information Field", and 
doesn't mention "User Data" at all.

You are saying that "User Data" includes the entire SIF, but both Brian, 
in his Data 3 proposal from July 27, most other interpretations that I 
have seen, say that "User Data" includes only that part of the SIF that 
comes AFTER the routing label. For example, In Brian's proposal for Data 
format 3, the last field is Protocol Data, defined as:

 "a byte string of MTP-User information from the original SS7 message 
starting with the first byte of the original SS7 message following the 
Routing Label."

Actually, after looking at this a second time I think that Brian is 
correct and that you and John are not. For ease of transmission to the MTP layers, we should stick with Brian's 
interpretation. Thus format 3 should be

OPC
DPC
SLS/SIO/(priority)
User Data (starting with the first byte of the original SS7 message 
following the Routing Label)

Barry Nagelberg

09/24/01 02:16 PM

Folks,

Cheers,

Lyndon

---

---

From: Lyndon Ong <[email-masked]>
Date: Fri, 21 Sep 2001 12:58:52 -0700 (PDT)

Hmm, maybe that's a solution:

- 1 format with message data encapsulated without
format change (i.e., payload 1)
- 1 format with opc, dpc, sls, sio and priority
split out into identified subfields.

Lyndon
--- Greg Sidebottom <[email-masked]> wrote:
> > is written in section 1.3.2.1 (Support for the
> Transport of MTP3-User
> Messages):
> >
> > network by the SGP are not re-encoded into a
> different format for
> transport between the M3UA peers."
> >
> > Barry Nagelberg
> >
> >
> >
> >
> >
> > - If you feel like you have to pick one, I vote
> for 
=== message truncated ===

---

---

From: Ashley Clementi <[email-masked]>
Date: Tue, 25 Sep 2001 13:12:15 +0800

Hi People

From the couple of MTP3 api's I have seen and used, when data pops out the
top of MTP 3 at the SG or out the bottom of ISUP/SCCP/... at the ASP the
routing label information has not been encoded as though it was "on the
wire". It has already been decoded. The same is true for injecting data into
these few stack APIs, where individual parameters have been required rather
than a pre-encoded label.

I have then had to implement methods to encode this in ITU or ANSI format to
then transmit across M3UA and decode it on the other side to push into the
stack. I have even had problems where my interpretation of ITU routing label
encoding was different from another implementors causing our draft M3UA
implementations to be incompatible (and I still don't understand exactly who
is right).

I have thought, since draft 2, that a single well defined ITU and ANSI
independant format should be used for M3UA.

Ash 

-----Original Message-----
From: Lyndon Ong [mailto:[email-masked]]
Sent: Saturday, September 22, 2001 3:59 AM
To: sigtran
Subject: Re: M3UA Issue 4: Payload Format - poll

Lyndon

__________________________________________________
Do You Yahoo!?
Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger.
http://im.yahoo.com

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to
[email-masked]

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 25 Sep 2001 01:26:30 -0500

Lyndon,

A number of those preferring 1/2 said that they could
"live" with 3.  Those preferring 3 do so because they
cannot "live" with the compatibility issues caused by
the 1/2 approach.

I propose that we use 3 as the starting point for a
single format and build from there.

--brian

Lyndon Ong wrote:               (Mon, 24 Sep 2001 18:08:09)
>
> Folks,
> 
> Sending again, first time disappeared...
> 
> We seem to be pretty evenly divided into 
> two solutions:
> 
> 1) payload 1/2, where the contents of the
> MTP message are send as the payload in M3UA,
> starting at either the SIO (1) or the LI (2).
> (I would like to cut this down to a single
> format if possible, either (1) or (2)).
> 
> 2) payload 3, where the DPC, OPC and SIO/SLS/Priority
> are broken out into separate 4-byte subfields and
> then the remaining User Data forms the rest of
> the payload.
> 
> Ideally we would agree on one format and agree
> to always support this, but we can't seem to agree, 
> so we need to consider two formats and how to 
> support this.
> 
> Possible actions:
> -- leave this up to configuration of the two endpoints
> -- make this part of registration
> -- add some kind of error procedure to indicate
>    when the remote end does not support the format
>    you are sending
> 
> Comments?  Let's try to clean this up by Wednesday
> so it can go into M3UA version 9.
> 

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

---

From: [email-masked]
Date: Tue, 25 Sep 2001 08:13:29 -0400

Lyndon,

I agree with Brian. Let's pick just one and go with it. 

Actually, my unconfirmed (and not yet recounted) tally indicates the 
following poll results:

Format 1/2:  John, Dan   - 25%
Format 3:      Ken, Brian, Barry, Ashley, Klaus, Kurt    - 75%

Barry Nagelberg

"Brian F. G. Bidulock" <[email-masked]>
09/25/01 02:26 AM
Please respond to sigtran

Lyndon,

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

---

---

From: Greg Sidebottom <[email-masked]>
Date: Tue, 25 Sep 2001 14:48:57 -0400

Hi Ashley, (or Kurt or Brian ...)

I have a question as to how the rest of the MTP3 message data (i.e., User
Protocol Data) is encoded on these mtp3 api's.  Kurt (and others I think)
have mentioned this point about the SIO / Routing Label and I accept this to
be compelling.  I'm just curious as to whether there is a difference between
the various formats 1, 2 and 3 with respect to the message after the Routing
Label.   Is it already encoded as per the MTP3-User's version/variant format
and is it "as on the wire"?  I would assume so but I have no experience with
it.  Note: I'm not implying that we need to specify the format of the User
Protocol Data in M3UA document - I'm just curious!

Cheers,

    Greg

--- Original Message -----
From: "Ashley Clementi" <[email-masked]>
To: "sigtran" <[email-masked]>
Sent: Tuesday, September 25, 2001 1:12 AM
Subject: RE: M3UA Issue 4: Payload Format - poll

---

---

From: Greg Sidebottom <[email-masked]>
Date: Tue, 25 Sep 2001 14:59:12 -0400

resending again - the mailer does not seem to like me today  2:^(

----- Original Message -----
From: "Greg Sidebottom" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, September 25, 2001 11:58 AM
Subject: Re: M3UA Issue 4: Payload Format - poll

> Greetings,
>
> Well, I personally can also "live with" the Payload 3 format, so I'll
> finally add myself to that camp.  I've never really agreed that it is
> variant/version independent but I think the advantage of a single
> generalized format is compelling enough.
>
> BTW I think Javier also has expressed support on the list for the Payload
3
> format.
>      Greg Sidebottom
> Sent: Tuesday, September 25, 2001 8:13 AM

---

---

From: Lyndon Ong <[email-masked]>
Date: Tue, 25 Sep 2001 12:49:22 -0700 (PDT)

Folks,

Well, we seem to be moving towards payload 3,
choosing a single parameter format at the
expense to some of extra processing.  I appreciate
people being willing to give a bit to get the
issue resolved (assuming it's resolved!)

Unless people have a major objection to this,
why don't we use payload 3 as the single format
in M3UA v9 and remove the descriptions of
the ANSI, ITU etc. formats accordingly.

That will help the editors to get v9 out,
targeting end of the month.

Cheers,

L. Ong

--- Greg Sidebottom <[email-masked]> wrote:
> [email-masked]
> [email-masked]

---

---

From: Greg Sidebottom <[email-masked]>
Date: Tue, 25 Sep 2001 13:41:15 -0400

resending ...

----- Original Message -----
From: "Greg Sidebottom" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, September 25, 2001 11:58 AM
Subject: Re: M3UA Issue 4: Payload Format - poll

3

---

---

From: Greg Sidebottom <[email-masked]>
Date: Tue, 25 Sep 2001 11:58:13 -0400

Greetings,

BTW I think Javier also has expressed support on the list for the Payload 3
format.

Cheers,

     Greg Sidebottom

----- Original Message -----
From: <[email-masked]>
To: "sigtran" <[email-masked]>
Sent: Tuesday, September 25, 2001 8:13 AM
Subject: Re: M3UA Issue 4: Payload Format - poll

---

---

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Wed, 26 Sep 2001 09:22:10 +0200

Hi, 

Thanks Greg !!!  That's right I've also supported payload 3 in several ocassions, and I do it right now again.  :-)

Cheers// Javier

> From: Greg Sidebottom [mailto:[email-masked]]
> Sent: Tuesday, September 25, 2001 8:59 PM
> To: sigtran
> Subject: Fw: M3UA Issue 4: Payload Format - poll
> 
> 

---

---

From: Kurt Kite <[email-masked]>
Date: Wed, 26 Sep 2001 10:50:15 -0500

Hi Greg,

For the MTP3 APIs I have worked with the user data is encoded per the MTP3-User's
version/variant, as you have assumed.

/Kurt

Greg Sidebottom wrote:

> You are currently subscribed to sigtran as: [email-masked]

---