Re: [Megaco] "IP NAPT traversal package: Update of the Remote Descriptor with the latched address information as a result of latch/relatch signal completion "

On 6/3/07, Christian Groves <Christian.Groves at nteczone.com> wrote:

Hello Jisu,

I can't see why this is a problem. The profile itself would have to be
updated to meet the new proposal. Keepactive could be changed then.

Regards, Christian

Jisu Bhattacharya wrote:
> 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
>