Merge pull request #10850 from teddygyabaah/patch-20

Update direct-routing-protocols.md

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