Subject: [MMUSIC] BUNDLE: usage of SDP mid attribute value to implement "receiver-id"?

From: Christer Holmberg <[email-masked]>
Date: Wed, 16 Jul 2014 08:08:55 +0000

Hi BUNDLE lovers,

The main remaining open issue in BUNDLE is the "receiver-id", i.e. the mechanism for the Offerer to map received RTP/RTCP packets with the associated m- line - even before the SDP answer has been received.

In London we more or less agreed to use Roni's app-id for this.

Since then, we've had some off-line discussions with Roni, and instead of using app-id we suggest the following:

-          We use the SDP mid attribute value to map RTP/RTCP packets with m- lines

-          We define a new RTP header extension, and a new RTCP SDES item, for carrying the mid value

-          The RTP header extension/RTCP SDES item are generic, which means they can also be used with other protocols than SDP

The advantage is that the SDP mid attribute already exists, the usage is mandatory in BUNDLE, and the value is unique for each m- line. The semantics also fit, as it is referencing an m- line.

Some of the detailed questions we need to deal with are:

Q1: The syntax of the SDP mid attribute value must "fit" into an RTP header extension of RTCP SDES item.
Q2: When are the mid value sent? During Offer/Answer transaction? During whole session? When SSRC change?
Q3: Do we, for BUNDLE usage, allow usage of the mechanism in both directions?
Q4: Do we carry the RTCP SDES item in RTCP, or in RTP using the mechanism in draft-westerlund-avtext-sdes-hdr-ext?

I intend to talk about during the MMUSIC session on Monday, but feel free to comment and give input on the list :)

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 16 Jul 2014 10:49:52 -0400

On 7/16/14 4:08 AM, Christer Holmberg wrote:
> Hi BUNDLE lovers,
>
> The main remaining open issue in BUNDLE is the “receiver-id”, i.e. the
> mechanism for the Offerer to map received RTP/RTCP packets with the
> associated m- line – even before the SDP answer has been received.
>
> In London we more or less agreed to use Roni’s app-id for this.
>
> Since then, we’ve had some off-line discussions with Roni, and instead
> of using app-id we suggest the following:
>
> -We use the SDP mid attribute value to map RTP/RTCP packets with m- lines
>
> -We define a new RTP header extension, and a new RTCP SDES item, for
> carrying the mid value
>
> -The RTP header extension/RTCP SDES item are generic, which means they
> can also be used with other protocols than SDP
>
> The advantage is that the SDP mid attribute already exists, the usage is
> mandatory in BUNDLE, and the value is unique for each m- line. The
> semantics also fit, as it is referencing an m- line.
>
> Q1: The syntax of the SDP mid attribute value must “fit” into an RTP
> header extension of RTCP SDES item.
>
> Q4: Do we carry the RTCP SDES item in RTCP, or in RTP using the
> mechanism in draft-westerlund-avtext-sdes-hdr-ext?
>
> I intend to talk about during the MMUSIC session on Monday, but feel
> free to comment and give input on the list :)

Another question:

When the grouping framework is used, then *every* m-line must have a mid 
assigned, whether it is bundled or not, and whether the mid is necessary 
to associate media packets to m-lines or not.

Will this require the header extension and SDES item to *used* for RTP 
of every m-line? (That would be unfortunate.)

Else, what are the complete set of conditions that determine when this 
is used?

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 16 Jul 2014 15:09:49 +0000

Hi,

>> The main remaining open issue in BUNDLE is the "receiver-id", i.e. the 
>> associated m- line - even before the SDP answer has been received.
>>
>> Since then, we've had some off-line discussions with Roni, and instead 
>> The advantage is that the SDP mid attribute already exists, the usage 
>> is mandatory in BUNDLE, and the value is unique for each m- line. The 
>When the grouping framework is used, then *every* m-line must have a mid assigned, whether it is >bundled or not, and whether the mid is necessary to associate media packets to m-lines or not.
>
>Will this require the header extension and SDES item to *used* for RTP of every m-line? (That >would be unfortunate.)
>
>Else, what are the complete set of conditions that determine when this is used?

Good question - I'll add that.

My personal opinion is that we would use the mechanism only for RTP/RTCP associated with bundled m- lines. Non-bundled media can be mapped to m- lines using their unique 5-tuple.

Regards,

Christer

---

From: Suhas Nandakumar <[email-masked]>
Date: Wed, 16 Jul 2014 20:41:16 +0530

Hi Paul

  Some thoughts inline.

On Wed, Jul 16, 2014 at 8:19 PM, Paul Kyzivat <[email-masked]> wrote:

> assigned, whether it is bundled or not, and whether the mid is necessary to
> associate media packets to m-lines or not.
>
> Will this require the header extension and SDES item to *used* for RTP of
> every m-line? (That would be unfortunate.)
>

[Suhas] .. I dont see a need for RTP header extension to be repeated for
all the m=lines where a mid is specified. Since the purpose is to map the
incoming media packets to a m=line, we need to specify the header extension
only for this requirement.

So whenever BUNDLE grouping framework is used and when PT is not enough to
map the RTP packets to a m= line, the implementation MUST signal (in SDP)
the RTP Header extension for all the media lines where the disambiguation
is needed and no more or less.

>         Thanks,
>         Paul
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 16 Jul 2014 15:25:21 +0000

Hi Suhas,

You also raise an important point, which I forgot to mention.

The suggestion is that BUNDLE entities MUST support the mechanism.

HOWEVER, IF a BUNDLE entity is able to map RTP based on PT, it would simply not indicate usage of the mechanism (using the SDP extmap attribute). The remote entity would then NOT include the mid value in sent RTP/RTCP packets.

Regards,

Christer

From: mmusic [mailto:[email-masked]] On Behalf Of Suhas Nandakumar
Sent: 16 July 2014 18:11
To: Paul Kyzivat
Cc: mmusic WG
Subject: Re: [MMUSIC] BUNDLE: usage of SDP mid attribute value to implement "receiver-id"?

Hi Paul

  Some thoughts inline.

On Wed, Jul 16, 2014 at 8:19 PM, Paul Kyzivat <[email-masked]<mailto:[email-masked]>> wrote:
On 7/16/14 4:08 AM, Christer Holmberg wrote:
Hi BUNDLE lovers,

Q2: When are the mid value sent? During Offer/Answer transaction? During
whole session? When SSRC change?

Q3: Do we, for BUNDLE usage, allow usage of the mechanism in both
directions?

Another question:

When the grouping framework is used, then *every* m-line must have a mid assigned, whether it is bundled or not, and whether the mid is necessary to associate media packets to m-lines or not.

Will this require the header extension and SDES item to *used* for RTP of every m-line? (That would be unfortunate.)

[Suhas] .. I dont see a need for RTP header extension to be repeated for all the m=lines where a mid is specified. Since the purpose is to map the incoming media packets to a m=line, we need to specify the header extension only for this requirement.

So whenever BUNDLE grouping framework is used and when PT is not enough to map the RTP packets to a m= line, the implementation MUST signal (in SDP) the RTP Header extension for all the media lines where the disambiguation is needed and no more or less.

        Thanks,
        Paul

_______________________________________________
mmusic mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Jonathan Lennox <[email-masked]>
Date: Wed, 16 Jul 2014 15:26:58 +0000

> Else, what are the complete set of conditions that determine when this is used?

I was part of the offline discussion that contributed to this (as co-author of the appid draft), and my understanding of the discussion was as follows:

An m-line group would carry an “a=rtcp-mid” attribute to indicate that the mid would be sent in RTCP, and also an appropriate a=extmap attribute (URL to be determined) to indicate that the mid would also be sent in a header extension.

This attribute is included in SDP to explicitly indicate that you are sending mids in RTP/RTCP; including the attribute is mandatory when you are using BUNDLE with overlapping payload types.  (Optional otherwise, I suppose, though this wasn’t discussed.)

Another important issue: POF/PAN wants to mandate that mid values are long, to minimize the possibility of mid collisions between simultaneous partial offers.  Meanwhile, rtcp-mid wants to mandate that mid values are short, so they fit in RTP header extensions with minimal overhead.  Is there a way we can reconcile these requirements?

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 16 Jul 2014 15:36:46 +0000

Hi Jonathan,

My suggestion was to use the a=mid attribute - not to define a new a=rtcp-mid attribute.

But, of course, if the mid values will be too big (I have expressed some issues on the suggested POF/PAN usage of the mid values) to carry in RTP/RTCP, I guess we have to consider something else.

Regards,

Christer

-----Original Message-----
From: mmusic [mailto:[email-masked]] On Behalf Of Jonathan Lennox
Sent: 16 July 2014 18:27
To: Paul Kyzivat
Cc: mmusic
Subject: Re: [MMUSIC] BUNDLE: usage of SDP mid attribute value to implement "receiver-id"?

On Jul 16, 2014, at 10:49 AM, Paul Kyzivat <[email-masked]> wrote:

>> The main remaining open issue in BUNDLE is the "receiver-id", i.e. 
>> the mechanism for the Offerer to map received RTP/RTCP packets with 
>> the associated m- line - even before the SDP answer has been received.
>> 
>> Since then, we've had some off-line discussions with Roni, and 
>> instead of using app-id we suggest the following:
>> 
>> -The RTP header extension/RTCP SDES item are generic, which means 
>> they can also be used with other protocols than SDP
>> 

An m-line group would carry an "a=rtcp-mid" attribute to indicate that the mid would be sent in RTCP, and also an appropriate a=extmap attribute (URL to be determined) to indicate that the mid would also be sent in a header extension.

This attribute is included in SDP to explicitly indicate that you are sending mids in RTP/RTCP; including the attribute is mandatory when you are using BUNDLE with overlapping payload types.  (Optional otherwise, I suppose, though this wasn't discussed.)

---

From: Jonathan Lennox <[email-masked]>
Date: Wed, 16 Jul 2014 15:41:16 +0000

In my suggestion, a=mid still contains the value.  a=rtcp-mid is a flag attribute (i.e., not containing any content) that simply indicates that the mid values will indeed be sent in RTCP.

I don’t think simply splitting the mid correlator into a separate value from a=mid would solve the POF/PAN problem.  The correlators need to be unique, but in POF/PAN you have the possibility of collision between simultaneous partial offers.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 16 Jul 2014 15:44:03 +0000

Hi,

>In my suggestion, a=mid still contains the value.  a=rtcp-mid is a flag attribute (i.e., not containing >any content) that simply indicates that the mid values will indeed be sent in RTCP.

Ok, I get it. But, why can't we use the a=extmap attribute to indicate that the value will be sent both in RTCP and RTP? Do we want to be able to choose?

Regards,

Christer

I don't think simply splitting the mid correlator into a separate value from a=mid would solve the POF/PAN problem.  The correlators need to be unique, but in POF/PAN you have the possibility of collision between simultaneous partial offers.

On Jul 16, 2014, at 11:36 AM, Christer Holmberg <[email-masked]> wrote:

>>> The advantage is that the SDP mid attribute already exists, the 
>>> usage is mandatory in BUNDLE, and the value is unique for each m- 
>>> line. The semantics also fit, as it is referencing an m- line.
>>> 
>> Will this require the header extension and SDES item to *used* for 
>> RTP of every m-line? (That would be unfortunate.)
>> 
> This attribute is included in SDP to explicitly indicate that you are 
> sending mids in RTP/RTCP; including the attribute is mandatory when 
> you are using BUNDLE with overlapping payload types.  (Optional 
> otherwise, I suppose, though this wasn't discussed.)
> 
>

---

From: Jonathan Lennox <[email-masked]>
Date: Wed, 16 Jul 2014 15:53:45 +0000

I see three possible states:

1. Mid will not be sent at all.  This is what is indicated by current signaling, implicitly.
2. Mid will be sent in RTCP, but not RTP.
3. Mid will be sent in RTCP and RTP both.

(I don’t think we want to allow mid in RTP but not in RTCP.)

In my suggestion, if you don’t say anything, it means #1.  #2 is indicated by a=rtcp-mid, and #3 is indicated by a=rtcp-mid and a=extmap.

Unless you want to say that the BUNDLE group semantic implicitly implies either #2 or #3 (always?  Iff overlapping payload types?), I don’t think it’s a good idea to start sending a new mechanism at the media layer without some SDP signaling indicating/negotiating that it will be done.

I don’t know if we want to allow the #2 possibility.  I can imagine use cases in which it would be desirable, but it also adds complexity.

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Wed, 16 Jul 2014 16:12:19 +0000

Paul Kyzivat <[email-masked]> wrote:
On 7/16/14 4:08 AM, Christer Holmberg wrote:
> Hi BUNDLE lovers,
>
> The main remaining open issue in BUNDLE is the ³receiver-id², i.e. the
> associated m- line  even before the SDP answer has been received.
>
> In London we more or less agreed to use Roni¹s app-id for this.
>
> Since then, we¹ve had some off-line discussions with Roni, and instead
> Q1: The syntax of the SDP mid attribute value must ³fit² into an RTP

Note that SDP mid values and RTCP SDES items are both text (token and
UTF-8, respectively). Compact values for small RTP header extensions
should keep this in mind.

> whole session? When SSRC change?

If negotiated, the RTCP SDES mid item should be sent whenever CNAME is
sent. If negotiated, the RTP header extension echoes this value for the
first few media frames of a new SSRC, or optionally for all critical media
frames (e.g. video key frames or parameter sets).

> Q3: Do we, for BUNDLE usage, allow usage of the mechanism in both

The mechanism applies to the m-line direction (both if sendrecv). A bundle
offer MUST include this if the offerer is otherwise unable to associate
received RTP streams with m-lines (e.g. due to PT reuse across m-lines). A
bundle answer MUST include this if offered.

> mechanism in draft-westerlund-avtext-sdes-hdr-ext?

Yes, follow that format but with no normative dependency. The RTP header
extension name should be:
  a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid

No, only if negotiated on the m-lines where it is needed to associate
received RTP streams.

> Else, what are the complete set of conditions that determine when this

See answer to Q3.

Mo

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Wed, 16 Jul 2014 16:25:08 +0000

If we don¹t care much about 2, then 3 can be negotiated using the existing
a=extmap attribute with the format proposed for SDES items in
draft-westerlund-avtext-sdes-hdr-ext.

This makes it clear the RTP header extension is also an RTCP SDES item. I
agree we should not allow mid in RTP but not RTCP, so naming the header
extension in this way closes that door.

Mo

Jonathan Lennox <[email-masked]> wrote:

1. Mid will not be sent at all.  This is what is indicated by current
signaling, implicitly.
2. Mid will be sent in RTCP, but not RTP.
3. Mid will be sent in RTCP and RTP both.

(I don¹t think we want to allow mid in RTP but not in RTCP.)

In my suggestion, if you don¹t say anything, it means #1.  #2 is indicated
by a=rtcp-mid, and #3 is indicated by a=rtcp-mid and a=extmap.

Unless you want to say that the BUNDLE group semantic implicitly implies
either #2 or #3 (always?  Iff overlapping payload types?), I don¹t think
it¹s a good idea to start sending a new mechanism at the media layer
without some SDP signaling indicating/negotiating that it will be done.

I don¹t know if we want to allow the #2 possibility.  I can imagine use
cases in which it would be desirable, but it also adds complexity.

On Jul 16, 2014, at 11:44 AM, Christer Holmberg
<[email-masked]> wrote:

> Hi,
> 
>> In my suggestion, a=mid still contains the value.  a=rtcp-mid is a flag
>>attribute (i.e., not containing >any content) that simply indicates that
>>the mid values will indeed be sent in RTCP.
> 
> Ok, I get it. But, why can't we use the a=extmap attribute to indicate
>that the value will be sent both in RTCP and RTP? Do we want to be able
>to choose?
> 
> Regards,
> 
> Christer
> 
> 
> 
> 
> 
> I don't think simply splitting the mid correlator into a separate value
>from a=mid would solve the POF/PAN problem.  The correlators need to be
>unique, but in POF/PAN you have the possibility of collision between
>simultaneous partial offers.
> 
>> But, of course, if the mid values will be too big (I have expressed
>>some issues on the suggested POF/PAN usage of the mid values) to carry
>>in RTP/RTCP, I guess we have to consider something else.
>> 
>> Regards,
>> 
>> Christer
>> 
>> 
>>> When the grouping framework is used, then *every* m-line must have a
>>>mid assigned, whether it is bundled or not, and whether the mid is
>>>necessary to associate media packets to m-lines or not.
>>> 
>> I was part of the offline discussion that contributed to this (as
>>co-author of the appid draft), and my understanding of the discussion
>>was as follows:
>> 
>> An m-line group would carry an "a=rtcp-mid" attribute to indicate that
>>the mid would be sent in RTCP, and also an appropriate a=extmap
>>attribute (URL to be determined) to indicate that the mid would also be
>>sent in a header extension.
>> 
>> Another important issue: POF/PAN wants to mandate that mid values are
>>long, to minimize the possibility of mid collisions between simultaneous
>>partial offers.  Meanwhile, rtcp-mid wants to mandate that mid values
>>are short, so they fit in RTP header extensions with minimal overhead.
>>Is there a way we can reconcile these requirements?
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 16 Jul 2014 14:33:00 -0400

On 7/16/14 11:25 AM, Christer Holmberg wrote:
> HOWEVER, IF a BUNDLE entity is able to map RTP based on PT, it would
> simply not indicate usage of the mechanism (using the SDP extmap
> attribute). The remote entity would then NOT include the mid value in
> sent RTP/RTCP packets.

I just skimmed 5285 for the first time. It isn't immediately apparent to 
me whether the SDP for extmap is negotiating *support* or *use*. If its 
like most things, it is probably support, and use is still optional.

	Thanks,
	Paul

> Regards,
>
> Christer
>
> *From:*mmusic [mailto:[email-masked]] *On Behalf Of *Suhas
> Nandakumar
> *Sent:* 16 July 2014 18:11
> *To:* Paul Kyzivat
> *Cc:* mmusic WG
> *Subject:* Re: [MMUSIC] BUNDLE: usage of SDP mid attribute value to
> implement "receiver-id"?
>
> Hi Paul
>
>    Some thoughts inline.
>
>         usage is
> all the m=lines where a mid is specified. Since the purpose is to map
> the incoming media packets to a m=line, we need to specify the header
> extension only for this requirement.
>
> So whenever BUNDLE grouping framework is used and when PT is not enough
> to map the RTP packets to a m= line, the implementation MUST signal (in
> SDP) the RTP Header extension for all the media lines where the
> disambiguation is needed and no more or less.
>
>
>              Thanks,
>              Paul
>
>     [email-masked] <mailto:[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 16 Jul 2014 18:57:28 +0000

Hi,

> I just skimmed 5285 for the first time. It isn't immediately apparent to me whether the SDP for 
> extmap is negotiating *support* or *use*. If its like most things, it is probably support, and use is 
> still optional.

Assuming it means indicating support, we can always specify that if the remote endpoint indicates *support*, the receiving endpoint must *use*. Because, the receiving endpoint is the one that will insert the mid value in the RTP/RTPC packets.

Regards,

Christer

> [Suhas] .. I dont see a need for RTP header extension to be repeated 
> for all the m=lines where a mid is specified. Since the purpose is to 
> map the incoming media packets to a m=line, we need to specify the 
> header extension only for this requirement.
>
> So whenever BUNDLE grouping framework is used and when PT is not 
> enough to map the RTP packets to a m= line, the implementation MUST 
> signal (in

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 16 Jul 2014 19:03:46 +0000

Hi,

> (I don't think we want to allow mid in RTP but not in RTCP.)
>
> In my suggestion, if you don't say anything, it means #1.

Agree.

> #2 is indicated by a=rtcp-mid, and #3 is indicated by a=rtcp-mid and a=extmap.

The question is whether we see a need to allow #2, or whether usage always means #3.

> Unless you want to say that the BUNDLE group semantic implicitly implies either #2 or #3 (always?  > Iff overlapping payload types?),

I do NOT want to say that :)

> I don't think it's a good idea to start sending a new mechanism at the media layer without some 
> SDP signaling indicating/negotiating that it will be done.

I agree.

But again: I thought the extmap value would be enough, because my assumption has been that usage always means #3.

> I don't know if we want to allow the #2 possibility.  I can imagine use cases in which it would be 
> desirable, but it also adds complexity.

If there is a good use case for #2, I won't object. 

Regards,

Christer

On Jul 16, 2014, at 11:44 AM, Christer Holmberg <[email-masked]> wrote:

>>>> -We define a new RTP header extension, and a new RTCP SDES item, 
>>>> for carrying the mid value
>>>> 
>>>> I intend to talk about during the MMUSIC session on Monday, but 
>>>> feel free to comment and give input on the list :)
>>> 
>>> Another question:
>>>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 16 Jul 2014 19:10:49 +0000

Hi,

> Note that SDP mid values and RTCP SDES items are both text (token and UTF-8, respectively). 
> Compact values for small RTP header extensions should keep this in mind.
>
> If negotiated, the RTCP SDES mid item should be sent whenever CNAME is sent. If negotiated, the 
> RTP header extension echoes this value for the first few media frames of a new SSRC, or optionally > for all critical media frames (e.g. video key frames or parameter sets).
>
> The mechanism applies to the m-line direction (both if sendrecv). A bundle offer MUST include this > if the offerer is otherwise unable to associate received RTP streams with m-lines (e.g. due to PT 
> reuse across m-lines). A bundle answer MUST include this if offered.

Note that you can also indicate direction in the examap attribute, but I haven't had time to check how/if it is relate to the direction attribute.

> Yes, follow that format but with no normative dependency. The RTP header extension name 
> should be:  a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid

Just to verify: you are suggestion to send the value in RTP using draft-westerlund-avtext-sdes-hdr-ext, and in RTCP using a SDES item?

Regards,

Christer

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Wed, 16 Jul 2014 19:57:34 +0000

Christer Holmberg <[email-masked]> wrote:
> Note that you can also indicate direction in the extmap attribute, but I
>haven't had time to check how/if it is relate to the direction attribute.

Good point. I didn¹t think that would be useful at first, but now see some
possible uses. The extmap direction inherits from the m-line direction,
but can override it. This could be useful for a=sendrecv cases where the
offerer does not need to receive the extension (e.g. it offers unique PTs
across m-lines), but is willing to send the extension in case the answerer
needs it.

Offer: (does not need to receive RTP mid, but willing to send it)
a=sendrecv
a=extmap:1/sendonly urn:ietf:params:rtp-hdrext:sdes:mid

Answer1: (needs to receive RTP mid)
a=sendrecv
a=extmap:1/recvonly urn:ietf:params:rtp-hdrext:sdes:mid

Answer2: (does not need to receive RTP mid)
a=sendrecv
(no a=extmap)

> Just to verify: you are suggestion to send the value in RTP using
>draft-westerlund-avtext-sdes-hdr-ext, and in RTCP using a SDES item?

Correct.

Mo

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 16 Jul 2014 21:53:43 +0000

Hi,

>> Note that you can also indicate direction in the extmap attribute, but 
>>I haven't had time to check how/if it is relate to the direction attribute.
>
>Good point. I didn¹t think that would be useful at first, but now see some possible uses. The extmap >direction inherits from the m-line direction, but can override it. This could be useful for a=sendrecv >cases where the offerer does not need to receive the extension (e.g. it offers unique PTs across m->lines), but is willing to send the extension in case the answerer needs it.
>
>Offer: (does not need to receive RTP mid, but willing to send it) a=sendrecv a=extmap:1/sendonly >urn:ietf:params:rtp-hdrext:sdes:mid
>
>Answer2: (does not need to receive RTP mid) a=sendrecv (no a=extmap)

That would mean that the offerer must always include the extmap attribute in the offer, even if it does not need to receive, as it shall allow for the answerer to indicate that it wants to receive.

Regards,

Christer

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Wed, 16 Jul 2014 22:27:01 +0000

That may be a good approach.

Although you could argue that if the offerer can avoid reusing PTs and
thus not need any RTP mid, so can the answerer. The answerer may use
different PT values, but it can’t answer with more PTs than offered.

The only case where I can envision this being useful is if the offerer
uses the entire primary dynamic PT range and is willing to use secondary
and tertiary PT ranges as well, but the answerer for some reason is only
willing or able to use the primary dynamic range and therefore must reuse
PTs if it accepts that many formats.

Mo

>Good point. I didn¹t think that would be useful at first, but now see
>some possible uses. The extmap >direction inherits from the m-line
>direction, but can override it. This could be useful for a=sendrecv
>>cases where the offerer does not need to receive the extension (e.g. it
>>offers unique PTs across m->lines), but is willing to send the extension
>>in case the answerer needs it.
>

That would mean that the offerer must always include the extmap attribute
in the offer, even if it does not need to receive, as it shall allow for
the answerer to indicate that it wants to receive.

Regards,

Christer