Discussion:
Need opinion
s***@wipro.com
2010-09-30 07:10:09 UTC
Permalink
HI All,



I am some doubt regarding the RFC4566.



According to RFC,



Up to one rtpmap attribute can be defined for each media format

specified. Thus, we might have the following:

=======================================

m=audio 49230 RTP/AVP 96 97 98

a=rtpmap:96 L8/8000

a=rtpmap:97 L16/8000

a=rtpmap:98 L16/11025/2

======================================





But what if the scenario is like the following,



"m=audio 12167 RTP/AVP 103 98 99 0 101 8 9 18 97 4 120 114 115 116
117\r\n" &
"c=IN IP4 " & v_userA.userhost & "\r\n" &
"a=rtpmap:103 AMR/8000/1\r\n" &
"a=fmtp:103 mode-set=0,1,2,3,4,5,6,7;octet-align=0\r\n" &
"a=rtpmap:98 AMR/8000/1\r\n" &
"a=fmtp:98 mode-set=0,1,2,3,4,5,6,7;octet-align=0\r\n" &
"a=rtpmap:99 AMR/8000/1\r\n" &
"a=fmtp:99 mode-set=0,1,2,3,4,5,6,7;octet-align=0\r\n" &
"a=rtpmap:0 PCMU/8000/1\r\n" &
"a=rtpmap:101 telephone-event/8000/1\r\n" &
"a=fmtp:101 0-15\r\n" &
"a=rtpmap:8 PCMA/8000/1\r\n" &
"a=rtpmap:98 AMR/8000/1\r\n" &
"a=fmtp:9 bitrate=48,56,64\r\n" &
"a=rtpmap:18 G729/8000/1\r\n" &
"a=rtpmap:97 EVRC0/8000/1\r\n" &
"a=rtpmap:4 G723/8000/1\r\n" &
"a=fmtp:4 bitrate=5.3,6.3;annexb=yes\r\n" &
"a=rtpmap:120 AMR-WB/16000/1\r\n" &
"a=fmtp:120 mode-set=0,1,2,3,4,5,6,7,8;octet-align=1\r\n" &
"a=rtpmap:114 G726-16/8000/1\r\n" &
"a=rtpmap:115 G726-24/8000/1\r\n" &
"a=rtpmap:116 G726-32/8000/1\r\n" &
"a=rtpmap:117 G726-40/8000/1\r\n"



If you see the red marked attribute this same attribute is getting
repeated in the SDP.

I just want to confirm, is this acceptable behavior?



Can anyone please share his views regarding this?



If this is not the right forum to ask this question can you please
direct me to the concern forum?



Thanks & Regards,

Sulabh
Worley, Dale R (Dale)
2010-09-30 15:46:32 UTC
Permalink
________________________________________
From: sip-***@ietf.org [sip-***@ietf.org] On Behalf Of ***@wipro.com [***@wipro.com]

I am some doubt regarding the RFC4566.

If you see the red marked attribute this same attribute is getting repeated in the SDP.
I just want to confirm, is this acceptable behavior?
________________________________________

According to the principle of "Be strict in what you send and lenient in what you accept", sending two lines that say "a=rtpmap:98 AMR/8000/1" should not be done, but the receiver should accept them and interpret them to mean that payload type number 98 is "AMR/8000/1".

Dale
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-***@cs.columbia.edu for questions on how to develop a SIP implementation.
Use ***@ietf.org for new developments on the application of sip.
Use ***@ietf.org for issues related to maintenance of the core SIP specifications.
Kevin P. Fleming
2010-09-30 17:39:46 UTC
Permalink
Post by Worley, Dale R (Dale)
________________________________________
I am some doubt regarding the RFC4566.
If you see the red marked attribute this same attribute is getting repeated in the SDP.
I just want to confirm, is this acceptable behavior?
________________________________________
According to the principle of "Be strict in what you send and lenient in what you accept", sending two lines that say "a=rtpmap:98 AMR/8000/1" should not be done, but the receiver should accept them and interpret them to mean that payload type number 98 is "AMR/8000/1".
To add to what Dale said... if the sender had sent two "a=rtpmap:98"
lines that did not have the same contents, the behavior of the receiver
is undefined, as the sender is not RFC compliant. The receiver could
choose to accept the first one, the second one, or neither, or even
reject the entire request.

This does not mean, though, that the receiver is obligated to watch for
duplicated "a=rtpmap" lines and verify that they match. It *can* do so,
but it can also treat the second one the same as it would if the
contents did not match the first one. As Dale said, though, it's not
costly to confirm that the second one does in fact match the first one,
and accepting the duplicate line is not harmful.
--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: ***@digium.com
Check us out at www.digium.com & www.asterisk.org
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-***@cs.columbia.edu for questions on how to develop a SIP implementation.
Use ***@ietf.org for new developments on the application of sip.
Use ***@ietf.org for issues related to maintenance of the core SIP specifications.
Loading...