Subject: Re: [Megaco] RTCP flow handling

From: [email-masked]
Date: Sun, 29 Oct 2006 07:03:34 +0100

(1) media inactivity detection
Discussion subject is now changing towards "media inactivity detection",
which is subject of Draft H.248.40, the application data inactivity
detection package.
Please have a look in the package, key point is that inactivity detection
is particularly related to a set of *conditions* in case of H.248 RTP
terminations (see also Appendix I/H.248.40).

NOTE: nt/netfail is supported by the Ia profile, but may not used so far
for "media inactivity detection" because the condition(s) for the event
detection logic are not yet specified (and a cause value should be defined
then as well IMHO), which is a prerequisite for the application of this
event (see § E.11.5.1.1 and also § E.11.5.1.4 in H.248.1 V3). The
application of nt/netfail would be controversial, or even
counterproductive, without such a clear mutual aggrement between MGC and
MG.
Saying that, I believe that the adid package is a much better way to
address "media inactivity detection" for RTP/RTCP traffic.

(2) RTCP in Ia Profile
Do agree to Kevin, we may not conclude from RFC 3264 on required Ia profile
capabilities.
(Perhaps we could derive an RTCP requirement from Gq' or TISPAN RACS, but I
don't know.)
Even more, Ia Profile V1 is "media-agnostic", i.e., an H.248 IP termination
is not necessarily representing an RTP session.
What we could consider for Ia Profile V2 that an H.248 IP termination type
for RTP must support per default RTCP as well. But this requires first a
contribution for WI-03098.
I think there is agreement on such a requirement, but I got the same view
as Reinaldo: the reality on RTP/RTCP deployments is very multifaceted,
which doesn't allow (a) an implicit conclusion that RTCP is always part of
an RTP session; and (b) an implicit conclusion that nt/netfail is already
prepared in Ia for the detection of inactivity for RTP/RTCP traffic.

I'm a proponent of RTCP, but we should make our (H.248 profile) specs more
explicit on that subject.

- Albrecht

                      "Jan Lindquist                                                                                                   
                      (TN/EAB)"                 To:      [email-masked]                                                      
                      <jan.lindquist@ER         cc:                                                                                    
                      ICSSON.COM>               Subject: Re: [Megaco] RTCP flow handling                                               
                                                                                                                                       
                      27.10.2006 14:32                                                                                                 
                      Please respond to                                                                                                
                      "Jan Lindquist                                                                                                   
                      (TN/EAB)"                                                                                                        

Hello Jan,

The BGF through the Ia profile can be used to arm the detection of loss of
the media flow. The BGF can then inform the SPDF of the loss of media for a
subsequent teardown.

Regards,
JanL

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: den 27 oktober 2006 13:33
To: Jan Lindquist (TN/EAB); [email-masked]
Subject: RE: [Megaco] RTCP flow handling

Interesting discussion.

I was wondering whether only the 2 endpoints need to know whether the
"coonection" is still ON, or do the core network  functions like S-CSCF
and/or AS also be aware that the session is still ON, even when no RTP is
flowing.

I would be interested in having a general mechanism to "detect"
connectivity loss, and consequently session teardown.

Kind regards

Jan Van Geel
IT and Network Development Specialist
Belgacom ITN/NIS/NST/NCP
Tel: +32 2 202 1035
Tel: +32 2 207 9032
Email : [email-masked]
www.cyberwezz.tk

-----Original Message-----
From: Jan Lindquist (TN/EAB) [mailto:[email-masked]]

Sent: 27 October 2006 13:26
To: [email-masked]
Subject: Re: [Megaco] RTCP flow handling

Hello Reinaldo,

There will be a problem if the Home Gateways or VoIP Phones do not send any
RTP/RTCP when a call is put on hold. Do you know if these products send
silence suppression in RTP (payload type 18) when a call is put on hold?
Without any RTP or RTCP then it is not possible for the other end to know
if the connection has been lost and may trigger a release of the call. In
H.248 terms an MG could send a "nt/netfail" Notify command when no media
arrives if the event is armed. In the Ia profile we have nt package as
required but we may want to expand on the usage specially in light of this
issue.

Regards,
JanL

-----Original Message-----
From: Reinaldo Penno [mailto:[email-masked]]
Sent: den 27 oktober 2006 10:33
To: Jan Lindquist (TN/EAB); [email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]
Subject: RE: [Megaco] RTCP flow handling

Hello Jan/Albrecht,

Independent of the correct interpretation of standards, there are
definitely endpoints (VoIP Phones and Home Gateways) that do not send RTCP.

Regards,

Reinaldo

> -----Original Message-----
> From: Jan Lindquist (TN/EAB) [mailto:[email-masked]]
> Sent: Thursday, October 26, 2006 11:58 PM
> To: [email-masked]
> Cc: [email-masked]; EXT -
> [email-masked]; [email-masked]
> Subject: RE: [Megaco] RTCP flow handling
>

> Hello Albrecht,

> My understanding of this statement is that RTCP is mandatory in
> rfc3264:
>

> (Section 5.1 unicast streams)
> "...
> That is, the directionality of the media stream has no impact on the

> RTCP usage.
> ..."

> And the only way to turn off RTCP is using the bandwidth attribute:
> "...
>    If the bandwidth attribute is present for a stream, it indicates

> the
>    desired bandwidth that the offerer would like to receive.

> A value of
>    zero is allowed, but discouraged.  It indicates that no media

> should
>    be sent.  In the case of RTP, it would also disable all RTCP."
>

> Solutions that do not support RTCP run the risk to cause dropping

> connections because of the mechanisms that are added to H.248 for

> detecting loss of media flow. They depend on either RTP and RTCP being

> sent. In case the streammode is manipulated then RTCP is criticial to

> keep the connection up.

> So I believe RTCP is mandatory. I hope this view will be touched on

> your TISPAN report. If there are problems with this interpretation we

> need to address it.

> Regards,
> JanL

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: den 26 oktober 2006 16:15
> To: Jan Lindquist (TN/EAB)
> Cc: [email-masked]; [email-masked]; YAMAMOTO, Susumu
> Subject: RE: [Megaco] RTCP flow handling
>

> >This is not stated in any of the H.248 specifications but is part of

> >SIP offer/answer rfc that RTCP is always included regardless
> of direction.
> >Albrecht can correct me if I am wrong but I believe this
> aspects will
> >be raised in the H.248/SIP SDP interworking study in TISPAN.
>

> RTCP is OPTIONAL according RFC 3550.
> RFC 3264 is talking a lot about RTCP, but making RTCP NOT MANDATORY

> for Offer/Answer in my understanding.
> On the other side might this be a too theoretical view because I guess

> that there aren't any RTCP-less RTP end-systems anymore implemented.
> (?)
>

> We are definitely on the safe side when we explicitly state in H.248

> profile specification whether RTCP is used or not used (per default)

> for
> H.248 RTP Terminations.

> Albrecht

> PS
> See also some initial analysis (on gm/rsb) in § 5.6 of:
> http://ftp3.itu.int/av-arch/avc-site/2005-2008/0608_Ott/AVD-2856a.zip
>

> PSS
> Example for a potential RTCP-less RTP domain:
> * PES
> * RTP sessions only between H.248 MGs (AMG-to-TMG, AMG-to-AMG,

> RMG-to-TMG
> etc)
> * every RTP endpoint is controlled via H.248
> * no H.248 statistics related to RFC 3550 counters
> * RTCP feedback is not used for adapting RTP source behaviour (here:
> phy-to-RTP interworking only in MGs)
> => RTCP doesn't provide any value in such a PES NGN environment IMHO

> => you could abstain from RTCP and save RTCP resources for other stuff
>

> But the RTCP-less scenario is only a very specific use case, the

> general case is with RTCP in my opinion.
>

>                       "Jan Lindquist

>                       \(TN/EAB\)"               To:

> Albrecht SCHWARZ/DE/ALCATEL@ALCATEL, "YAMAMOTO, Susumu"

>                       <jan.lindquist@er

> <[email-masked]>

>                       icsson.com>               cc:

> <[email-masked]>, <[email-masked]>

>                                                 Subject: RE:

> [Megaco] RTCP flow handling

>                       26.10.2006 13:05

> Hello Susumu,

> You had two questions which I will try to answer.
>

> 1) On the issue of direction of RTP, RTCP is independent and should as

> you pointed at be guaranteed with a bidirectional pinhole. This is not

> stated in any of the H.248 specifications but is part of SIP

> offer/answer rfc that RTCP is always included regardless of direction.
> Albrecht can correct me if I am wrong but I believe this aspects will

> be raised in the H.248/SIP SDP interworking study in TISPAN.
>

> 2) On the issue of enforcing policing, the tman package should be used

> either on individual streams or as a combined streams. The TISPAN Ia

> profile is in the process of being updated and adding (or clarifying)

> the requirements to making the MG more media aware.
>

> Regards,
> JanL

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: den 26 oktober 2006 10:58
> To: YAMAMOTO, Susumu
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Megaco] RTCP flow handling
>

> May not answer the protocol details, but like to provide a top-level
> view:
>

> 1) Traffic policing (with gm/1) is related to H.248 STREAMs, i.e., not

> on TERMINATION-level.
>    [Traffic policing is related to ingress traffic only.]
>

> 2) RTP & RTCP could be mapped on a) a single Stream, or b) individual

> Streams.

> 3) The bitrate reservation/allocation for RTP and RTCP may depend on

> the mapping scheme.
>    [E.g., current draft WI-03080 provides an example with two
> H.248 Streams.] RTCP bitrate may be explicitly signalled, or based on

> an implicit rule ("<= 5%"). This is up to profile specs IMHO.
>

> 4) The MGC is responsible for setting the traffic policing parameter

> values, i.e., must take into account bitrate reservations and applied

> Stream-mapping scheme.

> 5) E.g., using two H.248 Streams for RTP and RTCP allows therefore to

> perform individual traffic policers per RTP and RTCP.
>

> - Albrecht

>                       "YAMAMOTO, Susumu"

>                       <yamamoto.susumu@lab         To:
> [email-masked]

>                       .ntt.co.jp>                  cc:

>                                                    Subject:

> [Megaco] RTCP flow handling
>                       26.10.2006 09:32
>

> Hi all,

> I have a question regarding RTCP flow handling which pinhole is

> created by gm/rsb specified with a RTP flow.
>

> It seems that, even in case that Stream mode of the RTP may be changed

> to SendOnly or ReceiveOnly, RTCP pinhole should still guarantee

> bidirectional communication, i.e. still SendReceive regardless of the

> mode of the RTP flow. Is my assumption correct, and any description or

> discussion for this for this in the standard ?
>

> One more point is, when gm/rsb specified, how can we enforce policing,

> i.e. rate-limit, with the RTCP pinhole ?
> Tman/pol works on summation of the rate of the RTP and RTCP flows, or

> any specific rate is provisioned for policing RTCP flow outside megaco

> protocol ?
> Please let me know if you have any discussion about this in the

> standard.

> Thanks,
> -Susumu

> --- Susumu YAMAMOTO, NTT Network Service Systems Lab.
>        +81 422 59 2744 (phone), 5636 (fax)
>

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

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

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

-------------------------------------------------------------------
Mail archive for TISPAN_WG3  can be browsed at the following url :
         http://list.etsi.org/TISPAN_WG3.html
-------------------------------------------------------------------

**** DISCLAIMER ****
http://www.belgacom.be/maildisclaimer

-------------------------------------------------------------------
Mail archive for TISPAN_WG3  can be browsed at the following url :
         http://list.etsi.org/TISPAN_WG3.html
-------------------------------------------------------------------

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