On 3/8/12 4:17 AM, venu Y wrote:
> Yes, it won't make sense...
>
> But, in general while parsing SDP, take the most recent... instead of
> strictly rejecting the offer.
The Postel maxim is to be strict in what you send and liberal in what
you receive. The flaw in that is that there are often multiple
conflicting ways in which to be liberal. So being liberal will help when
dealing with somebody who screwed up in the way you assumed, but won't
help with those that screwed up some other way.
Here there are rational arguments for taking the first and taking the
last. The person that sent two values was obviously confused, but you
don't know which of the attributes was the right one.
The merit of taking the last is that it is typically *easier* to
program. That is especially the case when, for some things, you can
legally have an attribute at session level and then override it at media
level. For that, each time you encounter an m-line you need to make a
fresh copy of the session level c= values and attributes, and then
replace them if you encounter them again before the next m-line.
But the bottom line is: put at most *one* of
sendrecv/sendonly/recvonly/inactive at session level, and at most one of
them after each m-line.
Thanks,
Paul
> On Thu, Mar 8, 2012 at 1:33 PM, Pranab Bohra<[email protected]>wrote:
>
>> An Offer can have both the attribute, but not within the same media
>> description.
>> It doesn't make sense to have both sendonly and sendrecv attributes for
>> the same media description.
>> The specs do not explicitly explain how to handle such a situation, I
>> would say, the UA receiving it should respond back with 488 Not Acceptable
>> Here.
>>
>> -----Original Message-----
>> From: [email protected] [mailto:
>> [email protected]] On Behalf Of venu Y
>> Sent: Thursday, March 08, 2012 1:10 PM
>> To: [email protected]
>> Subject: [Sip-implementors] Regarding SDP attributes
>>
>> I think we should take last a= line
>>
>>
>> Does that mean we cannot send both the attributes in one-offer.
>> I think in such case end point should pick last a: line. My guess. Please
>> let me know with little explanation.
>>
>> Thanks,
>> -Abhishek
>>
>> On Wed, Mar 7, 2012 at 4:05 PM, Worley, Dale R (Dale)<[email protected]
>>> wrote:
>>
>>> No: their meanings are incompatible.
>>>
>>> Dale
>>>
>>> ________________________________________
>>> From: [email protected] [
>>> [email protected]] On Behalf Of Abhishek
>>> Lal [[email protected]]
>>> Sent: Tuesday, March 06, 2012 7:53 PM
>>> To: [email protected]
>>> Subject: [Sip-implementors] Regarding SDP attributes
>>>
>>> Hi All,
>>>
>>> Can we send both attributes (sendrecv& sendonly) in single Request.
>>>
>>> a=rtpmap:0 PCMU/8000/1
>>> a=rtpmap:8 PCMA/8000/1
>>> *a=sendrecv*
>>> a=ptime:20
>>> *a=sendonly*
>>> *
>>> *
>>> *
>>> *
>>> **
>>> Regards,
>>> -Abhishek
>>> _______________________________________________
>>> Sip-implementors mailing list
>>> [email protected]
>>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>>
>> _______________________________________________
>> Sip-implementors mailing list
>> [email protected]
>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>
>> SASKEN BUSINESS DISCLAIMER: This message may contain confidential,
>> proprietary or legally privileged information. In case you are not the
>> original intended Recipient of the message, you must not, directly or
>> indirectly, use, disclose, distribute, print, or copy any part of this
>> message and you are requested to delete it and inform the sender. Any views
>> expressed in this message are those of the individual sender unless
>> otherwise stated. Nothing contained in this message shall be construed as
>> an offer or acceptance of any offer by Sasken Communication Technologies
>> Limited ("Sasken") unless sent with that express intent and with due
>> authority of Sasken. Sasken has taken enough precautions to prevent the
>> spread of viruses. However the company accepts no liability for any damage
>> caused by any virus transmitted by this email.
>> Read Disclaimer at http://www.sasken.com/extras/mail_disclaimer.html
>>
>
>
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
