Miri,
There is a small problem with your proposal. The KeepActive in Signals
is not available in the ETSI_BGF profile (I've checked until version
1.1.4) .
Table 27: KeepActive
KeepActive used on signals:
No
So, KeepActive will not be usable with ETSI_BGF profile, one of the
primary candidates for this package.
Thanks,
Jisu Bhattacharya
Cisco Systems
On 6/2/07, * Miri Epstein* <mepstein at juniper.net
<mailto:mepstein at juniper.net>> wrote:
Hi,
Please see below.
Sorry, but sending it as an attachment (.doc) is not possible. As
a result, the change proposals became not clear enough.
Thx,
Miri
---------------------------
Miri Epstein
System Architect
VoIP Engineering
Juniper Networks
Direct +972.9.9717315
Fax +972.9.9717334
mepstein at juniper.net <mailto:mepstein at juniper.net>
www.juniper.net <http://www.juniper.net>
___________________
TELECOMMUNICATION
STANDARDIZATION SECTOR
STUDY PERIOD 2005-2008
STUDY GROUP 16
Original: English
Question(s):
Source:
Juniper Networks
Title:
H.248.37 Amendment 1 - IP NAPT traversal package: Update of the
Remote Descriptor with the latched address information as a result
of latch/relatch signal completion.
Purpose:
Proposal / Discussion
Problem:
The IP NAPT traversal package does not provide the MGC with a
method to obtain the latched address information, resulting with a
possible ambiguity about "the address towards which packets are
sent".
Problem Description:
The existing way for an MGC to learn about a remote destination
address change is by the reporting of the new address and port as
defined by the Address Reporting package (adr). This method is
based on a Notify command being sent from the MG.
There is a significant drawback on using only this method. The
latched address information is not always available for MGC, for
example, if the Notify command was lost due to a network
disconnection or an MGC failover. In any such case, the MGC cannot
retrieve this important information.
In addition, following a latch/relatch event, the customary method
of using an AuditValue command to synchronize between states of
the MGC and the MG may result in an error. Based on the reply of
the AuditValue, the MGC has no way of knowing whether the MG is
still sending packets to the address appearing in the Remote
descriptor or to the new (latched) address. In fact, the MGC might
not even know that an ipnapt/latch signal was ever applied to the
stream.
Following, we analyze the possible states for a stream regarding
the ipnapt/latch signal:
a) When the ipnapt/latch signal is not activated, the Remote
Descriptor represents the destination of the media packets.
b) When the ipnapt/latch signal is activated, but no
latching/relatching has occurred yet, the Remote Descriptor still
represents the destination of the media packets.
c) After the stream has latched/relatched, the destination of the
media packets is the latched address (and port) and not the
no-longer-valid Remote Descriptor. The ipnapt/latch signal has
completed, so an attempt to audit the Signals Descriptor will not
show it. This case is a new state, different from both (a) and
(b). However, the MGC cannot distinguish (using AuditValue)
between (a) and (c).
This analysis demonstrates that the current approach creates a
kind of "hysteresis" - the result of a termination's AuditValue
does not encompass the complete gate state - but must be merged
with past information; the previous existence of an ipnapt/latch
signal and a received adr Notify. Also, this approach creates a
deviation from the semantic meaning of the Remote descriptor as
"the address towards which packets are sent".
Suggested Solution:
We suggest updating the Remote Descriptor with the latched address
information. The SDP connection data field <connection-address>
will hold the new address and the media field <port> will hold the
new port. Both are updated as a result of latching/relatching.
This permits the ordinary use of the AuditValue command with the
Remote Descriptor, at any time, in order to get the actual
destination of the media packets.
This also makes state (c) above identical to state (a),
eliminating the AuditValue ambiguity.
Further Incentives, the KeepActive flag:
Because states (a) and (c) above are indistinguishable by the MGC,
clause 5.6.5 suggests the use of the KeepActive flag in order to
avoid the state (a, b or c) changing following a Modify of the
Signals Descriptor.
This use appears inconsistent with clause 7.11 of H.248.1:
"Signals present in the replacement descriptor and containing the
KeepActive flag shall be continued if they are currently playing
and have not already completed. If a replacement Signals
Descriptor contains a signal that is not currently playing and
contains the KeepActive flag, that signal shall be ignored."
Therefore it would seem that even if the KeepActive flag is used,
a Modify of the Signals Descriptor should cause state (c) above to
revert to (a).
This issue is avoided by having the latch completion update the
Remote Descriptor. As the MG always sends media towards the
address appearing in the Remote Descriptor, there is no need for a
special mechanism for maintaining state (c).
Conclusion:
By updating the Remote Descriptor with the latched address
information, we achieve a simple and standardized way to
facilitate tracking and tracing changes of the destination of
media packets.
Also, this update makes the specialized use of the KeepActive
signal flag redundant.
Correspondent changes are proposed below.
Change proposal against TD-35:
[Begin Proposal]
5.6.2 NAPT traversal processing: 'LATCH' mode
When the NAPT processing signal latch with parameter napt on a
termination/stream is set to LATCH, then this results in the MG
updating the addresses received in the RemoteDescriptor. The MG
will use the source address and source port from the incoming
media stream ( i.e., from the other terminations) as the
destination address and destination port of the outgoing
application data. The RemoteDescriptor is updated with these new
source address and source port. Figure 2/H.248.37 illustrates this
behaviour.
To the figure: an additional rectangle containing "Remote
Address=CPE1"should be inserted under the existing one (marked
with "x")
Latching is limited on the very first IP packet arrival event.
Source address information of afterwards received IP packets will
not be used for latching.
[End Change Proposal]
[Begin Proposal]
5.6.2.1.2 RecvOnly or Inactive before latching
In all cases here, the initial StreamMode is supposed to be
"RecvOnly" or "Inactive.
There are following possibilities:
* Underspecified RD without initial remote destination address
information, but all other descriptor elements are available:
Initially no packets will be sent because the destination address
information is not available and because restricted by StreamMode
settings. The first packet arrival event after enabling 'LATCH'
will allow packet sending (dependent on StreamMode settings).
* Still missing RD:
There could be theoretically already IP packets sent after the
first packet arrival event after enabling 'LATCH' (given that
StreamMode settings have changed for sending). But this is
questionable in practice due to potentially "meaningless IP
packets" ( e.g. still missing correct media field, format list, etc.).
The packet sending process should be therefore tightly coupled
with RD, i.e. the availability of all required information elements.
Initial signaled remote destination address information (in RD):
The packet sending process will not be started as long as the
initial StreamMode settings will not be changed to a value of
SendOnly or SendReceive. Nevertheless, the first packet arrival
event after enabling 'LATCH' will overwrite the remote destination
address in the RemoteDescriptor with the latched address,
independent of whether the H.248 signalled address information is
equal to or unequal to the latched address information.
[End Change Proposal]
[Begin Proposal]
5.6.3 NAPT traversal processing: 'RELATCH' mode
When the NAT traversal processing signal latch with parameter napt
on a termination/stream is set to RELATCH, then the MG will
perform a similar process to the latching process described above.
The difference is that the MG will check for a change of source IP
address/port on the incoming media stream. If/when a new source IP
address and/or port are detected, then they will be updated in the
Remote Descriptor and used as the destination address and port for
future outgoing packets. After re-latching, any packets received
on the old source address and port combination will be considered
as malicious and will be treated accordingly (discarded and
possibly counted; see sub-clause5.6.6). This is an implicit filter
rule related to source filtering. This implicit filter conditions
may be overruled by other, explicit filter rules as defined by
other H.248 packages, see clause 7.
The packet sending process in 'RELATCH' mode, before and after
successful re-latching, has again the two dependencies on
* available destination address information (IP DA, IP DP), and
NOTE: Information is implicitly available after re-latching and
may be available before the re-latching event dependent on RD
settings.
* StreamMode settings.
Application of 'RELATCH' mode does not imply a previous 'LATCH'
mode. New IP terminations may be therefore initially enabled for
the 'RELATCH' mode by the ADD.request command.
[End Change Proposal]
[Begin Proposal]
5.6.4.1 <http://5.6.4.1> Recommendations for 'LATCH' and 'RELATCH'
mode
The generic event g/sc, associated to signal latch,
* could be useful for MGCs which are interested in successful (or
unsuccessful) latching occurrences,
* but is basically not required for the application of ipnapt package.
* If requested by the MGC, the signal completion event would be
returned when packets are received according to the latching
process (e.g. MG detects a packet coming from a different address
for the particular stream).
The signal completion event would be returned irrespective of the
address in the RD.
The MGC may ask for the address information the MG is using as a
result of the latch process by usage of the adr package (see
clause6), or by issuing an AuditValue command with the
RemoteDescriptor.
* If requested by the MGC, the signal completion event would be
returned when packets are received according to the latching
process (e.g. MG detects a packet coming from a different address
for the particular stream).
The signal completion event would be returned irrespective of the
address in the RD. ME: this last sentence can be removed.
[End Change Proposal]
[Begin Proposal]
5.6.5 Usage of signal 'latch' together with signal parameter
'KeepActive'
The KeepActive flag could be principally combined with signal
latch (in new Signals Descriptor), see clause7.1.11/H.248.1. The
KeepActive flag is required to support the following use case:
The MGC starts the (re)latching process; and does not know whether
the process has completed. If, later on, the MGC modifies the
ephemeral termination signals descriptor, the MGC adds the
KeepActive flag to avoid either turning the signal on (if it has
already completed) or off (if it was not completed yet).
[End Change Proposal]
___________________
_______________________________________________
Megaco mailing list
Megaco at ietf.org <mailto:Megaco at ietf.org>
https://www1.ietf.org/mailman/listinfo/megaco
------------------------------------------------------------------------
_______________________________________________
Megaco mailing list
Megaco at ietf.org
https://www1.ietf.org/mailman/listinfo/megaco