gmane.ietf.mmusic

Re: Bundle offer with different ports - where to expect media?

Paul Kyzivat — 2013-05-20T15:09:03

It is a different case because the same port *can't* both be used as the 
bundle port and a port for an unbundled m-line.


There are many reasons that an answerer may reject an m-line.
It is *possible* that it is rejecting it because it has a problem with 
the address (c=) for the m-line in the offer. If so, then if you insist 
on using it as the bundle address, even if the m-line is refused, then 
there is no way for the answerer to refuse it.

(*Why* it would have a problem is an open question. Maybe its IPv6 and 
the answerer can't use it, or maybe its an FQDN and it can't be 
resolved. I realize this is unlikely. But making the assumption that the 
address must be acceptable to the answerer is IMO not a good idea.)


I presume you must have a motivation for wanting to go this way.
Are you thinking this will simplify the implementation? What do you 
think you can avoid doing my making this assumption?

Thanks,
Paul

Re: Bundle offer with different ports - where to expect media?

Emil Ivov — 2013-05-20T14:51:47

Hey Christer,

On 20.05.13, 17:16, Christer Holmberg wrote:

I don't see how we could allow it in one case and disallow it in the
other. The only difference between the two cases is how informed the
offerer is about the answerers bundle support capabilities and I don't
really understand why this would influence the decision to allow
splitting bundles one way or the other.


Well, how about looking at it this way: the offerer specifies a bundle
port in the first m=line. This also happens to be the port for the first
media line but the two are different things and just happen to have the
same value for reasons related to syntax and convenience.

A bundle supporting answerer should understand this. After receiving the
offer that answerer has learned the bundle port number. Rejecting the
first m=line in the answer does not change this.

Of course the answer would come with the first m=line having a 0 port
but the offerer would then just learn the bundle port number at the
first m=line with a non-zero port.

Subs

Re: Reply to Liaison statement to IETF concerning 3D video

Mary Barnes — 2013-05-20T14:39:52

Whether or not you explicitly mention the IPR, I think it should be
mentioned that the document was adopted as a WG document but latter
dropped due to some of the reasons you note. It it not a common
occurrence for a document to be agreed as a WG document and then
shortly thereafter have that decision revert. So, I think it's worth a
mention.

Thanks,
Mary.

On Fri, May 17, 2013 at 1:01 PM, Flemming Andreasen <fandreas< at >cisco.com> wrote:

Re: Bundle offer with different ports - where to expect media?

Christer Holmberg — 2013-05-20T14:16:59

Hi,


I suggested that it should never be allowed to split an m- line from a bundle group in an answer, but others had other opinions.

HOWEVER, it would still not help in the case where the 1st m- line is rejected.

Regards,

Christer

Re: Bundle offer with different ports - where to expectmedia?

Emil Ivov — 2013-05-20T14:12:35

On May 20, 2013 4:50 PM, "Christer Holmberg" <christer.holmberg< at >ericsson.com>
wrote:
sends all m-lines with the same port, then the answerer
send everything to the same port?

Yes, sorry, I didn't follow this closely.


OK, so shouldn't the same thing happen in the case with different ports?

Emil

--sent from my mobile
_______________________________________________
mmusic mailing list
mmusic< at >ietf.org
https://www.ietf.org/mailman/listinfo/mmusic

Re: MMUSIC Working Group Virtual Interim Meeting, May 23, 2013

Christer Holmberg — 2013-05-20T14:11:32

Hi,

The main technical issues for BUNDLE at the moment are:

1)How to demux RTP (and other media types, but RTP is the most critical). This is currently discussed within the "Plan A vs Plan B" context on the RTCWEB list.

2)Where to send media until an O/A exchange with identical port number has taken place. This is currently discussed on the MMUSIC list ("Bundle offer with different ports - where to expect media?").

Regards,

Christer



-----Original Message-----
From: mmusic-bounces< at >ietf.org [mailto:mmusic-bounces< at >ietf.org] On Behalf Of Ari Keränen
Sent: 16. toukokuuta 2013 23:06
To: mmusic< at >ietf.org
Cc: Flemming Andreasen
Subject: Re: [MMUSIC] MMUSIC Working Group Virtual Interim Meeting, May 23, 2013

All,

Since it seems that many of the key draft authors of the Plan A vs. Plan B discussion are unable to attend the virtual interim at the planned time, we have decided to focus at this interim on the open issues in the Bundle draft.

For details please read the current Bundle draft:
http://tools.ietf

Re: Bundle offer with different ports - where to expect media?

Hutton, Andrew — 2013-05-20T14:00:23

On 20 May 2013 14:39 Paul Kyzivat Wrote:



Also the offerer therefore needs to be prepared to send the bundled media from this port or immediately initiate a new offer indicating a different port for the bundle.


Andy

Re: Bundle offer with different ports - where toexpectmedia?

Christer Holmberg — 2013-05-20T13:50:23

Hi,


We discussed this week, and the outcome (at least my read of it :) was that the answerer is not allowed to split any m- lines away from the bundle in this case. Instead the answerer will have to send a new offer for the split, allowing new ports to be negotiated at both ends.

Regards,

Christer





If so, I don't see why it should be different in the case where the offerer could not make the assumption about the bundle support.
--sent from my mobile
On May 20, 2013 4:39 PM, "Paul Kyzivat" <pkyzivat< at >alum.mit.edu> wrote:
I agree with Christer's analysis here. The bundle port must be one associated with an m-line that is accepted, and included in the bundle, in the answer. That means the bundle port may not be the one from the first bundled m-line in the offer.

A corollary of that is that the offerer needs to be prepared to receive bundled media on any of the ports listed in the offer.

        Thanks,
        Paul

On 5/20/13 9:27 AM, Christer Holmberg wrote:
Hi,
Agree with Emil but think mayb

Re: Bundle offer with different ports - where to expectmedia?

Emil Ivov — 2013-05-20T13:46:37

What happens when the offerer knows the answerer has bundle support, sends
all m-lines with the same port, then the answerer splits the first line
away from the bundle? Would the answerer still send everything to the same
port?

If so, I don't see why it should be different in the case where the offerer
could not make the assumption about the bundle support.

--sent from my mobile
On May 20, 2013 4:39 PM, "Paul Kyzivat" <pkyzivat< at >alum.mit.edu> wrote:

_______________________________________________
mmusic mailing list
mmusic< at >ietf.org
https://www.ietf.org/mailman/listinfo/mmusic

Re: Bundle offer with different ports - where to expect media?

Paul Kyzivat — 2013-05-20T13:38:48

I agree with Christer's analysis here. The bundle port must be one 
associated with an m-line that is accepted, and included in the bundle, 
in the answer. That means the bundle port may not be the one from the 
first bundled m-line in the offer.

A corollary of that is that the offerer needs to be prepared to receive 
bundled media on any of the ports listed in the offer.

Thanks,
Paul

On 5/20/13 9:27 AM, Christer Holmberg wrote:

Re: Bundle offer with different ports - where to expect media?

Christer Holmberg — 2013-05-20T13:27:35

Hi,


I agree that is what the spec currently says. 

But, again, the following can happen:

1) The answerer rejects the 1st m- line; or

2) The answerer accepts the 1st m- line, but removes it from the bundle group. Yes, in this case the answerer WILL send media on that port, but ONLY media associated with that m- line (as it is no long part of the bundle group). The media associated with the remaining m- lines in the bundle group has to be sent somewhere else.

Again, once the second offer has been sent, the "bundle port" is explicitly signaled (as each m- line in the bundle group uses the same port number).

Regards,

Christer

Re: Bundle offer with different ports - where to expect media?

Emil Ivov — 2013-05-20T13:18:21

+1


Agreed.

Emil

Re: Bundle offer with different ports - where to expect media?

Hutton, Andrew — 2013-05-20T13:14:45

Agree with Emil but think maybe the question was meant to be on which port(s) it needs to be able to receive bundled media.

This is covered by the last para in section 6.3 which states that the answerer MUST use the port and everything else relating to the 1st m= line. So far I thought this to be reasonable and even if the 1st m= line is rejected this can still be the bundle port.

We could say that any port in the bundle could be used but I don't see this gains us anything.

Andy

Re: Bundle offer with different ports - where to expect media?

Emil Ivov — 2013-05-20T12:12:38

Hey Christer,

On 20.05.13, 14:43, Christer Holmberg wrote:

Do we really have a choice here? We send the offer with different port
numbers so that it would work with endpoints that have no knowledge of
bundle. Such endpoints can start streaming media to any port. Bundled
devices can, on the other hand, start streaming media on the bundle port.

So in other words, the offerer need to expect media arriving on any port
just as it needs to expect any stream arriving on the bundle port.

This would be consistent with what we do for rtcp-mux.

Emil

Bundle offer with different ports - where to expect media?

Christer Holmberg — 2013-05-20T11:43:30

Hi,

Currently BUNDLE defines that the first offer is sent with separate port numbers (later, if the answerer has indicated support of BUNDLE, the offerer will send a second offer, with identical port numbers).

Some people have indicated that the offerer shall be able to receive data already when the first offer has been sent. The question is on which port(s) it needs to be able to receive media.


-          Some have suggested the port of the first non-zero m- line within the offered bundle group.

-          Some have suggested ANY port


The issue with assuming the first non-zero m- line is that the answerer in the answer may reject it (put the port to zero), or remove it from the bundle group (which people seem to want to allow). In both cases it would be strange to assume the first m- line.

Now, in case e.g. ICE is used, the offerer will be able to send the second offer before any media is received to begin with. But, the offerer could still receive STUN connectivity checks on any of the ports, until

Re: Reply to Liaison statement to IETF concerning 3D video

Flemming Andreasen — 2013-05-17T18:01:51

On 5/16/13 4:21 PM, Mary Barnes wrote:
I wouldn't say the drafts were dropped due to IPR (but understand that 
different people may have different opinions on this), however the lack 
of an IPR disclosure prior to the documents' original adoption as WG 
items resulted in them going back to individual drafts. IPR disclosures 
were then made in accordance with IETF requirements, and following that, 
we had a renewed discussion in the WG around interest in the work as 
well as relevant expertise in the WG. As part of that, we noted the lack 
of coordination with and requirements from external bodies with respect 
to 3D video. There were also different opinions on the technical 
approach. In the end, as you note, there was not sufficient interest or 
concensus in the WG for adopting the work (as noted below).

If you think it's important to convey the IPR issue and the history 
around that, we can certainly do so. Personally, I don't think it 
changes anything and wouldn't want to suggest any presupposition as

Re: MMUSIC Working Group Virtual Interim Meeting, May 23, 2013

Ari Keränen — 2013-05-17T16:36:23

Whether we can have the f2f is still open too (the proposed date seems 
to collide with the WebRTC expo at Atlanta). We're working on figuring 
out possibilities for both a new virtual and/or f2f.


Cheers,
Ari

On 5/17/13 4:54 PM, Mary Barnes wrote:

Re: 1 Week WGLC fordraft-ietf-mmusic-rtsp-nat-evaluation-06

Ari Keränen — 2013-05-17T15:49:36

Hi,

I had a quick read over the draft and have a few comments:

3.  Requirements on NAT-Traversal

    1.  Must work for all flavors of NATs, including NATs with address
        and port restricted filtering.

The term used by RFC 4787 is "Address and Port-Dependent Filtering"


3.  Requirements on NAT-Traversal

    The list of feature requirements for RTSP NAT solutions are given
    below:

I guess this should say "RTSP NAT traversal solutions".


        *  Address discovery for NAT traversal should take automatically,
           if possible

I assume this means the discovery of the address assigned by the NAT? 
Maybe say that explicitly, e.g., "Discovery of the address(es) assigned 
by NAT should happen automatically if possible".


4.7.4.  Security Considerations

    An ALG will not work whit deployment of end-to-end RTSP signaling

Typo: whit


4.9.1.  [TURN] Introduction

    On the external side this is
    limited to the source address/port pair of the first packet arriving
    on the binding.  A

Re: What is an m-line?

Paul Kyzivat — 2013-05-17T15:22:15

Yes and no.

The INVITE/Replaces is analogous to establishing a new PeerConnection 
and asking it to replace the old one. I guess you could say that the 
'Replaces' augments the SDP by saying 'bind this to the devices used in 
that other call'.

More generally, yes the SIP can influence the SDP interpretation a 
little bit. (E.g. by using SIP Options.) But it is a blunt instrument, 
and usually proposals to do so get argued down as layer violations. 
There certainly is no precision to delve down to influence individual 
m-lines.

Thanks,
Paul

1 Week WGLC for draft-ietf-mmusic-rtsp-nat-15

Flemming Andreasen — 2013-05-17T14:04:05

The rtsp-nat draft reflects analysis done in the rtsp-nat-evaluation 
draft, which just concluded a reissued WGLC. We previously had a 2 week 
WGLC on the rtsp-nat-14 draft, which resulted in a few updates. In lieu 
of this, we are announcing a 1 week Working Group Last Call for any 
final comments on

     draft-ietf-mmusic-rtsp-nat-15

as Proposed Standard. Please review and provide any comments you may 
have on the document by May 25, 2013. Comments should be sent to the 
document authors and the MMUSIC WG list. If you review the document but 
do not have any comments, please send a note to that effect as well.

Thanks

        Flemming


Draft Info:

A New Internet-Draft is available from the on-line Internet-Drafts directories.
  This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF.

Title           : A Network Address Translator (NAT) Traversal mechanism for media controlled by Real-Time Streaming Protocol (RTSP)
Author(s)       : Jeff Goldberg

Re: 1 Week WGLC fordraft-ietf-mmusic-rtsp-nat-evaluation-06

Flemming Andreasen — 2013-05-17T13:54:11

The WGLC has now ended. We did not receive any comments and hence the 
document is ready to move forward at this point.

Thanks