Subject: Re: [MMUSIC] Negotiation in draft-hellstrom-mmusic-multi-party-rtt-00.txt

From: Christer Holmberg <[email-masked]>
Date: Tue, 17 Dec 2019 08:01:49 +0000

Hi,

Before we decide on support indicators, we need to decide on how we are going to implement multi-party RTT.

Section 4 specifies different alternatives. Are we going to specify all of those, or only a subset?

Related to Section 4, it would be nice with an SDP example for each alternative.

Regards,

Christer

From: mmusic <[email-masked]> on behalf of Gunnar Hellstrom <[email-masked]>
Date: Sunday, 15 December 2019 at 22.25
To: "[email-masked]" <[email-masked]>
Subject: [MMUSIC] Negotiation in draft-hellstrom-mmusic-multi-party-rtt-00.txt

Hi,

draft-hellstrom-mmusic-multi-party-rtt/<https://datatracker.ietf.org/doc/draft-hellstrom-mmusic-multi-party-rtt/> currently contains sets of alternative solutions for different aspects of multi-party real-time text (RTT).

I would like to discuss these alternatives aspect by aspect, and eventually reduce them to one solution per aspect. By aspects, I mean negotiation for SIP, negotiation for WebRTC, source identification and multi-party transport for SIP, source identification and multi-party transport for WebRTC and mixing for the multi-party unaware case.

The main requirements are described in section 3 of the draft. One requirement is that the solution should be implementable in a near future. Point-to-point RTT solutions based on SIP and RTP with RFC 4103 transport are implemented, and there are cases where upgrade to multi-party support is urgent. It is assumed that most multi-party cases will be based on one central bridge. The media coding is according to ITU-T T.140, that is Unicode text transmitted UTF-8 transformed, with some control codes from ISO 6429. Transmission takes place without any special action by the user other than creating text. Transmission is usually time sampled in about 300 ms samples.

I want to start with the negotiation aspect. Before the bridge can start transmitting RTT in a way suitable for good presentation of multi-party RTT, it must know that the receiving party is capable of separating text from the different participants. Also the UA may need an indication that it should include source information in a specific way for multi-party RTT to work..

Therefore, a negotiation method is needed. Chapter 7 contains the following negotiation alternatives.

7.1 Implicit negotiation by the bridge expressing RTT multi-party capability indications according to RFC 4575, and the UA showing multi-party awareness only if it supports multi-party RTT.

7.2 Define a new SIP media tag indicating RTT multi-party capability. Start using multi-party RTT after a successful capability exchange.

7.3 Define a new SDP attribute on media level, indicating RTT multi-party capability. Start using multi-party RTT after a successful capability exchange.

There may be other alternatives that I have not thought about.

Pros and cons for these methods are documented in chapter 7.

I hope we can discuss the negotiation methods and soon get to a conclusion.

Regards

Gunnar

Den 2019-11-01 kl. 00:43, skrev Gunnar Hellström:

Hi mmusic and avtcore,

I have replaced an old expired draft about real-time text multi-party handling. It touches both transport and negotiation topics, so I am sending this to both mmusic and avtcore, but I hope we can keep the discussion in mmusic. So, please respond with your comments to mmusic.

Right now, the draft is a discussion paper. I intend to convert it to a true BCP format after some discussions on the preferences I have proposed.

Regards

Gunnar Hellström

-------- Vidarebefordrat meddelande --------
Ämne:
I-D Action: draft-hellstrom-mmusic-multi-party-rtt-00.txt
Datum:
Thu, 31 Oct 2019 16:33:35 -0700
Från:
[email-masked]<mailto:[email-masked]>
Svar till:
[email-masked]<mailto:[email-masked]>
Till:
[email-masked]<mailto:[email-masked]>

A New Internet-Draft is available from the on-line Internet-Drafts directories.

Title : Real-time text media handling in multi-party conferences
Author : Gunnar Hellstrom
Filename : draft-hellstrom-mmusic-multi-party-rtt-00.txt
Pages : 36
Date : 2019-10-31

Abstract:
This memo specifies methods for Real-Time Text (RTT) media handling
in multi-party calls. The main solution is to carry Real-Time text
by the RTP protocol in a time-sampled mode according to RFC 4103.
The main solution for centralized multi-party handling of real-time
text is achieved through a media control unit coordinating multiple
RTP text streams into one RTP session.

Identification for the streams are provided through the RTCP
messages. This mechanism enables the receiving application to
present the received real-time text medium in different ways
according to user preferences. Some presentation related features
are also described explaining suitable variations of transmission and
presentation of text.

Call control features are described for the SIP environment. A
number of alternative methods for providing the multi-party
negotiation, transmission and presentation are discussed and a
recommendation for the main one is provided. Two alternative methods
using a single RTP stream and source identification inline in the
text stream are also described, one of them being provided as a lower
functionality fallback method for endpoints with no multi-party
awareness for RTT.

Brief information is also provided for multi-party RTT in the WebRTC
environment.

EDITOR NOTE: A number of alternatives are specified for discussion.
A decision is needed which alternatives are preferred and then how
the preferred alternatives shall be emphasized.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-hellstrom-mmusic-multi-party-rtt/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-hellstrom-mmusic-multi-party-rtt-00
https://datatracker.ietf.org/doc/html/draft-hellstrom-mmusic-multi-party-rtt-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

_______________________________________________

mmusic mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/mmusic

--

+ + + + + + + + + + + + + +

Gunnar Hellström

Omnitor

[email-masked]<mailto:[email-masked]>

+46 708 204 288

---

From: Gunnar Hellström <[email-masked]>
Date: Tue, 17 Dec 2019 22:53:31 +0000

Hi Christer,

Den 2019-12-17 kl. 09:01, skrev Christer Holmberg:
Hi,

Before we decide on support indicators, we need to decide on how we are going to implement multi-party RTT.
Yes, these discussions at least need to go in parallel. Note that I switched subject now when the topic is multi-party RTT transport alternatives.

 The problem so far has been that it has been said that multi-party RTT can be arranged with regular RTP methods, and that has provided too wide freedom of choice.

So, I want to eventually change the draft to elaborate on either one common alternative for real-time transport for both SIP/RTP and WebRTC, or one each for these two environments. The other alternatives may be briefly mentioned in a background chapter or deleted.

So, let us go through the alternatives, and try to look at both chapter 4 and 5. That is both SIP/RTP and WebRTC.

1. Control code in the T.140 stream.

4.3<https://tools.ietf.org/html/draft-hellstrom-mmusic-multi-party-rtt-00#section-4.3>.  RTP Mixer indicating participants by a control code in the stream

and
5.2<https://tools.ietf.org/html/draft-hellstrom-mmusic-multi-party-rtt-00#section-5.2>.  RTT bridging in WebRTC with one common data channel

Both build on the same principle. The presentation protocol T.140 is extendable. New one letter  function codes can be defined and sent together with a parameter framed by the control codes called SOS and ST as defined in ISO 6429. So, we could define (or rather ask ITU-T SG26 to define) a function code "c" followed by a string uniquely identifying the source of the following text (or rather T140blocks). The data for each transmission request from the mixer should start with the SOS,c,source,ST code as soon as more than two parties are involved in the session. The receiving party need to scan incoming T140blocks and direct the received text to the proper area for presentation of text from each source in one of the suitable styles for RTT presentation (see chapter 9).

For 4.3, the RTP variant, I don't think we need to prescribe any more SDP than a regular one stream RTT plus an indication of multi-party RTT capability.

Example, combining this alternative with capability negotiation 7.3

Offer
 m=text 11000 RTP/AVP 100 98
      a=rtpmap:98 t140/1000
      a=rtpmap:100 red/1000
      a=fmtp:100 98/98/98
      a=rtt-mixer:t140-mixer

Answer of a capable party
 m=text 12000 RTP/AVP 100 98
      a=rtpmap:98 t140/1000
      a=rtpmap:100 red/1000
      a=fmtp:100 98/98/98
      a=rtt-mixer:t140-mixer
The parties can start exchanging multi-party text in one stream with T.140 source indications.

Answer of an uncapable party
 m=text 12000 RTP/AVP 100 98
      a=rtpmap:98 t140/1000
      a=rtpmap:100 red/1000
      a=fmtp:100 98/98/98

The mixer can start sending multi-party text prepared for presentation to a multi-party unaware UA according to chapter 10 and Appendix A, providing a lower functionality fixed view presentation.

This method can be combined with multi-party conferencing control for SIP as said in the beginning of chapter 7

"A method for detection of conference-awareness for centralized SIP conferencing in general is specified in RFC 4579<https://tools.ietf.org/html/rfc4579> [RFC4579<https://tools.ietf.org/html/rfc4579>]. The focus sends the "isfocus" feature tag in a SIP Contact header. This causes the conference-aware UA to subscribe to conference notifications from the focus. The focus then sends notifications to the UA about entering and disappearing conference participants and their media capabilities. The information is carried XML-formatted in a 'conference-info' block in the notification according to RFC<https://tools.ietf.org/html/rfc4575> 4575<https://tools.ietf.org/html/rfc4575>. The mechanism is described in detail in RFC 4575<https://tools.ietf.org/html/rfc4575> [RFC4575<https://tools.ietf.org/html/rfc4575>]."

But I think now that we do not need to make us so dependent on that mechanism. Any way to introduce and delete parties in the conference may be used.  The draft is currently too much tied to use of the RFC 4579 / RFC 4575 procedure.

For 5.2, the WebRTC case with T.140 source marked text, according to draft-ietf-mmusic-t140-usage-data-channel the sdp would be

 Offer:

       m=application 1400 UDP/DTLS/SCTP webrtc-datachannel
       c=IN IP6 2001:db8::3
       a=max-message-size:1000
       a=sctp-port 5000
       a=dcmap:2 label="ACME customer service";subprotocol="t140"
       a=dcsa:2 rtt-mixer:t140-mixer

   Answer from a capable party:

       m=application 2400 UDP/DTLS/SCTP webrtc-datachannel
       c=IN IP6 2001:db8::1
       a=max-message-size:1000
       a=sctp-port 6000
       a=dcmap:2 label="ACME customer service";subprotocol="t140"
       a=dcsa:2 rtt-mixer:t140-mixer

The parties can start exchanging multi-party text in one stream with T.140 source indications.

(and if the negotiation does not find multi-party capability for both parties, then the mixer can start sending according to chapter 10 and Appendix A.)

The exact form of the multi-party capability indication should go into the negotiation discussion belonging to chapter 7. (maybe it should be a new fmtp - parameter instead of a new sdp attribute if using sdp )

Pros:

Equal handling for SIP/RTP and WebRTC
Simple session and stream establishment.

Cons:

The mixer need to manipulate the T.140 stream.
In SIP/RTP, if more than 3 consecutive packets are lost, the source of the loss is not known, and an indication of possible loss needs to be inserted in some other place than in the stream that had loss.
The mixer needs to be allowed to decrypt and encrypt the stream.

I need to stop here and describe the other alternatives another day.

Thanks

Gunnar

Regards,

Christer

From: mmusic <[email-masked]><mailto:[email-masked]> on behalf of Gunnar Hellstrom <[email-masked]><mailto:[email-masked]>
Date: Sunday, 15 December 2019 at 22.25
To: "[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>
Subject: [MMUSIC] Negotiation in draft-hellstrom-mmusic-multi-party-rtt-00.txt

Hi,

Regards

Gunnar

Hi mmusic and avtcore,

Regards

Gunnar Hellström

-------- Vidarebefordrat meddelande --------
Ämne:

Abstract:

mmusic mailing list

--

Gunnar Hellström

Omnitor

+46 708 204 288

--

Gunnar Hellström
Omnitor

---

From: Lorenzo Miniero <[email-masked]>
Date: Wed, 18 Dec 2019 11:07:54 +0100

Hi all,

apologies if I'm chiming in only now. I've recently started working on
an (open source) integration between SIP RTT and WebRTC: I already
exchanged some thoughts with Gunnar in private, but I plan to write a
post to introoduce the effort later today.

Since the effort has been on a server side component that acts like a
gateway, in this context, how to deal with multiparty is indeed
something I'm interested about, so I've added some comments inline.

On Tue, 17 Dec 2019 22:53:31 +0000
Gunnar Hellström <[email-masked]> wrote:

> Before we decide on support indicators, we need to decide on how we
> are going to implement multi-party RTT. Yes, these discussions at
> least need to go in parallel. Note that I switched subject now when
> the topic is multi-party RTT transport alternatives.
> 
>  The problem so far has been that it has been said that multi-party
> RTT can be arranged with regular RTP methods, and that has provided
> too wide freedom of choice.
> 
> So, I want to eventually change the draft to elaborate on either one
> common alternative for real-time transport for both SIP/RTP and
> WebRTC, or one each for these two environments. The other
> alternatives may be briefly mentioned in a background chapter or
> deleted.
> 
> So, let us go through the alternatives, and try to look at both
> chapter 4 and 5. That is both SIP/RTP and WebRTC.
> 
> 4.3<https://tools.ietf.org/html/draft-hellstrom-mmusic-multi-party-rtt-00#section-4.3>.
>  RTP Mixer indicating participants by a control code in the stream
> 
> and
> 5.2<https://tools.ietf.org/html/draft-hellstrom-mmusic-multi-party-rtt-00#section-5.2>.
>  RTT bridging in WebRTC with one common data channel
> 
> Both build on the same principle. The presentation protocol T.140 is
> extendable. New one letter  function codes can be defined and sent
> together with a parameter framed by the control codes called SOS and
> ST as defined in ISO 6429. So, we could define (or rather ask ITU-T
> SG26 to define) a function code "c" followed by a string uniquely
> identifying the source of the following text (or rather T140blocks).
> The data for each transmission request from the mixer should start
> with the SOS,c,source,ST code as soon as more than two parties are
> involved in the session. The receiving party need to scan incoming
> T140blocks and direct the received text to the proper area for
> presentation of text from each source in one of the suitable styles
> for RTT presentation (see chapter 9).
> 
> For 4.3, the RTP variant, I don't think we need to prescribe any more
> SDP than a regular one stream RTT plus an indication of multi-party
> RTT capability.
> 
> The mixer can start sending multi-party text prepared for
> presentation to a multi-party unaware UA according to chapter 10 and
> Appendix A, providing a lower functionality fixed view presentation.
> 
> This method can be combined with multi-party conferencing control for
> SIP as said in the beginning of chapter 7
> 
> 
> "A method for detection of conference-awareness for centralized SIP
> conferencing in general is specified in RFC
> 4579<https://tools.ietf.org/html/rfc4579>
> [RFC4579<https://tools.ietf.org/html/rfc4579>]. The focus sends the
> "isfocus" feature tag in a SIP Contact header. This causes the
> conference-aware UA to subscribe to conference notifications from the
> focus. The focus then sends notifications to the UA about entering
> and disappearing conference participants and their media
> capabilities. The information is carried XML-formatted in a
> 'conference-info' block in the notification according to
> RFC<https://tools.ietf.org/html/rfc4575>
> 4575<https://tools.ietf.org/html/rfc4575>. The mechanism is described
> in detail in RFC 4575<https://tools.ietf.org/html/rfc4575>
> [RFC4575<https://tools.ietf.org/html/rfc4575>]."
> 
> 
> But I think now that we do not need to make us so dependent on that
> mechanism. Any way to introduce and delete parties in the conference
> may be used.  The draft is currently too much tied to use of the RFC
> 4579 / RFC 4575 procedure.
> 
> 
> For 5.2, the WebRTC case with T.140 source marked text, according to
> draft-ietf-mmusic-t140-usage-data-channel the sdp would be
> 
>  Offer:
> 
> (and if the negotiation does not find multi-party capability for both
> parties, then the mixer can start sending according to chapter 10 and
> Appendix A.)
> 
> The exact form of the multi-party capability indication should go
> into the negotiation discussion belonging to chapter 7. (maybe it
> should be a new fmtp - parameter instead of a new sdp attribute if
> using sdp )
> 
> Pros:
> 
> In SIP/RTP, if more than 3 consecutive packets are lost, the source
> of the loss is not known, and an indication of possible loss needs to
> be inserted in some other place than in the stream that had loss. The
> mixer needs to be allowed to decrypt and encrypt the stream.
> 
> 

I'm personally not fond of the idea of the new control code. First of
all, it would require the mixer to indeed terminate the RTT session,
which means end-to-end encryption wouldn't be possible. Besides, with
data channels and the flexibility they provide (e.g., via the label you
can negotiate in the related draft), you don't really need the extra
inband control code to discriminate sessions.

I did read the multiparty document, and did have some opitions going
through the alternatives, so I thought I'd share them quickly here
(apologies to Gunnar if I'm repeating what the draft already says, or
if I'm completely misunderstanding some concepts, as I'm indeed new to
the specification as a whole):

	1. Section 4.1 introduces the usage of different SSRCs for
	different participants, which does seem like a good option to
	me: SSRCs would indeed provide the info required to demultiplex
	and relay participants without having to look at the payload,
	and would be very easy to map to labels when a translation
	to/from a WebRTC session is needed. There is indeed the problem
	of how you advertise those SSRCs, which brings back painful
	memories of the Plan B vs. Unified Plan fight in WebRTC: this
	section suggests a single m-line (à-la Plan B, I believe),
	which has some drawbackas; different participants may
	use different approaches (e.g., some may be using red, other
	t140, and payload types may differ) which indeed complicates
	the SDP negotiation, especially if the mixer is supposed to
	just relay those streams and not terminate them.

	2. Section 4.2 suggests using a shared SSRC, and using CSRC to
	mention participants. Again, the need for decrypting the
	traffic is problematic. Besides, I'm not sure detecting packet
	loss would be trivial as the document states: if the SSRC is
	shared, so is the timestamp/sequence number space, which means
	that it would be problematic, if not downright impossible, to
	detect packet losses for a specific participant at the source,
	considering sequence numbers originated by the mixer may be
	increasing sequentially with no gaps in between. Probably I'm
	missing something obvious in the scenario?

	3. Section 4.3 is where the new control code Gunnar described
	is introduced, and I already shared my view on why I'm not
	particularly fond of the idea.

	4. Section 4.4 describes a full mesh, which does work but is
	indeed more "verbose", and requires multiple sessions to take
	place, and may be a bit overkill. That said, one of the pros
	the document suggests is that this should be possible with most
	RTP implementations, which isn't to be ignored: I'd consider
	this a good backup when dealing with participants unaware of
	whatever method will be chosen, possibly establishing the
	multiple sessions with the mixer itself, though, rather than
	the other participants themselves.

	5. Section 4.5 documents the approach where multiple RTP
	sessions are negotiated, one per participant, I guess via
	separate m-lines. This is indeed a variant of 4.1 which again
	brings back the Plan B vs. Unified Plan discussion that
	happened in WebRTC, where the former signalled multiple SSRCs
	on the same m-line, and the latter used separate m-lines
	instead. Whatever signalling approach is used, I do feel that
	using SSRCs to demultiplex would make the process simpler.

	6. Finally, section 4.6 introduces the concept of "mixing" for
	RTT streams, which I'm not a fan of either, as it "flattens"
	everything, breaking end-to-end encryption when available in
	the process. The document provides even more cons, and
	clarifies how it should only be a last resort, which I agree on.

On the WebRTC side, things are much easier I believe. The approach
suggested in 5.1 is definitely what I'd go with, that is leveraging
labels to demultiplex participants: I wouldn't be too concerned about
the overhead of establishing a high number of channels, as most
implementations have ways to deal with high numbers anyway.

Lorenzo

> Thanks
> 
> Gunnar
> 
> Regards,
> 
> Christer
> 
> From: mmusic
> <[email-masked]><mailto:[email-masked]> on behalf
> of Gunnar Hellstrom
> <[email-masked]><mailto:[email-masked]>
> Date: Sunday, 15 December 2019 at 22.25 To:
> "[email-masked]"<mailto:[email-masked]>
> <[email-masked]><mailto:[email-masked]> Subject: [MMUSIC]
> Negotiation in draft-hellstrom-mmusic-multi-party-rtt-00.txt
> 
> 
> Hi,
> 
> draft-hellstrom-mmusic-multi-party-rtt/<https://datatracker.ietf.org/doc/draft-hellstrom-mmusic-multi-party-rtt/>
> currently contains sets of alternative solutions for different
> aspects of multi-party real-time text (RTT).
> 
> I would like to discuss these alternatives aspect by aspect, and
> eventually reduce them to one solution per aspect. By aspects, I mean
> negotiation for SIP, negotiation for WebRTC, source identification
> and multi-party transport for SIP, source identification and
> multi-party transport for WebRTC and mixing for the multi-party
> unaware case.
> 
> The main requirements are described in section 3 of the draft. One
> requirement is that the solution should be implementable in a near
> future. Point-to-point RTT solutions based on SIP and RTP with RFC
> 4103 transport are implemented, and there are cases where upgrade to
> multi-party support is urgent. It is assumed that most multi-party
> cases will be based on one central bridge. The media coding is
> according to ITU-T T.140, that is Unicode text transmitted UTF-8
> transformed, with some control codes from ISO 6429. Transmission
> takes place without any special action by the user other than
> creating text. Transmission is usually time sampled in about 300 ms
> samples.
> 
> I want to start with the negotiation aspect. Before the bridge can
> start transmitting RTT in a way suitable for good presentation of
> multi-party RTT, it must know that the receiving party is capable of
> separating text from the different participants. Also the UA may need
> an indication that it should include source information in a specific
> way for multi-party RTT to work..
> 
> 7.1 Implicit negotiation by the bridge expressing RTT multi-party
> capability indications according to RFC 4575, and the UA showing
> multi-party awareness only if it supports multi-party RTT.
> 
> 7.2 Define a new SIP media tag indicating RTT multi-party capability.
> Start using multi-party RTT after a successful capability exchange.
> 
> 7.3 Define a new SDP attribute on media level, indicating RTT
> multi-party capability. Start using multi-party RTT after a
> successful capability exchange.
> 
> I have replaced an old expired draft about real-time text multi-party
> handling. It touches both transport and negotiation topics, so I am
> sending this to both mmusic and avtcore, but I hope we can keep the
> discussion in mmusic. So, please respond with your comments to mmusic.
> 
> Right now, the draft is a discussion paper. I intend to convert it to
> a true BCP format after some discussions on the preferences I have
> proposed.
> 
> Regards
> 
> Gunnar Hellström
> 
> 
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
> 

-- 
I'm getting older but, unlike whisky, I'm not getting any better
https://twitter.com/elminiero

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 19 Dec 2019 08:59:01 +0000

Hi Gunnar,

I don’t think you need to describe the SDP in an e-mail – describe it in the draft instead :)

In addition, you need to describe the RTP considerations, regarding single SSRC etc.

I think it would be good to, for each alternative, have the following sub-sections.

SDP Considerations

  *   Here you describe how the SDP looks like

RTP Considerations

  *   Here you describe things like SSRC etc.

T.140 Considerations

  *   Here you describe whether some T.140 extensions etc are needed.

Much of the text already exists in the draft, but I think putting it into separate sub-sections would make it easier to read.

Thanks!

Regards,

Christer

From: Gunnar Hellstrom <[email-masked]>
Date: Wednesday, 18 December 2019 at 0.53
To: Christer Holmberg <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Multi-party transport in draft-hellstrom-mmusic-multi-party-rtt-00.txt

Hi Christer,

and

Offer

      a=rtpmap:98 t140/1000

      a=rtpmap:100 red/1000

      a=fmtp:100 98/98/98

      a=rtt-mixer:t140-mixer

      a=rtpmap:98 t140/1000

      a=rtpmap:100 red/1000

      a=fmtp:100 98/98/98

      a=rtt-mixer:t140-mixer

      a=rtpmap:98 t140/1000

      a=rtpmap:100 red/1000

      a=fmtp:100 98/98/98

 Offer:

       c=IN IP6 2001:db8::3

       a=max-message-size:1000

       a=sctp-port 5000

       c=IN IP6 2001:db8::1

       a=max-message-size:1000

       a=sctp-port 6000

Pros:

Cons:

Thanks

Gunnar

Regards,

Christer

Hi,

Regards

Gunnar

Hi mmusic and avtcore,

Regards

Gunnar Hellström

-------- Vidarebefordrat meddelande --------
Ämne:

Abstract:

mmusic mailing list

--

Gunnar Hellström

Omnitor

+46 708 204 288

--

Gunnar Hellström

Omnitor

+46 708 204 288

---

From: Gunnar Hellström <[email-masked]>
Date: Thu, 19 Dec 2019 09:19:00 +0000

Thanks Lorenzo for your views on the different transport and mixing 
alternatives.

I intend to continue the overview of the alternatives that Christer 
asked for.

But, in the meantime:

It would be good to have comments on if there are any specific methods 
for signaling multi-party control for WebRTC, e.g. announcing the focus 
role and announcing participants' entry and departure and capabilities 
to the conference.

And also if the RFC 7579 / RFC 7575 SIP conference control is so 
widespread that it would be suitable to rely on it in the SIP 
environment for  e.g. announcing the focus role and announcing 
participants' entry and departure and capabilities to the conference.

About your comment that the conference-unaware mixing alternative: Yes, 
it is not favourable, but possible. And I think it is needed in order to 
be able to introduce multi-party support in services where there are 
already many conference-unaware UAs out there.

One factor that you find not good for that method and the T140-mixing 
method is that the mixer need to be able to decrypt and encrypt the text 
stream. Is that not usually the case for the other media, audio and 
video in the centralized bridge mixing?

Thanks,

Gunnar

-- 

Gunnar Hellström
Omnitor
[email-masked]
+46 708 204 288

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 19 Dec 2019 11:11:21 +0000

Hi,

Regarding how to signal, at the moment my strong preference is to use a single m- line for RTP-based multi-party RTT, in one way or another. Having a separate m- line for each remote participant doesn't scale, and would probably not work in many networks. It could also cause lots of offer/answer transactions when people are joining/leaving conferences.

Regards,

Christer

On 19/12/2019, 11.19, "mmusic on behalf of Gunnar Hellström" <[email-masked] on behalf of [email-masked]> wrote:

    
    But, in the meantime:

    

    Thanks,
    
    Gunnar
    
    -- 

    Gunnar Hellström
    Omnitor
    
    [email-masked]