Subject: [MMUSIC] [Technical Errata Reported] RFC3264 (5177)

From: RFC Errata System <[email-masked]>
Date: Fri, 3 Nov 2017 11:42:52 -0700 (PDT)

The following errata report has been submitted for RFC3264,
"An Offer/Answer Model with Session Description Protocol (SDP)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5177

--------------------------------------
Type: Technical
Reported by: Sandeep Kumar Aitha <[email-masked]>

Section: 5.1

Original Text
-------------
Section 5.1 says:
However, for sendonly and sendrecv streams, the answer might indicate
different payload type numbers for the same codecs, in which case,
the offerer MUST send with the payload type numbers from the answer.

Section 6.2 says:
In the case of RTP, if a particular codec was referenced with a
specific payload type number in the offer, that same payload type
number SHOULD be used for that codec in the answer.

Corrected Text
--------------
Only one of the above statements can be correct.

Notes
-----
Above two statements are conflicting.
The answerer should be able to either map the payload type to a different codec or not.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC3264 (draft-ietf-mmusic-sdp-offer-answer-02)
--------------------------------------
Title               : An Offer/Answer Model with Session Description Protocol (SDP)
Publication Date    : June 2002
Author(s)           : J. Rosenberg, H. Schulzrinne
Category            : PROPOSED STANDARD
Source              : Multiparty Multimedia Session Control RAI
Area                : Real-time Applications and Infrastructure
Stream              : IETF
Verifying Party     : IESG

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 3 Nov 2017 16:41:51 -0400

Just to get a head start on discussion of this, comment at end.

> "An Offer/Answer Model with Session Description Protocol (SDP)".

These statements are not in conflict. "SHOULD" is different from "MUST", 
in that it may be violated with valid reason. There are a variety of 
reasons why an answerer might have to violate the SHOULD. And in this 
case the offerer MUST send media using the PT in the answer, while the 
answerer MUST send media using the PT from the offer.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 8 Nov 2017 14:03:38 -0500

On 11/4/17 12:01 AM, Sandeep Kumar Aitha wrote:
> Hi Paul ,
> 
> Thanks for the commnets.
> Can you please point me to the variety of reasons in which the answerer might change the mapping of codecs.

Can someone else chime in here? I can't recall. I think there were cases 
related to interoperation with H.323, but I don't know anything about H.323.

	Thanks,
	Paul

> Best Regards,
> Sandeep Kumar Aitha.
> 
> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Saturday, November 04, 2017 2:12 AM
> To: Sandeep Kumar Aitha <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [MMUSIC] [Technical Errata Reported] RFC3264 (5177)
> 
>> The following errata report has been submitted for RFC3264, "An
>> Offer/Answer Model with Session Description Protocol (SDP)".
>>
>> different payload type numbers for the same codecs, in which case, the
>> offerer MUST send with the payload type numbers from the answer.
>>
>> Section 6.2 says:
> These statements are not in conflict. "SHOULD" is different from "MUST", in that it may be violated with valid reason. There are a variety of reasons why an answerer might have to violate the SHOULD. And in this case the offerer MUST send media using the PT in the answer, while the answerer MUST send media using the PT from the offer.
> 
> 	Thanks,
> 	Paul
>

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 08 Nov 2017 22:08:14 -0500

Paul Kyzivat <[email-masked]> writes:
>> Can you please point me to the variety of reasons in which the
>> answerer might change the mapping of codecs.
>

In regard to the erratum for the RFC, why a device might deviate from
using the same payload type numbers isn't particularly relevant.  As
Paul says, it is a strict requirement that "the offerer MUST send with
the payload type numbers from the answer".  And that behavior of a
device can be test straightforwardly.  That a device should prefer to
use the same payload type numbers in its answer that it received in the
offer is not directly enforcable, of course, but is a guide to
implementors.

I believe Paul is right that in some instances of interworking with
H.323, having different payload type numbers in the two directions can't
be (easily) avoided.  But I do not know the details.  The only RFC with
an obvious title, RFC 4123, does not seem to discuss payload type
numbers.

One situation where a device may not be free in selecting payload type
numbers is when it is carrying out third-party call control and passing
offers and answers between other devices.  See for example RFC 3725 and
RFC 7088, especially the hair-splitting analysis in RFC 7088 section
2.8.

Dale

---

From: Gunnar Hellström <[email-masked]>
Date: Thu, 9 Nov 2017 07:03:18 +0100

Den 2017-11-08 kl. 20:03, skrev Paul Kyzivat:
> Can someone else chime in here? I can't recall. I think there were 
> cases related to interoperation with H.323, but I don't know anything 
> about H.323.
I can only agree that the exception is because of H.323. This sentence 
is further down in section 5.1 of RFC 3264:
" Different payload type numbers may be needed in each direction because 
of interoperability concerns with H.323."

I have however seen a number of SIP implementations with no clear 
relation to H.323 using the exception. So, it is best to keep on 
implementing the offering side for cases when the answering side just 
selects its own Payload Type numbers and ignores the SHOULD for keeping 
them equal.

Regards
Gunnar
>> These statements are not in conflict. "SHOULD" is different from 
>> "MUST", in that it may be violated with valid reason. There are a 
>> variety of reasons why an answerer might have to violate the SHOULD. 
>> And in this case the offerer MUST send media using the PT in the 
>> answer, while the answerer MUST send media using the PT from the offer.
>>
>>     Thanks,
>>     Paul
>>
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

-- 
-----------------------------------------
Gunnar Hellström
Omnitor
[email-masked]
+46 708 204 288

---

From: Stephen Botzko <[email-masked]>
Date: Thu, 9 Nov 2017 14:48:42 -0500

In H.323 systems, the two senders chose dynamic payload types
independently, and there is no requirement for them to match.

In version 16 (2011) version of H.245 a mechanism was added to address this
- it allows the receiver (e.g. a non-transcoding H.323/SIP gateway) to
request the sender to switch to a specified payload value.   But support
for that mechanism is optional.

Regards
Stephen

On Thu, Nov 9, 2017 at 1:03 AM, Gunnar Hellström <
[email-masked]> wrote:

> I can only agree that the exception is because of H.323. This sentence is
> further down in section 5.1 of RFC 3264:
> I have however seen a number of SIP implementations with no clear relation
> to H.323 using the exception. So, it is best to keep on implementing the
> offering side for cases when the answering side just selects its own
> Payload Type numbers and ignores the SHOULD for keeping them equal.
>
> Regards
> Gunnar
>
>
>>     Thanks,
>>     Paul
>>
>> Best Regards,
>>> Sandeep Kumar Aitha.
>>>
>>> reasons why an answerer might have to violate the SHOULD. And in this case
>>> the offerer MUST send media using the PT in the answer, while the answerer
>>> MUST send media using the PT from the offer.
>>>
>>>     Thanks,
>>>     Paul
>>>
>>>