Subject: RE: [MMUSIC] Re: rtpmap attribute in sdp-new

From: "Tom-PT Taylor"<[email-masked]>
Date: Thu, 7 Mar 2002 20:25:58 -0500

I have always understood it as a media-level attribute, but I see no harm in
allowing it at session level.

-----Original Message-----
From: Colin Perkins [mailto:[email-masked]]
Sent: Wednesday, March 06, 2002 4:29 PM
To: Flemming Andreasen
Cc: Pekka Pessi; [email-masked]
Subject: [MMUSIC] Re: rtpmap attribute in sdp-new

[moved to [email-masked] from [email-masked]]

The new text in -04 was intended as a clarification of existing behaviour,
not a change. My interpretation has always been that a=rtpmap is a media
attribute, not a session attribute.

How have others interpreted this?

Colin

--> Flemming Andreasen writes:
>Sorry that I missed this, but I see that as of sdp-new-04, rtpmap has been
>specified to be a media-level attribute. Why is that ? If I have multiple
>media streams of the same type, shouldn't I be allowed to re-use the
dynamic
>payload type bindings across media streams by having session-level rtpmaps
?
>
>-- Flemming
>
>
>Colin Perkins wrote:
>
>> --> Pekka Pessi writes:
>> >       The sdp-new-03 draft does not explicitly say if rtpmap is a
>> >       media-level attribute.  Should it be stated, or is it clear from
>> >       context?  Should there be a separate paragraph describing rtpmap
>> >       like other attributes?
>>
>> It should probably have a separate paragraph, to be consistent. I'll see
>> what I can do with the next version.
>>
>> Cheers,
>> Colin
>
>--
>Flemming Andreasen
>Cisco Systems
>

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

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 07 Mar 2002 20:33:05 -0500

> allowing it at session level.

I think there can be a problem. Consider this SDP:

   v=0
   o=alice 2890844526 2890844527 IN IP4 host.anywhere.com
   s=
   c=IN IP4 host.anywhere.com
   t=0 0
   a=rtpmap:0 G723 
   m=audio 49170 RTP/AVP 0
   m=audio 51372 RTP/AVP 0

The problem is that its not clear which of the PT 0 is mapped by this
rtpmap. To my knowledge, there is no requirement that the payload type
numbers be unique across streams. In fact, offer/answer explicitly talks
about disallowing assignment of the same PT number to a different codec
within the same stream - not across all streams. 

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

---

From: Flemming Andreasen <[email-masked]>
Date: Fri, 08 Mar 2002 08:20:02 -0500

> within the same stream - not across all streams.

Right, but this is not a problem. If you provide an rtpmap at the session
level, it would apply to all media streams, unless there was an overriding
rtpmap binding for the payload type(s) in question at a media level. This is
the way we normally use parameters that can be applied at both the session and
media level.

-- Flemming

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 08 Mar 2002 11:57:53 -0500

Flemming Andreasen wrote:

> the way we normally use parameters that can be applied at both the

I think that would work, but its certainly not the way I always thought
it worked up till now.

-Jonathan R.

---

From: Colin Perkins <[email-masked]>
Date: Fri, 08 Mar 2002 16:40:27 -0500

--> Jonathan Rosenberg writes:
>> rtpmap binding for the payload type(s) in question at a media level.  This
>> is the way we normally use parameters that can be applied at both the
>> session and media level.
>

So, people would be happy to see a=rtpmap allowed as a session attribute? I
can make the change in the next version of SDP, if that is the consensus.

Colin

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 11 Mar 2002 17:42:05 -0500

Sounds good to me.

-- Flemming

--
Flemming Andreasen
Cisco Systems