Re: latching vs stream mode=sendonly

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 protected] [mailto:[email protected]] On Behalf Of
Bhattacharjee, Arindam (Arindam)
Sent: Thursday, December 09, 2010 11:38 AM
To: Aronis, Marios (NSN - GR/Athens); [email protected]
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 protected] [mailto:[email protected]] On Behalf Of
Aronis, Marios (NSN - GR/Athens)
Sent: Thursday, December 09, 2010 11:58 AM
To: [email protected]
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 
BSO VIPT RD VoIP hiQ43 PI

_______________________________________________
Megaco mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/megaco