Subject: [Megaco] latching vs stream mode=sendonly

From: "Aronis, Marios (NSN - GR/Athens)" <[email-masked]>
Date: Thu, 9 Dec 2010 17:58:08 +0100

Hello,

 my question concerns the Border Gateway Function in IMS. Assume that a
termination on the BGF has been set to stream mode = SendOnly with a
modify command that also activates the ipnapt/latch package with latch
or relatch. Is this a valid combination? If the BGF next receives a
Modify command with stream mode = sendreceive and latch=off, is it
expected that latching has occurred in previous step (while in send only
mode), so two way communication is allowed ? Could the case be that the
BGF drops all incoming traffic since stream mode = sendonly and thus
does not latch on the first received packet remote descriptor? I have
gone through H248 standards but have not found any clear statement on
that, so any reference would be highly appreciated! 

Many thanks, Marios

Marios Aronis 
BSO VIPT RD VoIP hiQ43 PI

---

From: "Bhattacharjee, Arindam (Arindam)" <[email-masked]>
Date: Thu, 9 Dec 2010 11:38:22 -0600

Hi Marios,

Latching is a mechanism mainly to provide early bearer on IMS network where there is a big call setup latency involved. e.g. in wireless IUCS operations where there is IUCS signaling involved for early bearer but remote SDP is not known yet.
So this is basically left to implementation to accept remote packet from any IP address & open Pinhole is case of BGF for a certain period of time during call setup till the remote SDP is known thru signaling when latch is set to off & modified to the known remote IP.

In case of BGF it does create a hole in initial session setup as far as security is concerned.

-Arindam

From: [email-masked] [mailto:[email-masked]] On Behalf Of Aronis, Marios (NSN - GR/Athens)
Sent: Thursday, December 09, 2010 11:58 AM
To: [email-masked]
Subject: [Megaco] latching vs stream mode=sendonly

Hello,

 my question concerns the Border Gateway Function in IMS. Assume that a termination on the BGF has been set to stream mode = SendOnly with a modify command that also activates the ipnapt/latch package with latch or relatch. Is this a valid combination? If the BGF next receives a Modify command with stream mode = sendreceive and latch=off, is it expected that latching has occurred in previous step (while in send only mode), so two way communication is allowed ? Could the case be that the BGF drops all incoming traffic since stream mode = sendonly and thus does not latch on the first received packet remote descriptor? I have gone through H248 standards but have not found any clear statement on that, so any reference would be highly appreciated!

Many thanks, Marios

Marios Aronis

---

From: "Schwarz, Albrecht (Albrecht)" <[email-masked]>
Date: Fri, 10 Dec 2010 08:41:55 +0100

>I have gone through H248 standards but have not found any clear statement on that, so any reference would be highly appreciated!

Marios,

you know that the H.248.37 procedures are normative for latching.
Clause 6.6/H.248.37 (06/08)<http://www.itu.int/rec/T-REC-H.248.37/recommendation.asp?lang=en&parent=T-REC-H.248.37-200806-I> specifies the behaviour of "latch modes" versus "StreamMode settings"!

Anything unclear or missing in H.248.37?
If yes, please comment against the standard.

Regards,
Albrecht

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bhattacharjee, Arindam (Arindam)
Sent: Donnerstag, 9. Dezember 2010 18:38
To: Aronis, Marios (NSN - GR/Athens); [email-masked]
Subject: Re: [Megaco] latching vs stream mode=sendonly

Hi Marios,

-Arindam

Hello,

Many thanks, Marios

Marios Aronis

---

From: "Maridi R. Makaraju \(Raju\)" <[email-masked]>
Date: Fri, 10 Dec 2010 10:29:33 -0600

In addition to saving a Modify to update remote ip/port + early media
case...
Another purpose of latching (arguably the main purpose) is for "NAT
Traversal", i.e. to deal with endpoints behind a NAT; in such a case the
bearer (RTP/RTCP) port received in signaling is different from the bearer
port allocated by NAT. In this case, latching is the only way BGF can "latch
" on to (or learn ) the incoming port (of NAT).
 
Marios,
To answer your question, The combinations "latch=on, mode=sendonly/inactive"
is ambiguous and may or may not work depending on BGF implementation.
For RTP/RTCP based streams, please note that in case of modes sendonly or
inactive RTCP packets still go through in both the directions.
So, BGF can at least latch onto RTCP port (and in most cases RTP port can be
determined as "RTCP -1") as BGF should be prepared to accept
RTCP packets. RTCP based latching may take longer as it depends on the RTCP
reports which may occur at ever ~5sec or so.
BGF implementation may choose to drop RTP packets without considering latch
setting or can accept just one RTP packet (but not pass it through)
and start dropping rest of them. 
 
Having said all that, in my opinion, "latch=on, mode=sendonly/inactive"
works or not may depend on BGF implementation, it is better for call control
to choose a more deterministic
approach of using "latch=on, mode=recvonly".
 
More robust implementations might do:
step1: latch=on, mode=recvonly/inactive(in your example)
and then followed by
step2: latch=on, mode=sendrecv (basically keep the latching signal
unmodified, so no need to send Signal descriptor again).
 
If latching was already done in step1 then step 2 won't do latching again.
If latch is turned off in step2 then there is a risk that latching might not
be complete in step1 (even if mode was set to sendrecv or recvonly).

-Raju

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Bhattacharjee, Arindam (Arindam)
Sent: Thursday, December 09, 2010 11:38 AM
To: Aronis, Marios (NSN - GR/Athens); [email-masked]
Subject: Re: [Megaco] latching vs stream mode=sendonly

Hi Marios,

Latching is a mechanism mainly to provide early bearer on IMS network where
there is a big call setup latency involved. e.g. in wireless IUCS operations
where there is IUCS signaling involved for early bearer but remote SDP is
not known yet.

So this is basically left to implementation to accept remote packet from any
IP address & open Pinhole is case of BGF for a certain period of time during
call setup till the remote SDP is known thru signaling when latch is set to
off & modified to the known remote IP. 

In case of BGF it does create a hole in initial session setup as far as
security is concerned. 

-Arindam

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Aronis, Marios (NSN - GR/Athens)
Sent: Thursday, December 09, 2010 11:58 AM
To: [email-masked]
Subject: [Megaco] latching vs stream mode=sendonly

Hello,

 my question concerns the Border Gateway Function in IMS. Assume that a
termination on the BGF has been set to stream mode = SendOnly with a modify
command that also activates the ipnapt/latch package with latch or relatch.
Is this a valid combination? If the BGF next receives a Modify command with
stream mode = sendreceive and latch=off, is it expected that latching has
occurred in previous step (while in send only mode), so two way
communication is allowed ? Could the case be that the BGF drops all incoming
traffic since stream mode = sendonly and thus does not latch on the first
received packet remote descriptor? I have gone through H248 standards but
have not found any clear statement on that, so any reference would be highly
appreciated! 

Many thanks, Marios

Marios Aronis

---

From: "Maridi R. Makaraju \(Raju\)" <[email-masked]>
Date: Thu, 9 Dec 2010 17:01:25 -0600

Marios,

-Raju

  _____  

Hi Marios,

-Arindam

Hello,

Many thanks, Marios

Marios Aronis