Subject: [Megaco] RTCP flow handling

From: "YAMAMOTO, Susumu" <[email-masked]>
Date: Thu, 26 Oct 2006 16:32:55 +0900

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

---

From: [email-masked]
Date: Thu, 26 Oct 2006 10:57:45 +0200

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,

Thanks,
-Susumu

---

From: "Kevin Boyle" <[email-masked]>
Date: Thu, 26 Oct 2006 06:08:56 -0400

These are all very good questions, and would need to be addressed in any
gate management work that is produced.  It appears that the existing
gate management package does not address these items.

SG16 meets next month and is working on adapting the ETSI TISPAN package
to meet the additional requirements brought to Q3/16.  These items sound
like excellent additions to the list of requirements needing to be
addressed explicitly in the package work being performed.

I think Albrecht's reply provides good information that can be used to
draft text addressing these items in the packages being produced by
SG16.  At the meeting I will encourage the delegates to ensure that
these questions are answered in any work that is ratified.

Kevin 

-----Original Message-----
From: YAMAMOTO, Susumu [mailto:[email-masked]] 
Sent: Thursday, October 26, 2006 3:33 AM
To: [email-masked]
Subject: [Megaco] RTCP flow handling

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

---

From: "Jan Lindquist \(TN/EAB\)" <[email-masked]>
Date: Thu, 26 Oct 2006 13:05:46 +0200

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

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.

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

Thanks,
-Susumu

---

From: [email-masked]
Date: Thu, 26 Oct 2006 16:15:22 +0200

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

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,

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

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

Thanks,
-Susumu

---

From: "Jan Lindquist \(TN/EAB\)" <[email-masked]>
Date: Fri, 27 Oct 2006 08:57:51 +0200

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

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

Hello Susumu,

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

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:

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

---

From: "Reinaldo Penno" <[email-masked]>
Date: Fri, 27 Oct 2006 04:32:51 -0400

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 

> 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]
> 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
> 
> 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
> => 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         
>                       icsson.com>               cc:      
> <[email-masked]>, <[email-masked]>                 
>                 
>                                                 Subject: RE: 
> 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
> 
>    [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: 
> 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 ?

---

From: "Kevin Boyle" <[email-masked]>
Date: Fri, 27 Oct 2006 04:39:40 -0400

I would like to point out that RFC 3264 does not apply to H.248.  H.248
has its own SDP negotiating mechanism that predates the offer/answer
model.

That being said, I am of the opinion that not using RTCP is a mistake.
However, it is hardly mandatory within H.248-controlled systems.

Kevin 

-----Original Message-----
From: Jan Lindquist (TN/EAB) [mailto:[email-masked]] 
Sent: Friday, October 27, 2006 2:58 AM
To: [email-masked]
Cc: [email-masked]; YAMAMOTO, Susumu; [email-masked]
Subject: RE: [Megaco] RTCP flow handling

Hello Albrecht,

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

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

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

Albrecht

PS

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

 

                      "Jan Lindquist

                      \(TN/EAB\)"               To:      Albrecht
SCHWARZ/DE/ALCATEL@ALCATEL, "YAMAMOTO, Susumu"                       
                      <jan.lindquist@er
<[email-masked]>

                      icsson.com>               cc:

                                                Subject: RE: [Megaco]
RTCP flow handling                                               
                      26.10.2006 13:05

Hello Susumu,

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

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

Thanks,
-Susumu

---

From: "Jan Lindquist \(TN/EAB\)" <[email-masked]>
Date: Fri, 27 Oct 2006 13:25:42 +0200

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,

Regards,

Reinaldo 

> 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
> 
> aspects will
> H.248 Streams.] RTCP bitrate may be explicitly signalled, or based on 
> an implicit rule ("<= 5%"). This is up to profile specs IMHO.
> 
> I have a question regarding RTCP flow handling which pinhole is 
> created by gm/rsb specified with a RTP flow.
>