Subject: H.248.40: maximum notification rate; RE: [Megaco] RTCP flow handling

From: [email-masked]
Date: Tue, 12 Dec 2006 20:40:22 +0100

Dal,

this potential issue was discussed:
       the maximum notification rate is 1/dt per second per adid-enabled
termination.

The value of dt is under control of the MGC.
It depends on the specific use case of the adid package (see Appendices in
H.248.40), i.e., the time-scale of dt.
There might be use case with dt > Context holding times, i.e. rather low
notification rates.
But I do agree that there might be other use cases like the "deadlock
latching detection" (perhaps with dt < one second).

I think that the use cases should be more detailed in profile
specifications.

Regards,
Albrecht

                      "dal chohan"                                                                                                      
                      <[email-masked]         To:      <[email-masked]>, <[email-masked]>                
                      o.uk>                    cc:                                                                                      
                                               Subject: RE: [Megaco] RTCP flow handling                                                 
                      12.12.2006 20:07                                                                                                  

Hi Albrecht,

What concerns me about H.248.40 is that if there is a failure in the IP
backbone, then the controller will be flooded with H.248 "addid/ipstop"
observed events and this could cause overload/congestion collapse of the
controller.

To overcome this problem the package procedures should really specify some
kind of flow control mechanism for reporting these observed events and
avoid
flooding the controller.

Ideally it would sense to report just one event per far end destination IP
address associated with the RTP flow contained in the remote descriptor.
But
this will require some changes to H.248.40.

Any thoughts ?????

Regards,

Dal.

-----Original Message-----
From: Albrecht Schwarz [mailto:[email-masked]]
Sent: 29 October 2006 06:04
To: [email-masked]
Subject: Re: [Megaco] RTCP flow handling

(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
-------------------------------------------------------------------

-------------------------------------------------------------------
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

---

From: "Kevin Boyle" <[email-masked]>
Date: Tue, 12 Dec 2006 15:50:09 -0500

Keep in mind that the MGC is always able to deactivate detection of the
events if it is getting flooded.  How the MGC handles this is an
implementation detail.

Kevin 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] 
Sent: Tuesday, December 12, 2006 2:40 PM
To: dal chohan
Cc: [email-masked]; [email-masked];
[email-masked]
Subject: H.248.40: maximum notification rate; RE: [Megaco] RTCP flow
handling

Dal,

The value of dt is under control of the MGC.
It depends on the specific use case of the adid package (see Appendices
in H.248.40), i.e., the time-scale of dt.
There might be use case with dt > Context holding times, i.e. rather low
notification rates.
But I do agree that there might be other use cases like the "deadlock
latching detection" (perhaps with dt < one second).

Regards,
Albrecht

                      "dal chohan"

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

                      o.uk>                    cc:

                                               Subject: RE: [Megaco]
RTCP flow handling                                                 
                      12.12.2006 20:07

Hi Albrecht,

To overcome this problem the package procedures should really specify
some kind of flow control mechanism for reporting these observed events
and avoid flooding the controller.

Ideally it would sense to report just one event per far end destination
IP address associated with the RTP flow contained in the remote
descriptor.
But
this will require some changes to H.248.40.

Any thoughts ?????

Regards,

Dal.

-----Original Message-----
From: Albrecht Schwarz [mailto:[email-masked]]
Sent: 29 October 2006 06:04
To: [email-masked]
Subject: Re: [Megaco] RTCP flow handling

(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.

Kind regards

Jan Van Geel

-----Original Message-----

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]

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

**** DISCLAIMER ****

---

From: [email-masked]
Date: Wed, 13 Dec 2006 08:35:59 +0100

Right.

It remains the case when media inactivity is detected in "parallel"
successfully on k (IP) terminations.
This may lead to a "group arrival" (with a group size of k) of
NOTIFY.requests at the MGC, independent of the dt value!
Assuming that there is a real use case with parallel detected events on a
group of terminations, then there'll be a short-term traffic peak towards
MGC.
Question is then, whether the MG should shape that peak (e.g., based on a
maximum allowed notification rate).

Albrecht

                      "Kevin Boyle"                                                                                                     
                      <[email-masked]         To:      <[email-masked]>, "dal chohan" <[email-masked]>        
                      om>                      cc:      <[email-masked]>, <[email-masked]>                                   
                                               Subject: RE: H.248.40: maximum notification rate; RE: [Megaco] RTCP flow handling        
                      12.12.2006 21:50                                                                                                  

Kevin

-----Original Message-----

Dal,

Regards,
Albrecht

                      "dal chohan"

                      <[email-masked]         To:

                      o.uk>                    cc:

                                               Subject: RE: [Megaco] RTCP
flow handling
                      12.12.2006 20:07

Hi Albrecht,

To overcome this problem the package procedures should really specify some
kind of flow control mechanism for reporting these observed events and
avoid flooding the controller.

Any thoughts ?????

Regards,

Dal.

-----Original Message-----
From: Albrecht Schwarz [mailto:[email-masked]]
Sent: 29 October 2006 06:04
To: [email-masked]
Subject: Re: [Megaco] RTCP flow handling

(2) RTCP in Ia Profile
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.

- Albrecht

                      "Jan Lindquist

                      (TN/EAB)"                 To:
[email-masked]

                      <jan.lindquist@ER         cc:

                      27.10.2006 14:32

                      Please respond to

                      "Jan Lindquist

                      (TN/EAB)"

Hello Jan,

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.

Kind regards

Jan Van Geel

-----Original Message-----

Hello Reinaldo,

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]

Hello Jan/Albrecht,

Regards,

Reinaldo

**** DISCLAIMER ****

---

From: "Arturo Martin De Nicolas \(AC/EDD\)" <[email-masked]>
Date: Wed, 13 Dec 2006 10:51:34 +0100

Hi,

The problem is not specific to H.248.40. There are other events that could be triggered in big numbers just by one single failure, e.g. g/cause.

But it's the MG's responsibility to restrict sudden bursts of notifications to the MGC.

H.248.1 v3:
---
Protection against Notify avalanche

If a circumstance arises at an MG where a substantial number of notifications accumulate, either because of transmission difficulties or because the MG recognized a number of events in a short time period, the MG should send the notifications in a restricted manner until the backlog is cleared.
---

BR,
Arturo

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, December 13, 2006 8:36 AM
To: Kevin Boyle
Cc: [email-masked]; [email-masked]; dal chohan
Subject: RE: H.248.40: maximum notification rate;RE: [Megaco] RTCP flow handling

Right.

It remains the case when media inactivity is detected in "parallel"
successfully on k (IP) terminations.
This may lead to a "group arrival" (with a group size of k) of NOTIFY.requests at the MGC, independent of the dt value!
Assuming that there is a real use case with parallel detected events on a group of terminations, then there'll be a short-term traffic peak towards MGC.
Question is then, whether the MG should shape that peak (e.g., based on a maximum allowed notification rate).

Albrecht

                      "Kevin Boyle"                                                                                                     

Keep in mind that the MGC is always able to deactivate detection of the events if it is getting flooded.  How the MGC handles this is an implementation detail.

Kevin

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
Sent: Tuesday, December 12, 2006 2:40 PM
To: dal chohan
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: H.248.40: maximum notification rate; RE: [Megaco] RTCP flow handling

Dal,

this potential issue was discussed:
       the maximum notification rate is 1/dt per second per adid-enabled termination.

The value of dt is under control of the MGC.
It depends on the specific use case of the adid package (see Appendices in H.248.40), i.e., the time-scale of dt.
There might be use case with dt > Context holding times, i.e. rather low notification rates.
But I do agree that there might be other use cases like the "deadlock latching detection" (perhaps with dt < one second).

I think that the use cases should be more detailed in profile specifications.

Regards,
Albrecht

                      "dal chohan"

                      <[email-masked]         To:

                      o.uk>                    cc:

Hi Albrecht,

What concerns me about H.248.40 is that if there is a failure in the IP backbone, then the controller will be flooded with H.248 "addid/ipstop"
observed events and this could cause overload/congestion collapse of the controller.

To overcome this problem the package procedures should really specify some kind of flow control mechanism for reporting these observed events and avoid flooding the controller.

Ideally it would sense to report just one event per far end destination IP address associated with the RTP flow contained in the remote descriptor.
But
this will require some changes to H.248.40.

Any thoughts ?????

Regards,

Dal.

-----Original Message-----
From: Albrecht Schwarz [mailto:[email-masked]]
Sent: 29 October 2006 06:04
To: [email-masked]
Subject: Re: [Megaco] RTCP flow handling

(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:

                      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.

Kind regards

Jan Van Geel

-----Original Message-----

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

**** DISCLAIMER ****

---

From: Christian Groves <[email-masked]>
Date: Wed, 13 Dec 2006 22:43:01 +1100

G'Day,

If Notify Avalanche is seen as a problem then the H.248.1v3 Annex E.15  
Notification Behaviour package can be used. It was designed especially 
for the case that the MGC is being overloaded and gives a means to 
handle this.

I would encourage people to start moving toward v3 implementations as it 
does contain some important functionality such as the above, turning 
on/off/resetting individual statistics, statistics on streams etc...

Regards, Christian

---

From: "Arturo Martin De Nicolas \(AC/EDD\)" <[email-masked]>
Date: Wed, 13 Dec 2006 15:06:02 +0100

Hi Christian,

Notification Behaviour flag and Annex E.15 may be one way.  However, a couple of issues I see with it:

a) If I am not wrong, notifications that are suppressed with the NotificationBehaviour mechanism are simply lost. This may be perfectly acceptable with e.g. the off hook event in an AGW, as a way to reject new calls in congestion situations, but it may be less acceptable in cases of g/cause or adid/ipstop events, which normally could trigger release of call/session in the MGC. 

b) A sudden user plane failure could cause thousands of events practically instantaneously. The NotifyBehaviour mechanism may not prove quick enough to avoid the congestion in the MGC, as by the time the MGC may react, the burst has already been generated.

So I think it is important that MG comply with clause 9.3 of H.248.1.

Cheers,
Arturo

-----Original Message-----
From: Christian Groves [mailto:[email-masked]] 
Sent: Wednesday, December 13, 2006 12:43 PM
To: Arturo Martin De Nicolas (AC/EDD)
Cc: [email-masked]; Kevin Boyle; [email-masked]; [email-masked]; dal chohan
Subject: [Suspected Spam] Re: H.248.40: maximum notification rate; RE: [Megaco] RTCP flow handling

G'Day,

If Notify Avalanche is seen as a problem then the H.248.1v3 Annex E.15 Notification Behaviour package can be used. It was designed especially for the case that the MGC is being overloaded and gives a means to handle this.

I would encourage people to start moving toward v3 implementations as it does contain some important functionality such as the above, turning on/off/resetting individual statistics, statistics on streams etc...

Regards, Christian