Table 27: KeepActive
|
KeepActive used on signals: |
No |
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
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 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
https://www1.ietf.org/mailman/listinfo/megaco
_______________________________________________ Megaco mailing list Megaco at ietf.org https://www1.ietf.org/mailman/listinfo/megaco