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
