[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sipping] [RAI] draft-ietf-sipping-media-policy-dataset: The implied boolean logic of policy operations



Hi Dale,

yes, we are saying the same thing.

Thanks,

Gonzalo

On 07/03/2011 11:46 PM, Worley, Dale R (Dale) wrote:
> Gonzalo Camarillo [Gonzalo.Camarillo@xxxxxxxxxxxx] writes:
>>>    o  The different <stream> elements in a session-policy are
>>>       effectively ORed together, in that the policy intends to permit
>>>       any stream that conforms to *any one* of the <stream> elements.
>>>       This is necessary because e.g. a session-policy can contain one
>>>       <stream> that specifies audio media and restricts the codecs
>>>       permitted for audio, and another <stream> that specifies video
>>>       media and restricts the codecs permitted for video.
>>
>> When policies apply to different aspects (e.g., video codecs and audio
>> codecs), this is true. However, if different policies apply to the same
>> aspect, they need to be merged. And when merging the policies, the
>> resulting stream needs to be compliant to all policies (i.e., an AND
>> operation). For example, if one policy allows codecs 0 and 8 and another
>> only allows 8, the resulting policy is to only use codec 8. If a policy
>> allows only codec 0 and another policy only allows codec 8, the result
>> is a null session. I am not sure if this is what you are saying above
>> (and below in the rest of the section), though.
> 
> I'm not sure I'm understanding you completely here.  And it's possible
> that we aren't talking about exactly the same thing.
> 
> Let me recap my opinion:
> 
> - When there are two <stream> elements in *one* session-policy, then
> the intention is to OR the specified restrictions:  a stream that
> conforms to any one of the <stream> elements is premitted.
> 
> - When we "merge" *two* session-policy's, that is an AND, in that the
> stream is subject to the restrictions of each session-policy
> seperately.
> 
> So within one session-policy, one could have a <stream> element that
> specifies the allowed audio codecs, and another <stream> element that
> specifies the allowed video codecs, because an SDP stream that
> conforms to *either* <stream> element would be allowed.  Thus, if one
> <stream> allows codec G.729 and another <stream> allows codec G.711,
> then either codec could be used in a stream.
> 
> But if one is "merging" two session-policy's, an audio stream would
> only be acceptable to the resulting merged session-policy if its
> codecs conformed to the limitations in both original ession-policy's.
> Thus, if one session-policy allows codec G.729 and the other
> session-policy allows codec G.711, then no codec could be used in an
> audio stream.
> 
> Dale

_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
Use sip@xxxxxxxx for new developments of core SIP


[IETF Announce]     [IETF Discussion]     [Linux SCSI]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Photo]     [Yosemite News]    [Yosemite Photos]    [Free Online Dating]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Big List of Linux Books]

Add to Google Powered by Linux