Subject: [siprec] Multiplexing RTP & RTCP in SIPREC

From: "Hutton, Andrew" <[email-masked]>
Date: Wed, 4 Jan 2012 17:38:28 +0100

Hi,

During IETF82 we discussed RTP & RTCP Multiplexing (RFC 5761) and whether what we should say about this in the SIPREC protocol draft the conclusion was that this could be supported but we needed to confirm this.

I am not sure we really need to say anything about this in the protocol draft since support for it would of course be optional like many other SDP attributes and I don't see any specific relevant to SIPREC other than it being useful in reducing the number of ports used at the SRS and SRC.

I think it would be ok for the protocol draft to say that support for this would be a good idea but don't think we should make it mandatory.

Any comments?

Regards
Andy

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Wed, 4 Jan 2012 11:12:12 -0800

Hi Andy,

I agree with you, and I do not see a need for us to make RFC 5761 RTP &
RTCP multiplexing MANDATORY. There is currently no recommendation for it
in draft-eckelcu-siprec-rtp-rec. It is mentioned only to differentiate
it from symmetric RTP/RTCP, which is MANDATORY when sending RTP/RTCP.

Cheers,
Charles

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Hutton, Andrew
> Sent: Wednesday, January 04, 2012 8:38 AM
> To: [email-masked]
> Subject: [siprec] Multiplexing RTP & RTCP in SIPREC
> 
> Hi,
> 
> During IETF82 we discussed RTP & RTCP Multiplexing (RFC 5761) and
> whether what we should say about this in the SIPREC protocol draft the
> conclusion was that this could be supported but we needed to confirm
> this.
> 
> I am not sure we really need to say anything about this in the
protocol
> draft since support for it would of course be optional like many other
> SDP attributes and I don't see any specific relevant to SIPREC other
> than it being useful in reducing the number of ports used at the SRS
> and SRC.
> 
> I think it would be ok for the protocol draft to say that support for
> this would be a good idea but don't think we should make it mandatory.
> 
> Any comments?
> 
> Regards
> Andy
> 
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 04 Jan 2012 14:26:27 -0500

On 1/4/12 2:12 PM, Charles Eckel (eckelcu) wrote:
> Hi Andy,
>
> I agree with you, and I do not see a need for us to make RFC 5761 RTP&

I agree it probably doesn't make sense to make it mandatory, nor to ban 
it. So from a spec perspective it may not be necessary to mention it at all.

But given that there might be a large number of streams, it could be 
desirable to use. I guess the question would be whether we want to make 
it mandatory to support but optional to use.

	Thanks,
	Paul

>> Subject: [siprec] Multiplexing RTP&  RTCP in SIPREC
>>
>> Hi,
>>
>> During IETF82 we discussed RTP&  RTCP Multiplexing (RFC 5761) and
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec
>

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Thu, 5 Jan 2012 01:02:12 +0000

Paul,

My understanding about rtcp-mux (RFC5761) attribute is optional to support in SIPREC as per Sec 5.1.1 of RFC 5761 statement

" If the answer does not contain an "a=rtcp-mux" attribute, the offerer
   MUST NOT multiplex RTP and RTCP packets on a single port.  Instead,
   it should send and receive RTCP on a port allocated according to the
   usual port-selection rules (either the port pair, or a signalled port
   if the "a=rtcp:" attribute [10] is also included).  This will occur
   when talking to a peer that does not understand the "a=rtcp-mux"
   attribute."

Here in case SRS does not support RFC 5761, the answer to SRC will not have "a=rtcp-mux" and SRC will fallback as per RFC suggestion.

Thanks
Partha

>From: [email-masked] [mailto:[email-masked]] On Behalf
>Of Paul Kyzivat
>Sent: Thursday, January 05, 2012 12:56 AM
>To: [email-masked]
>Subject: Re: [siprec] Multiplexing RTP & RTCP in SIPREC
>
>> RTCP multiplexing MANDATORY. There is currently no recommendation for
>> it in draft-eckelcu-siprec-rtp-rec. It is mentioned only to
>> differentiate it from symmetric RTP/RTCP, which is MANDATORY when
>sending RTP/RTCP.
>
>>> whether what we should say about this in the SIPREC protocol draft
>>> the conclusion was that this could be supported but we needed to
>>> confirm this.
>>>
>>> draft since support for it would of course be optional like many
>>> other SDP attributes and I don't see any specific relevant to SIPREC
>>> other than it being useful in reducing the number of ports used at
>>> the SRS and SRC.
>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 04 Jan 2012 20:21:08 -0500

> Here in case SRS does not support RFC 5761, the answer to SRC will not have "a=rtcp-mux" and SRC will fallback as per RFC suggestion.

This implies that the offerer must reserve a port on which to receive 
rtcp even if it is proposing rtcp-mux. Then presumably if the rtcp-mux 
is accepted it can free up that port.

And even though RTP is one-way for siprec, the RTCP is two-way, so this 
can't be avoided for siprec.

	Thanks,
	Paul

>> Subject: Re: [siprec] Multiplexing RTP&  RTCP in SIPREC
>>

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Thu, 5 Jan 2012 01:33:34 +0000

Correction - "Optional to support" instead "optional to use" 

>From: Ravindran, Parthasarathi
>Sent: Thursday, January 05, 2012 7:00 AM
>To: 'Paul Kyzivat'
>Cc: [email-masked]
>Subject: RE: [siprec] Multiplexing RTP & RTCP in SIPREC
>
>Paul,
>
>We are in the same page for having two port allocation for RTCP when the
>offer is sent by SRC/SRS and make it to single port after the
>negotiation is done with answer. These kind of SIPREC implementation is
>inline with any other RFC 5761 implementation. Please let me know
>whether it is fine to make RFC 5761 as optional to support for SIPREC.
>
>Thanks
>Partha
>
>>From: Paul Kyzivat [mailto:[email-masked]]
>>Sent: Thursday, January 05, 2012 6:51 AM
>>To: Ravindran, Parthasarathi
>>Cc: [email-masked]
>>> My understanding about rtcp-mux (RFC5761) attribute is optional to
>>> support in SIPREC as per Sec 5.1.1 of RFC 5761 statement
>>>
>>> Here in case SRS does not support RFC 5761, the answer to SRC will
>>> not
>>have "a=rtcp-mux" and SRC will fallback as per RFC suggestion.
>>
>>>> Behalf Of Paul Kyzivat
>>>>> I agree with you, and I do not see a need for us to make RFC 5761
>>>>> RTP& RTCP multiplexing MANDATORY. There is currently no
>>>>> recommendation for it in draft-eckelcu-siprec-rtp-rec. It is
>>>>> mentioned only to differentiate it from symmetric RTP/RTCP, which
>>>>> is MANDATORY when
>>>> sending RTP/RTCP.
>>>>
>>>> I agree it probably doesn't make sense to make it mandatory, nor to
>>>> ban it. So from a spec perspective it may not be necessary to
>>>> mention it at all.
>>>>
>>>> desirable to use. I guess the question would be whether we want to
>>>> make it mandatory to support but optional to use.
>>>>
>>>> 	Thanks,
>>>> 	Paul
>>>>
>>>>> Cheers,
>>>>> Charles
>>>>>
>>>>>
>>>>>
>>>>>> other SDP attributes and I don't see any specific relevant to
>>>>>> SIPREC other than it being useful in reducing the number of ports
>>>>>> used at the SRS and SRC.
>>>>>>
>>>>>> I think it would be ok for the protocol draft to say that support
>>>>>> for this would be a good idea but don't think we should make it
>>>> mandatory.
>>>>>>
>>>>>> Any comments?
>>>>>>
>>>>>> Regards
>>>>>> Andy
>>>>>>
>>>>>>

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Thu, 5 Jan 2012 01:30:40 +0000

Paul,

We are in the same page for having two port allocation for RTCP when the offer is sent by SRC/SRS and make it to single port after the negotiation is done with answer. These kind of SIPREC implementation is inline with any other RFC 5761 implementation. Please let me know whether it is fine to make RFC 5761 as optional to use for SIPREC.

Thanks
Partha

>> Here in case SRS does not support RFC 5761, the answer to SRC will not
>>>> mentioned only to differentiate it from symmetric RTP/RTCP, which is
>>>> MANDATORY when
>>> sending RTP/RTCP.
>>>
>>> ban it. So from a spec perspective it may not be necessary to mention
>>> it at all.
>>>

---

From: "Hutton, Andrew" <[email-masked]>
Date: Thu, 19 Jan 2012 13:10:06 +0100

Hi All,

I am still of the view that we should not mandate support or the use of RFC 5761 in SIPREC.

Obviously in scenarios where there are a large number of recording sessions between the SRC and SRS it may make sense to make use of this that is the case for any scenario in which there are a large number of active sessions. We should not burden all SIPREC implementation with having to implement RFC 5761.

I would be happy for the architecture draft to provide a hint towards using RFC 5761 but don't think it needs to be mentioned in the protocol draft.

Regards
Andy (As an individual).

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Thu, 19 Jan 2012 08:47:55 -0800

I mostly agree, in that I do not believe we should mandate RFC 5761, nor
do I think there is a real need to call it out explicitly in the
protocol in the draft. It is mentioned in draft-eckel-siprec-rtp-rec-03
only for the purpose of differentiating it from symmetric RTP and
symmetric RTCP, which are required. To me this means that, as with many
other things, support for RFC 5761 RTP/RTCP multiplexing is optional,
and there is nothing we need to say about it explicitly.
However, my feeling is that if we were to decide to add a hint at RFC
5761 RTP/RTCP multiplexing in the architecture draft, then we actually
do need to deal with it in the protocol draft, and therefore in
draft-eckel-siprec-rtp-rec. It that point, I still feel we should not
make it required, but we could make it recommended.

Cheers,
Charles

> Sent: Thursday, January 19, 2012 4:10 AM
> To: Ravindran, Parthasarathi; Paul Kyzivat
> Cc: [email-masked]
> I am still of the view that we should not mandate support or the use
of
> RFC 5761 in SIPREC.
> 
> Obviously in scenarios where there are a large number of recording
> sessions between the SRC and SRS it may make sense to make use of this
> that is the case for any scenario in which there are a large number of
> active sessions. We should not burden all SIPREC implementation with
> having to implement RFC 5761.
> 
> I would be happy for the architecture draft to provide a hint towards
> using RFC 5761 but don't think it needs to be mentioned in the
protocol
> draft.
> Behalf Of Ravindran, Parthasarathi
> >>>     it should send and receive RTCP on a port allocated according
> to
> >>the
> >>>     usual port-selection rules (either the port pair, or a
> signalled
> >>port

---

From: "Hutton, Andrew" <[email-masked]>
Date: Thu, 19 Jan 2012 20:07:08 +0100

Hi Charles,

I was forgetting that your RTP stuff will go in to the protocol draft I am ok with the text in your draft.

A hint in the architecture draft just to make people think about the possibility would be good enough for me but I would also be happy if we said nothing at all about RFC 5761 in the architecture draft.

I don't see the value in making it recommended.

Regards
Andy

-----Original Message-----
From: Charles Eckel (eckelcu) [mailto:[email-masked]] 
Sent: 19 January 2012 16:48
To: Hutton, Andrew; Ravindran, Parthasarathi; Paul Kyzivat
Cc: [email-masked]
Subject: RE: [siprec] Multiplexing RTP & RTCP in SIPREC

Cheers,
Charles

of
protocol

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 19 Jan 2012 14:43:32 -0500

RECOMMENDED is the same as SHOULD. And so, if we were to use it then 
should specify the criteria for doing it or not. Without anything like 
that it is not especially useful.

We have more important fish to fry, so I'm ok with doing nothing.

	Thanks,
	Paul

On 1/19/12 2:07 PM, Hutton, Andrew wrote:
> Subject: RE: [siprec] Multiplexing RTP&  RTCP in SIPREC
>
>>> Subject: RE: [siprec] Multiplexing RTP&  RTCP in SIPREC
>>>
>>> Paul,
>>>

---

From: "Henry Lum" <[email-masked]>
Date: Fri, 20 Jan 2012 17:57:56 -0800

I tend to agree that we should leave it alone and not mention it in the
protocol draft. Mentioning it to the protocol draft implies that
multiplexing becomes mandatory to support, which I don't think it is the
intention here.

Regards,
Henry

> Sent: January-19-12 2:07 PM
> To: Charles Eckel (eckelcu); Ravindran, Parthasarathi; Paul Kyzivat
> Cc: [email-masked]
> I was forgetting that your RTP stuff will go in to the protocol draft
I
> am ok with the text in your draft.
> 
> A hint in the architecture draft just to make people think about the
> possibility would be good enough for me but I would also be happy if
we
> said nothing at all about RFC 5761 in the architecture draft.
> 
> > >We are in the same page for having two port allocation for RTCP
when
> > >negotiation is done with answer. These kind of SIPREC
implementation
> > is
> > >>>     if the "a=rtcp:" attribute [10] is also included).  This
will
> > >>occur
> > >>rtcp even if it is proposing rtcp-mux. Then presumably if the
rtcp-
> > mux
> > >>>> I agree it probably doesn't make sense to make it mandatory,
nor
> > >>>> But given that there might be a large number of streams, it
> could
> > be
> > >>>>>> From: [email-masked]
[mailto:[email-masked]]
> > On
> > >>>>>> During IETF82 we discussed RTP&   RTCP Multiplexing (RFC
5761)
> > and

-------------------------------------------------------------------------------------------------------------------
CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential and proprietary information of Alcatel-Lucent and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or its affiliated entities.