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
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:
megaco-bounces <at> ietf.org [mailto:megaco-bounces <at> ietf.org] On Behalf Of
Aronis, Marios (NSN - GR/Athens)
Sent: Thursday, December 09,
2010 11:58 AM
To: megaco <at> ietf.org
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
RSS Feed