[TS] I didn’t see that as a specific use-case, rather so= mething that arises due to the way how the rules for the 2

When SIP is used “491 (Request Pending)” procedur=
es [1][2] can be used.

   A UAS that receive=
s an INVITE on a dialog while an INVITE it had sent
   on that dialog is =
in progress MUST return a 491 (Request Pending)
   response to the re=
ceived INVITE.
   If a UAC receives =
a 491 response to a re-INVITE, it SHOULD start a
   timer with a value=
 T chosen as follows:

      =
1. If the UAC is the owner of the Call-ID of the dialog ID
     &=
nbsp;   (meaning it generated the value), T has a randomly chosen=
 value
     &=
nbsp;   between 2.1 and 4 seconds in units of 10 ms.

      =
2. If the UAC is not the owner of the Call-ID of the dialog ID, T
     &=
nbsp;   has a randomly chosen value of between 0 and 2 seconds in=
 units
     &=
nbsp;   of 10 ms.
_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic

 � An entity implmementing an MSID semantic MUST add one or more "msid-
� �semantic" attributes to its session level attributes, indicating the
� �MSID semantic it supports.

It's not clear this formulation is correct, as there may be cases where an implementation 
supports a specific semantic,but does not wish to use it.� This hinges, I guess, on what 
"entity" means here (the implementation or the instance in which it is used).� I'd suggest 
changing these formulations to something like "An implementation supporting an MSID semantic 
for a specific offer/answer MUST add..." unless there is a strong reason to believe that
it must be offered if implemented.

Later, in section 5.1, the document says:

  "If an entity implementing the WMS semantic sends a description, 
   it MUST include the msid-semantic:WMS attribute, even if no media 
   streams are sent. This allows us to distinguish between the case 
   of no media streams at the moment and the case of legacy SDP generation."

It's not clear what legacy SDP generation means here. It seems that the
presence of any msid-semantic session level attribute would indicate
that it was not "legacy SDP generation", for at least some values of legacy.

I think the point here is that you want to know at beginning of the session
whether or not WMS semantics will be used, even if there no media to bear
the MSIDs yet.  I'd suggest recasting this to say that, with something like

"In an entity intends to use WMS semantics in a session, it should the msid-semantic
on sending a description, even if no media are sent"

In the IANA considerations, the document says:

   This document requests IANA to create a new registry called
   "Semantics for the msid-semantic SDP attribute", which should have
   exactly the same rules as for the "Semantics for the ssrc-group SDP
   attribute" registry (Expert Review), and to register the "WMS"
   semantic within this new registry.
Generally, IANA seems to be asking for guidance to the expert when
you create a registry with expert review; if the intent is to repeat 
the guidance given for ssrc-group SDP attribute registry, then a pointer 
to the guidance may be necessary.  Alternatively, it may be enough to 
suggest that the working group expects this to be a sparsely used registry

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic

Hi,

In your first alternative, you incl=
ude multiple media types in a single m- line (m=3Dapplication). The =
question whether we want to allow that is not BUNDLE specific (however, in =
the beginning of times we did discuss a single-m-line-with-multiple-media-t=
ypes approach also for BUNDLE, but decided to not do that).

In your second alternative, you use=
 two BUNDLE groups, with separate m- lines for the audio- and video =
FID streams. From a BUNDLE perspective I see no issues of using two separat=
e BUNDLE groups in that way. And, eventhough the BUNDLE groups from a FID p=
erspective are related, from a pure BUNDLE perspective the BUNDLE groups ar=
e independent from each other.

However, perhaps you in draft-ietf-avtcore=
-multi-media-rtp-session would need some BUNDLE restrictions. For example, =
if the answerer accepts the “main media” BUNDLE group (foo bar)=
, does it also have to accept the “fid” BUNDLE group (zoo kelp)=
?

Personally, I like the second alternative =
better.

Regards,

Christer

>I realize that there is another likely=
 configuration here, and that is
>one where one has one corresponding m=
=3D line per source media source also
>in the retransmission RTP session whic=
h would result in an example SDP
>like this:
> 
>       v=
=3D0
>       o=
=3Dalice 2890844526 2890844526 IN IP4 atlanta.example.com=

>       s=
=3D
>       c=
=3DIN IP4 atlanta.example.com
>       t=
=3D0 0
>       a=
=3Dgroup:BUNDLE foo bar
>       a=
=3Dgroup:BUNDLE zoo kelp
>       a=
=3Dgroup:FID foo zoo
>       a=
=3Dgroup:FID bar kelp
>       <=
b>m=3Daudio 10000 RTP/AVP 0
>       b=
=3DAS:200
>       <=
b>a=3Dmid:foo
>       a=
=3Drtpmap:0 PCMU/8000
>       a=
=3Dextmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
>      &nbs=
p;m=3Dvideo 10000 RTP/AVP 31
>       b=
=3DAS:1000
>       <=
b>a=3Dmid:bar
>       a=
=3Drtpmap:31 H261/90000
>       a=
=3Dextmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
>       <=
/span>m=3Daudio 40000 RTP/AVPF 99
>       a=
=3Drtpmap:99 rtx/90000
>       a=
=3Dfmtp:99 apt=3D0;rtx-time=3D3000
>       <=
/span>a=3Dmid:zoo
>       a=
=3Dextmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
>       <=
/span>m=3Dvideo 40000 RTP/AVPF 100<=
span style=3D"color:black">
>       a=
=3Drtpmap:100 rtx/90000
>       a=
=3Dfmtp:199 apt=3D31;rtx-time=3D3000
>       <=
/span>a=3Dmid:kelp
>       a=
=3Dextmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
> 
> 
>So, please provide input on which way =
you think is the most correct and
>based on what is written in the BUNDLE=
 and other specs
> 
>> MMUSIC,
>> (CC AVTCORE but please reply to M=
MUSIC only)
>> 
>> In draft-ietf-avtcore-multi-media=
-rtp-session-06 we have the following
>> open issue in Section 7.1:
>> 
>>    Open Issue: Whe=
n using SDP to signal retransmission for one RTP
>>    session with mu=
ltiple media types and one RTP session for the
>>    retransmission =
data will cause a situation where one will have
>>    multiple m=3D l=
ines grouped using FID and the ones belonging to
>>    respective RTP =
session being grouped using BUNDLE.  This usage might
>>    contradict both=
 the FID semantics [RFC5888] and an assumption in the
>>    RTP retransmiss=
ion specification [RFC4588].
>> 
>> What I understand the concern rel=
ates to the correct usage of FID to
>> avoid breaking the semantics of F=
ID when declaring an RTP session that
>> would contain one audio, one vide=
o source bundled but a separate RTP
>> session for the retransmission of=
 both these media sources.
>> 
>> Lets exemplify with what I believ=
e is the only possible offer for this
>> in regards to FID usage.
>> 
>>    SDP Offer (3)
>> 
>>     &nbs=
p;  v=3D0
>>     &nbs=
p;  o=3Dalice 2890844526 2890844526 IN IP4 atlanta.example.com
>>     &nbs=
p;  s=3D
>>     &nbs=
p;  c=3DIN IP4 atlanta.example.com
>>     &nbs=
p;  t=3D0 0
>>     &nbs=
p;  a=3Dgroup:BUNDLE foo bar
>>     &nbs=
p;  a=3Dgroup:FID foo zoo
>>     &nbs=
p;  a=3Dgroup:FID bar zoo
>>     &nbs=
p;  m=3Daudio 10000 RTP/AVP 0
>>     &nbs=
p;  b=3DAS:200
>>     &nbs=
p;  a=3Dmid:foo
>>     &nbs=
p;  a=3Drtpmap:0 PCMU/8000
>>     &nbs=
p;  a=3Dextmap 1 urn:ietf:params:rtp-hdrext:sdes:mid=

>>     &nbs=
p;  m=3Dvideo 10000 RTP/AVP 31
>>     &nbs=
p;  b=3DAS:1000
>>     &nbs=
p;  a=3Dmid:bar
>>     &nbs=
p;  a=3Drtpmap:31 H261/90000
>>     &nbs=
p;  a=3Dextmap 1 urn:ietf:params:rtp-hdrext:sdes:mid=

>>     &nbs=
p;  m=3Dapplication 40000 RTP/AVPF=
 99 100
>>     &nbs=
p;  a=3Drtpmap:99 rtx/90000
>>     &nbs=
p;  a=3Dfmtp:99 apt=3D0;rtx-time=3D3000
>>     &nbs=
p;  a=3Drtpmap:100 rtx/90000
>>     &nbs=
p;  a=3Dfmtp:199 apt=3D31;rtx-time=3D3000
>>     &nbs=
p;  a=3Dmid:zoo
>> 
>> I think the important aspect here=
 is that one MUST use one FID line per
>> m=3D line one groups with the ret=
ransmission session to avoid the FID MUST
>> NOT have the same address that Ro=
ni brought up back in December.
>> 
>> Have I missed any limitation or d=
oes the above example appear
>> reasonable. If it does then we ca=
n write a small informational
>> description about this into the m=
ultiple media types document.
>> 
>> Cheers
>> 
>> Magnus Westerlund

In
            whole document, including the document's title, replacement
            of

=
"data
            channel" with
            "WebRTC data channel".

In
          Section 4 removal of following note: 'OPEN ISSUE: The syntax
          in [I-D.ietf-mmusic-sct=
p-sdp]
          may change as
          that document progresses. In
          particular we expect "webrtc-datachannel"
          to become a more genera=
l
          term.'

Consistent usage of=

          '"m" line' in whole document as per
          [RFC4566].

In
          Section 5.1.1 removal of following note: 

          "Note: This attribute i=
s
          derived from attribute
          "webrtc-DataChannel", which was defined in old version 03 of the
          following draft,
          but which was removed a=
long
          with any support for SDP external
          negotiation in subsequent versions:
          [I-D.ietf-mmusic-sctp-sdp]."

Insertion of following new sentence to the beginning of Section 5.1.1.1: 

          "dcmap is a media
          level attribute having =
following
          ABNF syntax:".

In
          Section 5.1.1.1 the ABNF definition of "quoted-string" refers to rule name
          "escaped-char",
          which is not defined.=C2=A0 Instead
          a rule with name
          "escaped" is defined.=C2=A0 Re=
naming
            of that rule's name to
          "escaped-char".

Insertion of following dedicated note right after the
          "a=3Ddcmap:4
          label=3D"foo%09bar";ordered=3Dtrue;max-time=3D15000;max-retr=3D=
3" attribute example in
          Section 5.1.1.1:

          "Note: The last example (a=3Ddcmap:4) shows a 'label' parameter=

          value which contains one non-printable 'escaped-char'
          character (the=C2=A0=C2=A0=C2=A0 tabulator character)."

In
          Section 5.1.2's second paragraph replacement of "sctp stream identifier" with "SCTP
          stream
          identifier".

In
          first paragraph of Section 5.2.1 replacement of first sentence<=
span
            style=3D"mso-spacerun:yes"> 

=C2=A0=C2=A0=C2=A0 "For the SDP-based external
          negotiation described in this =
document,
          the initial offerer based
          "SCTP over DTLS" owns by convention
          the even stream identifiers
          whereas the initial ans=
werer
          owns the odd stream identifiers."

          with 

          =C2=A0=C2=A0=C2=A0 "For the SDP-based external
          negotiation described in this
          document, the sender of the initial
          offer owns by convention the even
          stream identifiers wher=
eas
          the sender of the initial answer
          owns the odd stream ide=
ntifiers."

In
          Section 5.2.3 the first action of an SDP answerer, when receiving an SDP offer, is=

          described as

          =C2=A0=C2=A0=C2=A0 "Applies the SDP offer. Note
          that the browser ignores data
          channel specific attributes in=

          the SDP."=C2=A0 =

          Replacement of these two sentences with

          =C2=A0=C2=A0=C2=A0 "It parses and applies
          the SDP offer.=C2=A0 No=
te
          that the typical parser normally
          ignores unknown SDP attributes, which
          includes WebRTC data channel <=
/span>related
          attributes."

In
          Section 5.2.3 the second sentence of the third SDP answerer action is 

          =C2=A0=C2=A0=C2=A0 "Note that the browser is
          asked to create data channels =
with
          stream identifiers not
          "owned" by the agent.".=C2=A0

          Replacement of this
          sentence with 

          =C2=A0=C2=A0=C2=A0 "Note that the
          agent is asked to create WebRTC
          data channels with SCTP stream
          identifiers contained in the <=
/span>SDP
          offer if the SDP offer is
          accepted."

In
          Section 5.2.4 the third paragraph begins with 

          =C2=A0=C2=A0=C2=A0 "A data channel can
          be closed by sending a new SDP offer
          which excludes the dcmap and
          dcsa attributes lines for the data
          channel.=C2=A0 The port=

          value for the m line
          should not be changed
          (e.g., to zero) when closing <=
/span>a
          data channel (unless all data channels
          are being closed and the SCTP
          association is no longer needed),
          since this would close the SCTP
          association and impact all of the
          data channels.=C2=A0 If=
 the
          answerer accepts the SD=
P
          offer then it
          MUST also exclude the c=
orresponding
          attribute lines in the
          answer. ..." 

          Replacement of this
          part with 

          =C2=A0=C2=A0=C2=A0 "The intention to
          close a WebRTC data channel can
          be signaled by sending a new SDP offer
          which excludes the "a=3D=
dcmap:"
          and
          "a=3Ddcsa:" attributes lines for the WebRTC data channel.=C2=A0
          The port value for the "m" line SHOULD not be changed (e.g., to zero) when closin=
g
          a WebRTC
          data channel (unless all WebRTC
          data channels are being closed and
          the SCTP association is no
          longer needed), since this would close
          the SCTP association and impact
          all of the WebRTC data
          channels.=C2=A0 If the
          answerer accepts the
          SDP offer then it MUST close those
          WebRTC data channels whose "a=3Ddcmap:"
          and
          "a=3Ddcsa:" attribute lines were excluded from the received SDP offer, unless=

          those WebRTC
          data channels were already closed,
          and it MUST also exclude the
          corresponding attribute lines =
in
          the answer."

In
            Section 5.2.4 the hanging text after the third paragraph is

=C2=A0=C2=A0=C2=A0 "This delayed close is to handle
            cases where a successful SDP

answer is not
            received, in which case the
            state of session should

be kept per the=

            last successful SDP
            offer/answer."
=C2=A0=

            Replacement of

this
            sentence with 

            =C2=A0=C2=A0=C2=A0 "This delayed
            closure is RECOMMENDED in order

to
            handle cases where a successful SDP answer is not received,
            in

=
which
            case the state of the session
            SHOULD be kept per the last

successful SDP
            offer/answer."