Re: [MMUSIC] Draft new version: 8843bis-02

[Paul Kyzivat <[e-mail]>]

Christer,

This sounds good to me.

	Thanks,
	Paul

On 6/11/21 3:35 AM, Christer Holmberg wrote:

> We could e.g., keep the text, because I do think that showing the examples is useful, but instead of saying that endpoints should support them we simply say that the processing is outside the scope of the document.
> 
> Something like:
> 
> ---
> 
> 7.3.5.  RFC 8843 Considerations
> 
>     In RFC 8843, instead of assigning the offerer BUNDLE address:port to
>     each "m=" section within the BUNDLE group when modifying the session
>     (Section 7.5), the offerer only assigned the offerer BUNDLE
>     address:port to the offerer-tagged "m=" section.  For every other
>     "m=" section within the BUNDLE group, the offerer included an SDP
>     'bundle-only' attribute in, and assigned a zero port value to, the
>     "m=" section. The way an answerer compliant to this specification
>      processes such offer is considered an implementation issue (e.g., based
>      on whether the answerer needs to be backward compatible with RFC 8843
>      compliant offerers), and is outside the scope of this specification.
> 
>     SDP Offer
> 
>       v=0
>       o=alice 2890844526 2890844526 IN IP6 2001:db8::3
>       s=
>       c=IN IP6 2001:db8::3
>       t=0 0
>       a=group:BUNDLE foo bar
> 
>       m=audio 10000 RTP/AVP 0 8 97
>       b=AS:200
>       a=mid:foo
>       a=rtcp-mux
>       a=rtpmap:0 PCMU/8000
>       a=rtpmap:8 PCMA/8000
>       a=rtpmap:97 iLBC/8000
>       a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
> 
>       m=video 0 RTP/AVP 31 32
>       b=AS:1000
>       a=mid:bar
>       a=bundle-only
>       a=rtpmap:31 H261/90000
>       a=rtpmap:32 MPV/90000
>       a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
> 
> ---
> 
> Regards,
> 
> Christer
> 
> 
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>