Merge branch 'public' into patch-21

Teams/assign-policies-users-and-groups.md

@@ -97,10 +97,7 @@ Group policy assignments are only propagated to users who are direct members of
 > The Teams Powershell module and Teams admin center don't support the following policies for group policy assignment.
 >
 > - Teams App Permission Policy
-> - Teams Emergency Call Routing Policy
-> - Teams Network Roaming Policy
 > - Teams Upgrade Policy
-> - Teams Voice Applications Policy
 
 ### What you need to know about policy assignment to groups
 
@@ -122,9 +119,6 @@ A user's effective policy is updated according to these rules:
 
 #### Group assignment ranking
 
-> [!NOTE]
-> A given policy type can be assigned to a maximum of 64 groups across policy instances for that type.
-
 When you assign a policy to a group, you specify a ranking for the group assignment. This ranking is used to determine which policy a user should inherit as their effective policy if the user is a member of two or more groups and each group is assigned a policy of the same type.
 
 The group assignment ranking is relative to other group assignments of the same type. For example, if you're assigning a calling policy to two groups, set the ranking of one assignment to 1 and the other to 2, with 1 being the highest ranking. The group assignment ranking indicates which group membership is more important or more relevant than other group memberships regarding inheritance.

Teams/direct-routing-protocols.md

@@ -77,7 +77,10 @@ The following table lists the sections of the RFC(s) in which Microsoft's implem
 | :---------------------  |:---------------------- |:-----------------------|
 | [RFC 6337, section 5.3 Hold and Resume of Media](https://tools.ietf.org/html/rfc6337#section-5.3) | RFC allows using “a=inactive”, “a=sendonly”, a=recvonly” to place a call on hold. |The SIP proxy only supports “a=inactive” and doesn't understand if the SBC sends “a=sendonly” or “a=recvonly”.
 | [RFC 6337, section 5.4 Behavior on Receiving SDP with c=0.0.0.0](https://tools.ietf.org/html/rfc6337#section-5.4) | [RFC3264](https://tools.ietf.org/html/rfc3264) requires that an agent is capable of receiving SDP with a connection address of 0.0.0.0, in which case it means that neither RTP nor RTCP should be sent to the peer. | The SIP proxy doesn't support this option. |
-| [RFC 3261, section 25 Augmented BNF for the SIP Protocol](https://tools.ietf.org/html/rfc3261#section-25.1) | '#' character should be sent as '%23'| The SIP proxy sends the '#' character in a Request-URI unescaped. |
+| [RFC 3261, section 25 Augmented BNF for the SIP Protocol](https://tools.ietf.org/html/rfc3261#section-25.1) | '#' character should be sent as '%23'| The SIP proxy sends the '#' character in a Request-URI unescaped.
+| [RFC 3264, section 8.3.1 An Offer/Answer Model with SDP](https://www.rfc-editor.org/rfc/rfc3264#section-8.3.1) |3264 details a MAY (Optional) media re-target mechanism allowing changing media port, IP address, or transport after session is established. | Optional media re-target is not supported. During a call, SIP requests to update media port, IP address, or transport are not supported. Media will not be sent to the updated session target; media from Direct Routing will continue to flow to the original target.
+
+Note from RFC supporting the choice; The offerer MUST be prepared to receive media on both the old and new ports as soon as the offer is sent. The offerer SHOULD NOT cease listening for media on the old port until the answer is received and media arrives on the new port.|
 
 ## TCP/TLS transport considerations