Subject: [AVT] Suggested text for RAMS response codes

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Sat, 21 Aug 2010 03:04:06 -0700

Please provide your feedback if any by Wednesday. Then, we will include these in the revision.

Thanks, acbegen.

100   Parameter update for RAMS session: 
This is used when the BRS wants to update a value that was sent earlier to the RTP_Rx. 

200   RAMS request has been accepted: 
This is used when the server accepts the RAMS request.

201   Unicast burst has been completed: 
This is used when the unicast burst has been completed and the BRS wants to notify the RTP_Rx.

400   Invalid RAMS-R message syntax: 
This is used when the RAMS-R message is improperly formatted.

401   Invalid min buffer requirement in RAMS-R message: 
This is used when the minimum RAMS buffer fill requirement value indicated in the RAMS-R message is invalid.
 
402   Invalid max buffer requirement in RAMS-R message:
This is used when the maximum RAMS buffer fill requirement value indicated in the RAMS-R message is invalid.

403   Invalid max bitrate requirement in RAMS-R message: 
This is used when the maximum receive bitrate value indicated in the RAMS-R message is invalid.

500   An unspecified BRS internal error has occurred: 
This is used when the BRS has experienced an internal error and cannot respond to the RAMS request.

501   BRS has insufficient bandwidth to start RAMS session:
This is used when the BRS does not have enough bandwidth to send the unicast burst stream.

502   Burst is terminated due to network congestion:
This is used when the BRS terminates the unicast burst stream due to network congestion.

503   BRS has insufficient CPU cycles to start RAMS session:
This is used when the BRS does not have enough CPU resources to send the unicast burst stream.

504   RAMS functionality is not available on BRS:
This is used when the BRS does not support sending a unicast burst stream.

505   RAMS functionality is not available for RTP_Rx:
This is used when the requesting RTP_Rx is not eligible to receive a unicast burst stream.

506   RAMS functionality is not available for the requested multicast stream:
This is used when RAMS functionality is not enabled for the requested multicast stream.

507   BRS has no valid starting point available for the requested multicast stream:
This is used when the BRS cannot find a valid starting point satisfying the RTP_Rx's requirements.
 
508   BRS has no reference information available for the requested multicast stream:
This is used when the BRS cannot find the essential reference information for the requested multicast stream.

509   BRS has no RTP stream matching the requested SSRC:
This is used when the BRS cannot match the requested SSRC to any of the streams it is serving.

510   RAMS request to acquire the entire session has been denied:
This is used when the BRS cannot serve the requested entire session.

511   Only the preamble information is sent:
This is used when the BRS sends only the preamble information but not the whole unicast burst stream.

512   RAMS request has been denied due to a policy:
This is used when the RAMS request is denied due to a policy specified for the requested multicast stream, requesting RTP_Rx or this particular BRS.

---

From: "Van Caenegem, Tom (Tom)" <[email-masked]>
Date: Mon, 23 Aug 2010 10:02:46 +0200

Hi Ali,

Response codes are OK for me. I have two remaining remarks around response code usage:

1)In section 6.2, step 3, we have:

"Accept Responses:  BRS MUST send at least one separate RAMS-I
           message with the appropriate response code for each primary
           multicast stream that has been requested by RTP_Rx and will
           be served by BRS." 

Maybe it would be better to name explicit the appropriate response codes here: it is either  0  or 200 (and where we add also in the text that a RTP Rx must parse anyhow the TLVs in a RAMS-I that has private response code 0).

2)If there are different error conditions (where different appropriate response codes apply) that lead to the BRS not accepting the RAMS request, is the BRS then supposed to send those different RAMS-I mesages (with different 400/500/0 response codes)? I would say not, and perhaps it makes sense to explicitly state that (i.e. the BRS can pick out only one error response code) for the RAMS-I message.

Tom 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ali C. Begen (abegen)
Sent: zaterdag 21 augustus 2010 12:04
To: [email-masked]
Subject: [AVT] Suggested text for RAMS response codes

Thanks, acbegen.

 

 

512   RAMS request has been denied due to a policy:
This is used when the RAMS request is denied due to a policy specified for the requested multicast stream, requesting RTP_Rx or this particular BRS.
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www.ietf.org/mailman/listinfo/avt

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 23 Aug 2010 03:36:06 -0700

OK on both points. One reject code is sufficient.

-acbegen

> From: Van Caenegem, Tom (Tom) [mailto:[email-masked]]
> Sent: Monday, August 23, 2010 11:03 AM
> To: Ali C. Begen (abegen); [email-masked]
> Subject: RE: Suggested text for RAMS response codes
> 
> Hi Ali,
> 
> Maybe it would be better to name explicit the appropriate response codes here: it is either  0  or 200 (and where we add also
> in the text that a RTP Rx must parse anyhow the TLVs in a RAMS-I that has private response code 0).
> 
> 2)If there are different error conditions (where different appropriate response codes apply) that lead to the BRS not
> accepting the RAMS request, is the BRS then supposed to send those different RAMS-I mesages (with different 400/500/0
> response codes)? I would say not, and perhaps it makes sense to explicitly state that (i.e. the BRS can pick out only one error
> response code) for the RAMS-I message.
> 
> Tom
> 
> 
>