I'm going to be reviewing our work plan this weekend and attempting to lay
out a detailed schedule of issues to solve between now and July, just to
establish priorities if necessary. Even without doing this I suspect we
don't have time for a civil war over the SDP vs. H.245 issue, so I'm going
to swallow my architectural principles and make the following proposal:
Which method of expression is used will be a property of the MG, either
discoverable by the MGC through an audit or …
[View More]administratively defined. MGs
will use either H.245-based descriptors or SDP-based descriptors -- the
control protocol is indifferent between them.
If this is too drastic, the terms can be negotiated, but can we accept the
principle of willingness to allow either protocol to be used as the basis
for termination descriptors?
Tom Taylor
E-mail: taylor(a)nortelnetworks.com (internally Tom-PT Taylor)
Tel.: +1 613 736 0961 (ESN 396-1490)
FAX: same number by prior arrangement (manual answer).
[View Less]
Hi,
H.323 V1 and V2 endpoints correctly assume that octet 3a is not present since
H.225.0 states that it shall not be. Therefore there are endpoints that don't
check for the extension bit of octet 3 (i.e. assume it is 1). I agree that it
is useful to forward octet 3a but backward compatibility must be met.
Kaynam
Rich Bowen <rkbowen(a)CISCO.COM> on 05/07/99 03:49:54 PM
Please respond to Mailing list for parties associated with ITU-T Study Group 16
<ITU-SG16(a)mailbag.…
[View More]cps.intel.com>
To: ITU-SG16(a)mailbag.cps.intel.com
cc: (bcc: Kaynam Hedayat/PicTel)
Subject: Re: caller ID and implementer's guide
Glen, others,
I also would support the proposal to allow octet 3a. We have
had requests from customers to allow this information.
Not knowing about APC-1527, I also submitted a contribution to
allow octet 3a (D-264), with proposed text indicating that gateways
"should" forward this information as received from the SCN. As
Glen has indicated, however, we need to look further into
interoperability issues.
Regards,
Rich
--------------------------------------------------------------------
Richard K. Bowen Cisco Systems, Inc.
rkbowen(a)cisco.com Research Triangle Park, NC
--------------------------------------------------------------------
Karl.Klaghofer(a)ICN.SIEMENS.DE wrote:
>
> Glen and others,
>
> It was a mistake to exclude the octet 3a in H.225.0 (v1 and v2) Calling
> party number IE. It has led to interoperability problems with the SCN in
> the past (where octet 3a is used) !
> Now, it is time to fix this error as discussed in the Monterey Rapporteuts
> meeting in February (i.e. for H.225.0v3 but also for H.225.0v2 via
> Implementors Guide !). There may be procucts already planning on that
> announced correction.
>
> An endpoint B - not supporting octet 3a of Calling Party Number Information
> element - should treat this situation as a "non-mandatory information
> element content error". The reaction to such an type of error shall be:
> * Take actions on the SETUP received and on all the information
> elements that are recognized and have valid contents; i.e. ignore only the
> Calling party Number IE
> * A STATUS may optionally be returned with Cause #100.
>
> Refer also to Q.931 clause 5.8.7.2 (which should applicable also to H.225.0,
> since H.225.0 is so much based on the Q.931).
>
> So, if such an endpoint B receives an octet 3a in Calling party Number set
> to "presentation allowed", all that happens is that the Number would not be
> displayed at B.
> But for the really critical case where the octet 3a is received by such an
> endpoint B being set to "presentation restrictet", we have even the behavier
> we intend, namely NOT to display the number to the endpoint B (since the
> whole IE should be ignored anyway).
>
> A miscoded optional Information element should never lead to a clearing of
> the call !
>
> Regards,
> Karl
> ------------------------------------------------
> Karl Klaghofer, Siemens AG, Dpmt. ICN IB NL D1
> Hofmannstr. 51, D-81359 Munich, Germany
> Tel.: +49 89 722 31488, Fax.: +49 89 722 37629
> e-mail: karl.klaghofer(a)icn.siemens.de
>
> > -----Ursprüngliche Nachricht-----
> > Von: Glen Freundlich [SMTP:ggf@lucent.com]
> > Gesendet am: Donnerstag, 6. Mai 1999 22:11
> > An: ITU-SG16(a)mailbag.cps.intel.com
> > Betreff: caller ID and implementer's guide
> >
> > At the Monterey meeting we discussed the possibility of an addition to
> > the Implementer's Guide to support caller ID features (APC-1527).
> > H.225.0 V2 (and V1) forbids the use of octet 3a in the Calling Party
> > Number IE (and also specifies that the octet 3 extension bit shall be
> > set to 1). The proposal calls for removing the restriction through the
> > Implementer's Guide. (See also the meeting report in APC-1554b.)
> >
> > Fixing this brings up the possibility of interoperability problems with
> > existing products. Please respond if you think this change will be a
> > problem. You can respond to me individually, rather than to the entire
> > list, if you prefer.
> >
> > Thanks,
> > Glen
> >
> >
> > --
> > Glen Freundlich ggf(a)lucent.com
> > Lucent Technologies office: +1 303 538 2899
> > 11900 N. Pecos fax: +1 303 538 3907
> > Westminster, Colorado 80234 USA
[View Less]
Glen, others,
I also would support the proposal to allow octet 3a. We have
had requests from customers to allow this information.
Not knowing about APC-1527, I also submitted a contribution to
allow octet 3a (D-264), with proposed text indicating that gateways
"should" forward this information as received from the SCN. As
Glen has indicated, however, we need to look further into
interoperability issues.
Regards,
Rich
--------------------------------------------------------------------
…
[View More]Richard K. Bowen Cisco Systems, Inc.
rkbowen(a)cisco.com Research Triangle Park, NC
--------------------------------------------------------------------
Karl.Klaghofer(a)ICN.SIEMENS.DE wrote:
>
> Glen and others,
>
> It was a mistake to exclude the octet 3a in H.225.0 (v1 and v2) Calling
> party number IE. It has led to interoperability problems with the SCN in
> the past (where octet 3a is used) !
> Now, it is time to fix this error as discussed in the Monterey Rapporteuts
> meeting in February (i.e. for H.225.0v3 but also for H.225.0v2 via
> Implementors Guide !). There may be procucts already planning on that
> announced correction.
>
> An endpoint B - not supporting octet 3a of Calling Party Number Information
> element - should treat this situation as a "non-mandatory information
> element content error". The reaction to such an type of error shall be:
> * Take actions on the SETUP received and on all the information
> elements that are recognized and have valid contents; i.e. ignore only the
> Calling party Number IE
> * A STATUS may optionally be returned with Cause #100.
>
> Refer also to Q.931 clause 5.8.7.2 (which should applicable also to H.225.0,
> since H.225.0 is so much based on the Q.931).
>
> So, if such an endpoint B receives an octet 3a in Calling party Number set
> to "presentation allowed", all that happens is that the Number would not be
> displayed at B.
> But for the really critical case where the octet 3a is received by such an
> endpoint B being set to "presentation restrictet", we have even the behavier
> we intend, namely NOT to display the number to the endpoint B (since the
> whole IE should be ignored anyway).
>
> A miscoded optional Information element should never lead to a clearing of
> the call !
>
> Regards,
> Karl
> ------------------------------------------------
> Karl Klaghofer, Siemens AG, Dpmt. ICN IB NL D1
> Hofmannstr. 51, D-81359 Munich, Germany
> Tel.: +49 89 722 31488, Fax.: +49 89 722 37629
> e-mail: karl.klaghofer(a)icn.siemens.de
>
> > -----Ursprüngliche Nachricht-----
> > Von: Glen Freundlich [SMTP:ggf@lucent.com]
> > Gesendet am: Donnerstag, 6. Mai 1999 22:11
> > An: ITU-SG16(a)mailbag.cps.intel.com
> > Betreff: caller ID and implementer's guide
> >
> > At the Monterey meeting we discussed the possibility of an addition to
> > the Implementer's Guide to support caller ID features (APC-1527).
> > H.225.0 V2 (and V1) forbids the use of octet 3a in the Calling Party
> > Number IE (and also specifies that the octet 3 extension bit shall be
> > set to 1). The proposal calls for removing the restriction through the
> > Implementer's Guide. (See also the meeting report in APC-1554b.)
> >
> > Fixing this brings up the possibility of interoperability problems with
> > existing products. Please respond if you think this change will be a
> > problem. You can respond to me individually, rather than to the entire
> > list, if you prefer.
> >
> > Thanks,
> > Glen
> >
> >
> > --
> > Glen Freundlich ggf(a)lucent.com
> > Lucent Technologies office: +1 303 538 2899
> > 11900 N. Pecos fax: +1 303 538 3907
> > Westminster, Colorado 80234 USA
[View Less]
On behalf of Espen and myself I will post this (delayed) reply to
Douglas
Best regards Lill
--
Lill Kristiansen,
Ericsson Internet Development, XoIP (former MMTS)
Billingstad, Norway
email: etolkr(a)eto.ericsson.se
- -
Hi,
Thanks for clarifying this. We're basicly happy with an agreement that
mobility issues more work.
> It is not enough to just say "roaming"!
> Douglas
Fully support this statement!
There are (at least) two different aspects of mobility:
Terminal mobility - A terminal …
[View More]communicating independent of location
User mobility - The user receives his phone service independent of of
terminal and underlying network (domain).
In addition we have the discrete vs continuous cases.
See Tiphon WG7 for more definitions
In wireless one mostly talk about the continuous case (aka handover).
Discrete user mobility may very easy be achieved by user oriented
E.164 numbers and RAS messages
Discrete terminal mobility is often out of scope of the application
(may be done by Mobile IP or other means)
Digression:
In case an H.323 E.164 number is assigned to a terminal/plug in the
wall,
(i.e. similar to the PSTN case) then you place a call towards this fixed
place. The fact that my phusical phone can be plugged in also at another
house, does not offer 'mobility', as the calls will still be charged
to the plug in the wall. So even though is is a sort of 'discrete
terminal mobility', it is not what we're after. (and why the UPT concept
was invented)
end digression
However in most cases with terminal mobility the continuous/wireless
case is the interesting one. We consider wireless to be a very important
and radio specific access technology, outside the scope and competence
of
sg16 and Tiphon.
Here we're talking about user mobility, as we hope terminal mobility can
be achieved with other/access techniques.
But the point is, when we are introducing "user mobility" between the
Annex G domains, we should make sure that any supplementary services
the user subscribes to are also reachable. This includes both services
invoked by the service provider and terminal invoked services.
For the service provider invoked services one can see solutions as
1. Downloading a service profile from home domain to the visited domain
This is done in GSM networks, and requires all services to be
standardized.
2. Route the call signaling channel through the home domain
This allows proprietary services within the domain to be executed
anywhere. I.e. one obtain service mobility, and virtual home environment
There is danger of "tromboning" which is the reason it hasn't been
introduced in switched networks, but as H.323 uses a packet network,
the tromboning applies only to the signaling, which in many cases might
not be problematic.
See also some comments below
Espen and Lill
-----Original Message-----
> From: Douglas Clowes [mailto:dclowes@ozemail.com.au]
> Sent: 27. april 1999 01:01
> To: Espen Skjæran
> Cc: ITU-SG16(a)mailbag.cps.intel.com
> Subject: Re: Annex G and Roaming?
>
> Espen,
> It all depends on what you mean by "roaming of users between different
> domains".
> Annex G does support some functionality for some favours of roaming,
but
> requires further development - particularly in how to use these
aspects
> between domains.
>
> Comments below.
> At 14:54 1999-04-23 +0200, Espen Skjæran wrote:
> >Hi all,
> >
> >I've recently heard (unofficially) that some claim Annex G
> >(APC-1546/TD-20 in Monterey)
> >also to support roaming of users between different domains.
> >
> >If this is true, I wonder how.
> >
> >I can see how the AccessRequest/ValidationRequest might be sent from
a
> >visiting domain to the home domain for per-call authorization. While
> >this might work in simple cases, it will hinder the use of services
> >while roaming.
> Per call authorization permits a user from one domain to use gateway
> equipment from a second domain, to make calls to through a gateway in
a
> third domain. There could even be a fourth domain present as a
clearinghouse.
>
> I don't know what you mean by "hinder the use of services while
roaming" in
> this context. Perhaps you could elaborate please.
This is the VAS/supplementary services issue mention above
> >I can not either see any mechanism to authorize the roaming
> >registration.
> Registration is a completely different issue, and I don't see support
for
> it in Annex G. Perhaps an RRQ with a remote e.164 or IP address could
be
> issued to the home domain, by the terminal or host gatekeeper?
> >I am sorry to post based on "rumors", but this may change the scope
of
> >Annex G significally, and I worry if this might affect future work on
> >roaming. As Tiphon has just started their work on roaming by
analysing
> >existing roaming techniques in telco and datacom/IETF work,and not
yet
> >reached any conclusion, it seems premature to use annex G
> >in its current state for roaming.
> These concepts will have to be developed in parallel. There is more
than
> one "type" or "roaming", and different people will think of different
> things when that word is used.
Maybe have a look at Tiphon 12TD088 for an overview of existing
techniques
for mobility and roaming in datacom and telecom
> Some people think of terminal mobility,
yes, and often the continuous/wireless one
> while others think of mobile IP.
> Neither of these apply to the mobile user on public ingress gateways
> depicted above, but they are no less valid and need to be considered.
If we compare to the terminology used above, we think what you refer to
is
discrete user mobility, more like in UPT, where you register for
in/outgoing
calls to be routed to your current location. I.e. it relates to you and
your
H.323 application, and the call routing you want (including routing to
IVR etc..)
And it is true that this is neither wireless nor Mobile IP.
But it is important as well.
> When we know what the opportunities are, we will be better placed to
seek
> solutions. It is not enough to just say "roaming"!
> Douglas
> >Espen
[View Less]
Dear Mr. Okubo, dear colleagues,
I have placed a copy of the revised Draft H.323 Annex F (incorporating
editorial changes from the last Rapporteur's meeting in Monterey) in the
Incoming directory on the PicureTel ftp server: H323AnnexF-Delayed.zip
Please disregards file H323AnnexF-02.zip (uploading failed last night).
Regards,
Joerg
-------------------------------------------------------------------------------
Joerg Ott jo(a)tzi.uni-bremen.…
[View More]de
Universitaet Bremen, Germany fax + 49 421 218-7000
TELES AG voice + 49 421 201-7028
[View Less]
Dale:
Yes, I like Espen's idea.
I also like to add as follows:
1. Backend services for H.323
2. Mobility support for H.323
3. Other possible topics ...
Radhika R. Roy
AT&T
(732) 420 1580
PS: "Mobile Internet Telephony: Mobile Extension to H.323 by W. Liao,"
INFOCOM'99, is a good start for support of mobility in H.323.
> -----Original Message-----
> From: Espen Skjæran (ETO) [SMTP:Espen.Skjaeran@ETO.ERICSSON.SE]
> Sent: Friday, May 07, 1999 8:45 AM
> To: ITU-SG16(a)…
[View More]MAILBAG.INTEL.COM
> Subject: TD's for discussion at the Santiago meeting
>
> Dale,
>
> We would like to bring up a (rather new) topic for discussion about a
> future work item at the rapporteur's part of the Santiago meeting. We hope
> this is possible at this time.
>
> The topic is service control (and have been discussed at Tiphon meeting in
> Bankok this week). We will like to bring forward some of the Tiphon
> discussion to sg16. We will write a small note about the possible use of
> H.245 to establish service control channels. It will be explained via a
> few simple examples, and hopefully serve as a basis fo further dicsussion.
>
> Thus we will ask you as a rapporteur to give us a TD number if this is
> required.
>
>
> Espen Skjaeran
[View Less]
Let's not get too trigger happy here!
The original intent of flowControl is to constrain the bit rate of a channel
to something such as a video decoder can cope with. In the past these
tended to be MIPS limited, and bit rate tended to be a major (although not
only) parameter that affecting the number of MIPS required. Note that in
this case this was bits of video data and had nothing to do with headers
etc. flowControl is also used to control the rate at which gateways receive
things like …
[View More]video data. This allows the gateways to squirt the data down
fixed bit rate pipes such as parts of ISDN B channels. Again this figure is
not interested in packet overhead.
Use of flowControl in the QoS arena is the most recent of its uses.
Therefore, even if it is broken in this context, it is not appropriate to
change its definition as it would fix one problem and break two others!
However, I don't believe it is actually broken in the latter context. In
the QoS case, the flowControl command is really only used to switch the
channel on and off. The transmitter knows at which rate it will send, and
puts this in the RSVPParameters part of the OLC. This information is
presumably also put in the RSVP PATH Sender TSPEC.
Even if it is desired to allow flowControl to change the channel rate, a
transmitter that receives a flowControl message can work out what it
requires to add in terms of headers, and then change the RSVP PATH TSPEC
accordingly. This will get to the receiver, which will send RESV using the
new spec. As the transmitter knows what it is going to do in terms of
packetisation and the receiver can only guess, this seems the right way
round to me.
Pete
=============================================
Pete Cordell
pete.cordell(a)btinternet.com
=============================================
-----Original Message-----
From: Gur Kimchi <Gur_Kimchi(a)VOCALTEC.COM>
To: ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)MAILBAG.INTEL.COM>
Date: 07 May 1999 04:41
Subject: Re: flowControlCommand and packet overhead
>Paul Wrote:
>
>>>> The value in consistently
>>>> using the same, although arguably flawed,
>>>> bandwidth calculations outweighs the
>>>> benefit of having a mix of calculations.
>
>I don't quite agree, this is the type of corrections that should make
>into the Implementer's guide. When you calculate for a few sessions
>it does not make much of a difference, but there are high-scale GWs
>and GKs based on 323 out in the market (supporting multiple DS3s)
>and the offset will be too much - it will effect network provisioning.
>
>- gur
>
>______________________________________________________________________
> Gur Kimchi
> Corporate Director, Advance Technologies, Research and Standards
> VocalTec Communications Ltd
> web: http://www.vocaltec.com
>
>-------- On 05/06/99 04:04 PM GMT Paul Long <Plong(a)SMITHMICRO.COM> wrote:
>
>
>
>
>Steve,
>
>But H.323, the referencing document via H.225.0 of RFC 1889, says that
>bandwidth for the open logical channel bitrate and ARQ is calculated
>_without_
>headers. We cannot change this, because it would break existing
>implementations. Are you suggesting that flowControlCommand should do it
>differently, i.e., include at least the RTP header? The value in
>consistently
>using the same, although arguably flawed, bandwidth calculations outweighs
>the
>benefit of having a mix of calculations.
>
>Paul Long
>Smith Micro Software, Inc.
>
> -----Original Message-----
> From: Stephen Casner [SMTP:casner@CISCO.COM]
> Sent: Wednesday, May 05, 1999 10:20 PM
> To: ITU-SG16(a)MAILBAG.INTEL.COM
> Subject: Re: flowControlCommand and packet overhead
>
> On Wed, 28 Apr 1999, Paul Long wrote:
>
> > Therefore, clarification text to the following effect should be
>added to
> > 6.2.11.2 (in v2) of H.323:
> >
> > "flowControlCommand applies to the information streams
>which
>are the
> > content of logical channel(s), not including RTP headers, RTP
>payload headers,
> > network headers and other overhead."
>
> I'm mostly a lurker on this list, but I thought I would offer
>another
> perspective. The RTP spec, RFC 1889, says the following:
>
> Bandwidth calculations for control and data traffic include
>lower-
> layer transport and network protocols (e.g., UDP and IP) since
>that
> is what the resource reservation system would need to know. The
> application can also be expected to know which of these
>protocols
>are
> in use. Link level headers are not included in the calculation
>since
> the packet will be encapsulated with different link level
>headers
>as
> it travels.
>
> At a minimum, I would expect the RTP payload header to be included
> because that is specific to the encoding and would not be known by
> lower layers. The difficulty in pushing this problem off to lower
> layers is that they need to know the packet rate in order to know
>how
> much overhead the additional headers will add.
> -- Steve
>
[View Less]
Hi Christian,
Good timing, In the study D meeting in Washington dc
I was asked to put my contribution as a proposal for
new annex in h.246. In the contribution I show one example
in Annex-A of the RAS messages mapping into ITU INAP other
example may include HLR/VLR, MAP and WIN messages. I did
not include the parameters mapping. Because, I did not
want to do all that work until the concept is
approved. (document attached)
In any case I have proposed the lower layer
sigtran transport (CTP) to …
[View More]carry upper layer protocol
for tunneling and interworking. Which
should not be any issue with h.246 or the
work you are doing..I hope?
I will read your contribution as a framework going forward
on SS7 interworking. We both/all need to resolve the Transport
problem where to terminate the Lower SS7 layers (MTP 1,2,3).
That is, where does SS7 ends and IP begins? in the H.323 network
i.e., tiphon.
Regards,
Ed
Christian Groves wrote:
>
> G'Day All,
>
> Attached is a draft copy of H.246 Annex C.
>
> As you can see it is Version 0.0 so it needs some
> work. It is based on Q.699 as is split into 4
> main sections:
>
> 1 Overview/Introduction
> 2 ISUP to H225 message and parameter mapping
> 3 Outgoing Call - H.225 to ISUP
> Basic Call
> Services
> 4 Incoming Call - ISUP to H.225
> Basic Call
> Services
>
> The services sections need some work to align
> with the 3pty/conference discussions.
>
> RAS hasn't been considered in the document yet.
>
> Comments/addition/amendments welcome.
>
> Regards, Christian Groves
>
> ------------------------------------------------------------------------
> Name: h246_annex_c_v_0-0.zip
> h246_annex_c_v_0-0.zip Type: Winzip32 File (application/x-zip-compressed)
> Encoding: base64
--
Edgar Martinez - Principal Staff Engineer
Email mailto:martinze@cig.mot.com
FAX 1-847-632-3145 - - Voice 1-847-632-5278
1501 West Shure Drive, Arlington Hgts. IL 60004
TIPHON & Other Stds -- http://www.cig.mot.com/~martinze/
[View Less]
Paul Wrote:
>>> The value in consistently
>>> using the same, although arguably flawed,
>>> bandwidth calculations outweighs the
>>> benefit of having a mix of calculations.
I don't quite agree, this is the type of corrections that should make
into the Implementer's guide. When you calculate for a few sessions
it does not make much of a difference, but there are high-scale GWs
and GKs based on 323 out in the market (supporting multiple DS3s)
and the offset …
[View More]will be too much - it will effect network provisioning.
- gur
______________________________________________________________________
Gur Kimchi
Corporate Director, Advance Technologies, Research and Standards
VocalTec Communications Ltd
web: http://www.vocaltec.com
-------- On 05/06/99 04:04 PM GMT Paul Long <Plong(a)SMITHMICRO.COM> wrote:
Steve,
But H.323, the referencing document via H.225.0 of RFC 1889, says that
bandwidth for the open logical channel bitrate and ARQ is calculated
_without_
headers. We cannot change this, because it would break existing
implementations. Are you suggesting that flowControlCommand should do it
differently, i.e., include at least the RTP header? The value in
consistently
using the same, although arguably flawed, bandwidth calculations outweighs
the
benefit of having a mix of calculations.
Paul Long
Smith Micro Software, Inc.
-----Original Message-----
From: Stephen Casner [SMTP:casner@CISCO.COM]
Sent: Wednesday, May 05, 1999 10:20 PM
To: ITU-SG16(a)MAILBAG.INTEL.COM
Subject: Re: flowControlCommand and packet overhead
On Wed, 28 Apr 1999, Paul Long wrote:
> Therefore, clarification text to the following effect should be
added to
> 6.2.11.2 (in v2) of H.323:
>
> "flowControlCommand applies to the information streams
which
are the
> content of logical channel(s), not including RTP headers, RTP
payload headers,
> network headers and other overhead."
I'm mostly a lurker on this list, but I thought I would offer
another
perspective. The RTP spec, RFC 1889, says the following:
Bandwidth calculations for control and data traffic include
lower-
layer transport and network protocols (e.g., UDP and IP) since
that
is what the resource reservation system would need to know. The
application can also be expected to know which of these
protocols
are
in use. Link level headers are not included in the calculation
since
the packet will be encapsulated with different link level
headers
as
it travels.
At a minimum, I would expect the RTP payload header to be included
because that is specific to the encoding and would not be known by
lower layers. The difficulty in pushing this problem off to lower
layers is that they need to know the packet rate in order to know
how
much overhead the additional headers will add.
-- Steve
[View Less]
Another point to consider is when to use which transport:
for Annex G:
small/fast messages should be sent over UDP (e.g. the Access family)
large/slow messages should be sent over TCP (e.g. information
push/pull)
ultimately this is an implementation + network environment issue.
for Annex E, I really don't see this as an issue - 225 messages are small
(we did specify
PER for a purpose) and far between, so the follow the small/fast category.
- gur
-------- On 05/05/99 04:08 PM GMT …
[View More]Andrew Draper <Andrew.Draper(a)MADGE.COM>
wrote:
At 09:35 1999-05-04 +0200, ETO wrote:
>When an Annex G message will exceed max packet size (typically a
>DescriptorConfirm) on UDP, a Reject might be sent, and the session is
>repeated on TCP.
>
>But, isn't our PDU size on TCP also limited? When using TPK,
the max pdu
>size is 65k too, as seen in RFC-1006....
I don't think this is a problem for Annex G.
First, a sensible implementation is probably sending DescriptorRequests
over
TCP anyway since it expects a large (well larger than MRU) answer anyway so
the UDP step described above won't happen (only AccessRequest and
ValidationRequest is likely to be sent over UDP).
Secondly, the only message likely to run into the maximum message size
limit
is the DescriptorConfirm (if a descriptor is more than 64K). I don't
expect
anyone to have a descriptor of 64K or more, but if they do it can be broken
down into multiple descriptors, and each one transmitted separately.
For call signalling over annex E the message size limit isn't a problem
either. Annex E will be transmitting the same call signalling messages as
would be sent over TPKT over TCP, so messages of more than 64K aren't
allowed (since they wouldn't fit within TPKT), even if anyone can create a
plausible one.
Regards,
Andy
--
Andrew Draper -- Principal Development Engineer -- WAVE Software
Madge Networks, Wexham Springs, Framewood Road, Wexham, Berks, UK.
mailto:adraper@madge.com = = = = = = = = = phone:+44 1753 661329
pgp fingerprint 8776 1F5F DD1B F37E BEF7 1E52 924D F6B7 34CB EFA9
[View Less]
