IEPREP Vienna meeting minutes**Carlberg presentation
Basic telephony and general requirements were acceptable (i.e., no
objections) to the working group. The framework will undergo another pass
through. Polk - raised the issue that the IETF use terms in alignment with
the ITU. The ITU uses the initialism TDR (telecommunications for
disaster relief) vs. ETS. **
Carlberg stub domain presentation
Berg - wants to know if access links and transit are part of some IEPREP
document, Scott says within a domain but not in plan to go beyond single
domain. Desire has been expressed but not enough meet in traction to go
further. Scott feels the intention is both stub domains and transit over a
single domain. Polk - wants to know EF relationship and things like MPLS
Polk - This document proposes extensions to a lot of existing
protocols, and a BCP is intended to use existing technology in its
practices. The ideas in this document might be better served if the ideas
were broken up, replaced by requirements, and moved into the
appropriate working groups for consideration. If the resulting
mechanisms are standardized, then the document can be revived in IEPREP for
consideration. Further, the point is that this document only proposed
solutions, which are not appropriate. In order for this document to have any
use it must be made up of requirements.
Bradner - This document, as is, has no path forward. The use of
experimental codepoints makes it such that it won't be made into an RFC.
Also, a best common practices document must be possible with existing
technology, and due to the fact that you are using experimental
codepoints, you don't meet that requirement. If the media gateway is smart
enough to differentiate between ETS and non-ETS traffic, then the IP
portion is not relevant, as two tunnels can be created (1 - ETS; 1 - non
ETS), and manage the priority in that way.
Henry (MCI) - There are no IP phones in the architecture, and
therefore the model is bad. Also, it doesn't consider cable networks at
all. Scott Bradner said that it was "a scenario that needs to be
addressed, but not the only one."
Dick Knight - asked a clarification on the requirement in the proposed BCP
for the use of M2UA rather M3UA. Dick stated that M2UA emulates SS7 MTP2
level (Signaling Transport - Link Level) so that an existing SS7 MTP3
(Signaling Transport - Network Level) can be used without it knowing that it
is operating in an IP packet environment. Similarly, M3UA emulates the
Signaling Network Level of SS7, so that ISUP and other Application Parts of
the SS7 stack, can be used without knowledge of the underlying IP
network. Janet's presentation explicitly stated that M2UA MUST be used in
order to preserve SS7 ISUP parameters. Dick pointed out that whether M2UA or
M3UA is used, the ISUP parameters are unaffected. He asked for an
explanation of this requirement.
Dick Knight also said "People are using M3UA or M2PA. Nobody is using
M2UA." Also "There is no point in using the (current) SIP emergency
header if you are going to a CSN phone. The SIP emergency
notification will never get there. The SIP emergency notification only
makes sense if it is going to a SIP phone."