Subject: AVD-2834; RE: [Megaco] H.248.37 - Latch versus Relatch

From: [email-masked]
Date: Thu, 3 Aug 2006 09:11:38 +0200

fyi, we did record the responses (as well as our understanding of some
other .37 related questions) in a proposed draft Addendum to H.248.37.

See AVD-2834:
http://ftp3.itu.int/av-arch/avc-site/Incoming/AVD-2834%20H.248.37_Addendum.zip

(note: doc will be moved later to directory
http://ftp3.itu.int/av-arch/avc-site/2005-2008/0608_Ott/)

Any comments?
Albrecht/Juergen

                      "Christer Holmberg                                                                                                   
                      \(JO/LMF\)"                   To:      [email-masked], "Christian Groves" <[email-masked]>     
                      <christer.holmberg@er         cc:      Albrecht SCHWARZ/DE/ALCATEL@ALCATEL, [email-masked],                   
                      icsson.com>                   [email-masked], [email-masked]                                          
                                                    Subject: RE: [Megaco] H.248.37 - Latch versus Relatch                                  
                      17.07.2006 22:26                                                                                                     

Hi,

I am currently on vacation, so I will need to verify Christian's answers
when I get back to office (I will be away the whole july). But, after a
first look it seems like we have a common view :)

Regards,

Christer

-----Original Message-----
From: Juergen Stoetzer [mailto:[email-masked]]
Sent: 17. heinäkuuta 2006 14:42
To: Christian Groves
Cc: Christer Holmberg (JO/LMF); Albrecht Schwarz; Carsten Waitzmann;
Andreas Winkler; Uwe Uhler
Subject: Re: [Megaco] H.248.37 - Latch versus Relatch

Hello Christian,

Thanks a lot for your answers!
They really help clarifying things.

Thank you and best regards,
Juergen

Christian Groves wrote:
> Hello Juergen,
>
> Please see my replies below marked CNG. As I'm no longer with
> Ericsson, Christer may have a seperate view.
>
> Regards, Christian
>
> Juergen Stoetzer wrote:
>
>> Hello Christian and Christer,
>>
>> Below are some questions to H.248.37. Guess you as former editor/main
>> contributors may have the best insights in the package design and
>> background information.
>>
>> Thanks a lot in advance for any ideas and clarifications you may give!
>> Best regards,
>> Juergen Stoetzer
>>
>> --------------------------------------
>>
>> The package H.248.37 introduces the signal ipnapt/latch with
>> parameter napt.
>> This parameter napt may have the values OFF, LATCH and RELATCH.
>> The parameter value LATCH is defined as
>>
>> "When the NAPT processing signal with the NAPT parameter on a
>> termination/stream is set to LATCH, then this results in the MG
>> ignoring the addresses received in the RemoteDescriptor. Instead 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 value RELATCH is defined to imply a similar gateway behaviour as
>> the value LATCH with the difference
>>
>> "... 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 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 counted)."
>>
>> Thus, the RELATCH case emphasizes the change of source IP address/port.
>> Does this mean that RELATCHing is only possible/allowed after a first
>> LATCHing was already performed and thus the used destination IP
>> address/port for outgoing packets are in fact already different from
>> the ones in the Remote descriptor?
>
>
> [CNG] Not necessarily. RELTACH enables the MG to keep receiving
> packets and then immediately LATCH to packets from a new source
> address.  If the MGC sends LATCH it immediately latches to the next
> packet. However I think the most likely use case is LATCH followed by
RELATCH.
>
>>
>> In case the stream mode of the corresponding termination equals
>> SendReceive it seems to be clear that the signal
>> ipnapt/latch{napt=LATCH} completes (generates the g/sc event if
>> requested by the MGC) at the moment the next IP packet is received by
>> the corresponding termination. From that moment onwards the source
>> address/port of that received packet will then be used as destination
>> address/port for outgoing packets.
>>
>> In case a Remote descriptor is already specified, is this behaviour
>> independent of whether the source address/port of received IP packet
>> is equal to or unqual to the IP address/port specified in this Remote
>> descriptor?
>> That is, if the source address/port of received packet is equal to
>> the address/port in the Remote descriptor, does the signal
>> ipnapt/latch{napt=LATCH} complete nevertheless?
>
>
> [CNG] Yes I would say the signal complete would be returned
> irrespective of the address in the remote descriptor.
>
>>
>> Is this also the case if the stream mode is equal to ReceiveOnly?
>> Or does the signal ipnapt/latch{napt=LATCH} in this case only
>> complete at the moment the first IP packet is received _after_ the
>> stream mode was changed to SendReceive?
>> In other words, does the reception of the new address trigger the
>> signal completion event or is it the first packet which is actually
>> sent to the new address?
>
>
> [CNG] Signals are usually independent of stream mode. The signal
> completion would be when packets are received as that is what drives
> the latching process.
>
>>
>> When does the signal ipnapt/latch{napt=RELATCH} complete?
>
>
> [CNG] When the MG detects a packet coming from a different address for
> the particular stream.
>
>>
>> Does it make sense to generate an IP termination with a Signals
>> descriptor containing the signal ipnapt/latch{napt=RELATCH}, i.e.
>> with RELATCH parameter?
>> That is to say, can the very first IP packet received by
>> corresponding termination be considered to have a 'new'/'different'
>> source IP address/port?
>>
>> Let's assume an IP termination (Ia profile terminology) is created
>> only with a Local descriptor and ipnapt/latch signal:
>>
>> Add = ip/<group>/<interface>/$ {
>>   Signals{ipnapt/latch{napt=LATCH}},
>>   Media {
>>     LocalControl {
>>       Mode = SendReceive
>>     },
>>     Local {
>>       ....
>>     }
>>   }
>> }
>>
>> Is this IP termination then allowed to start sending out IP packets
>> after having received the first incoming packet (and after having
>> performed latching with the received source address/port) since the
>> Stream Mode equals SendReceive but before having received a Remote
>> descriptor?
>
>
> [CNG] Yes and no. The MG has the remote addresses at this stage but no
> description of the media type etc that is usually contained in the
> Remote Descriptor. Latching means you ignore the addresses but not the
> whole remote descriptor contents.
>
>>
>> _______________________________________________
>> Megaco mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/megaco
>>
>>
>>
>>
>

_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco