Subject: FW: [Megaco] RTCP flow handling

From: "Reinaldo Penno" <[email-masked]>
Date: Fri, 27 Oct 2006 17:53:41 -0400

In the specific case of SIP endpoints/home gateways when a session (call/videocall) is put on hold, a re-INVITE is sent to the other send with c = 0.0.0.0 (old style) or attribute a=sendonly. So, the other end definitely knows the call is on hold because it will answer (in the case of SIP) with a 200OK. 

SIP endpoints in general _do not_ rely on the receipt of RTP/RTCP to detect if the session is still active. For this very reason RFC 4028 was published (Session Timers in the Session Initiation Protocol (SIP)) 

So, IMHO any A/C/I-BGF in the middle that install gates/termination/whatever for media triggered by SIP also should _not_ rely blindly on the receipt of RTCP/RTCP to detect that the connection is down. The fact that session timers exist should be taken into account and override any RTP/RTCP specific behavior even if no RTP/RTCP is received for a specific session.

Regards,

Reinaldo

> -----Original Message-----
> From: Jan Lindquist (TN/EAB) [mailto:[email-masked]]
> Sent: Friday, October 27, 2006 4:26 AM
> 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
> -------------------------------------------------------------------
> 

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

---

From: Christian Groves <[email-masked]>
Date: Mon, 30 Oct 2006 12:21:34 +1100

I think this whole discussion shows that its not really up to the H.248 
specifications to mandate the use of RTCP. RTCP is used within the 
context of a wider network coupled with control/session control and 
other techniques to maintain a certain QoS (e.g. you could remove H.248 
from the network picture and still have the same problems). Its when 
defining this overall network and the capabilities of a MG the use of 
RTCP needs to be determined.
 
Once the use is clarified H.248 can then send a specific indication of 
RTCP support. This is why I support a stand alone package so that it may 
be used by a wider group of people rather than having it coupled with 
the ETSI Gate management package.

Christian

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Mon, 30 Oct 2006 10:44:51 -0500

Your assessment is a good one. I just wanted to point out some related 
SG 11 work (for which I am Editor) that defines the protocol from which 
the H.248 gate control protocol would take its information. This is 
Q.rcp.1 (soon to be Q.3301), across the Rs interface. It corresponds to 
Gq' in ETSI TISPAN. The basic point is that Q.rcp.1 (and Gq') allow for 
explicit or implicit allocation of bandwidth to RTCP, at the option of 
the invoking service control element.

Speaking as an AVT co-Chair, I do urge the implementation of RTCP 
because more and more features are being defined that depend on its 
availability.

> the ETSI Gate management package.
...