[SIPForum-discussion] Behavior w.r.t RFC 2198 when "a=fmtp"attribute is not present in SDP

[Gunnar Hellstrom]

Jagan,
RFC 2198 says in section 5, sdp, that the receiver shall assume that any of
the payload types in the m-line except the RED payload type may be used in
primary and secondary transmissions. 
It also says that the transmitter need to know what payload types are
recommended, and that the fmtp line would therefore be required. 
This sounds a bit contradicting, at least for sendrcv streams.
 
We have reused the RFC 2198 format for reliability of real-time text in RFC
4102 and RFC 4103, for use for example in Total Conversation´sessions. There
was a mail list discussion on the meaning of the sdp attributes for RFC 2198
when RFC 4103 was about to be approved. That discussion was held in the IETF
AVT group in March 2004.
Here is a link to that discussion: 
http://www.ietf.org/mail-archive/web/avt/current/msg03563.html
 
Gunnar
  _____  

From: discussion-bounces at sipforum.org
[mailto:discussion-bounces at sipforum.org] On Behalf Of Jagan Mohan
Sent: Monday, February 23, 2009 6:25 PM
To: discussion at sipforum.org
Subject: [SIPForum-discussion] Behavior w.r.t RFC 2198 when
"a=fmtp"attribute is not present in SDP


Hi,

  As per RFC 2198, "ftmp" attribute could be used to describe the payload
type for primary and redundant audio, as shown below.

  m=audio 12345 RTP/AVP 121 0 5
  a=rtpmap:121 red/8000/1
  a=fmtp:121 0/5

  Say, offer present in the INVITE request from UAC does not have the "fmtp"
attribute, as shown below:

  m=audio 12345 RTP/AVP 121 0 5
  a=rtpmap:121 red/8000/1

  Then, how would the UAS interpret what codecs to use when RED payload type
is negotiated?

Thanks,
Jagan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sipforum.org/pipermail/discussion/attachments/20090223/f505c76f/attachment-0002.html>