Subject: [MMUSIC] draft-ivov-mmusic-trickle-ice-sip-00

From: Paul Kyzivat <[email-masked]>
Date: Thu, 25 Jul 2013 13:09:20 -0400

(I was rereviewing this in prep for the meeting)

Section 4 says that trickled candidates are transported as INFO payloads 
containing SDP formatted according to ivov-mmusic-trickle-ice. But 
AFAICT that draft doesn't specify this. Also the example in this section 
shows an info payload that contains only a subset of SDP, and doesn't 
conform to mime type application/sdp.

Section 5.6 again references the trickle-ice draft (section 4) for 
definition of the body of the info message, but that section of that 
draft doesn't contain any such definition.

Aside from that, it occurs to me that trickle-ice, and for that matter 
ice in sip even without trickle, is a good candidate for preconditions. 
The use of preconditions could eliminate the need for half trickle. This 
would of course require a new precondition type, but that is doable.

By using preconditions, you can establish the dialog without alerting 
the callee. Then the alert can be deferred until at least one workable 
path has been detected.

(But I suppose the hate for preconditions is so great that this is not 
to be considered.)

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 25 Jul 2013 18:36:41 +0000

Hi Paul,

Are you sure a new type is needed? The existing types are rather generic, aren't they?

Also, if people don't like the precondition mechanism, another option is to simply set the streams to inactive until enough candidates are collected, and specify that trickle ICE UASs don't alert the user until the direction attribute is changed to a non-inactive value. E.g. 3GPP has done that for many years.

Regards,

Christer

Sent from Windows using TouchDown (www.nitrodesk.com)

-----Original Message-----
From: Paul Kyzivat [[email-masked]]
To: IETF MMUSIC WG [[email-masked]]; Emil Ivov [[email-masked]]
Subject: [MMUSIC] draft-ivov-mmusic-trickle-ice-sip-00

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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 25 Jul 2013 14:55:30 -0400

> Are you sure a new type is needed? The existing types are rather

I'm not sure, but I thought they were more specific than that.
Maybe there is some type that is sufficiently general.

> Also, if people don't like the precondition mechanism, another option is
> to simply set the streams to inactive until enough candidates are
> collected, and specify that trickle ICE UASs don't alert the user until
> the direction attribute is changed to a non-inactive value. E.g. 3GPP
> has done that for many years.

I hadn't heard of specifying a change in alerting behavior based on 
inactive. That seems weird and improper to me.

	Thanks,
	Paul

> Regards,
> Christer
>
> Sent from */Windows/* using *TouchDown* (www.nitrodesk.com)
>
> *From:* Paul Kyzivat [[email-masked]]
> *To:* IETF MMUSIC WG [[email-masked]]; Emil Ivov [[email-masked]]
> *Subject:* [MMUSIC] draft-ivov-mmusic-trickle-ice-sip-00

---

From: Emil Ivov <[email-masked]>
Date: Thu, 25 Jul 2013 20:57:22 +0200

Hey folks,

> Are you sure a new type is needed? The existing types are rather

Back in Boston we decided to do something like this:

http://tools.ietf.org/html/draft-ivov-dispatch-sdpfrag-00

More below:

> On 25.07.13, 19:09, Paul Kyzivat wrote:
>
> AFAICT that draft doesn't specify this.

Well, it just borrows the format from 5245 and says that this is how you 
represent trickled candidates.

> Also the example in this section

Yup, should be application/sdpfrag.

> draft doesn't contain any such definition.

Will need to fix.

> would of course require a new precondition type, but that is doable.

Hmmm ... that's a good point!

> (But I suppose the hate for preconditions is so great that this is not

Well, it doesn't have to be mandatory ...

Emil

-- 
https://jitsi.org

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 25 Jul 2013 19:08:44 +0000

Hi Paul,

I don't thin 3261 specifies when a user must be alerted, does it? ;)

Anyway, it was just one example of how people have achieved "delayed user alerting" without using the precondition mechanism.

Regards,

Christer

-----Original Message-----
From: Paul Kyzivat [[email-masked]]
To: Christer Holmberg [[email-masked]]
CC: IETF MMUSIC WG [[email-masked]]; Emil Ivov [[email-masked]]
Subject: Re: [MMUSIC] draft-ivov-mmusic-trickle-ice-sip-00

        Thanks,
        Paul

> Regards,
> Christer
>
> Sent from */Windows/* using *TouchDown* (www.nitrodesk.com<http://www.nitrodesk.com>)
>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 25 Jul 2013 19:11:41 +0000

Hi Emil,

I don't think Paul was talking about a new MIME types, but the type values used for the precondition mechanism. Paul?

Regards,

Christer

-----Original Message-----
From: Emil Ivov [[email-masked]]
To: Christer Holmberg [[email-masked]]
CC: Paul Kyzivat [[email-masked]]; IETF MMUSIC WG [[email-masked]]
Subject: Re: [MMUSIC] draft-ivov-mmusic-trickle-ice-sip-00
Hey folks,

Will need to fix.

Emil

--
https://jitsi.org

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 25 Jul 2013 16:04:56 -0400

> http://tools.ietf.org/html/draft-ivov-dispatch-sdpfrag-00

I thought Christer was talking about my suggestion that preconditions 
would require a new precondition type. Nothing to do with the mime type.

> represent trickled candidates.

But all of that assumes a full SDP body. And it seems you don't.
Your draft somewhere has a mention that the trickled stuff must be keyed 
to a media section via mid, but nothing formally written about it.

> Yup, should be application/sdpfrag.

Well, AFAIK there is currently no such mime type. So its necessary to 
define it.

And while you could define a generic one, you have some specific 
requirements about what this needs to contain, so you might want to 
define application/trickle-ice-sdp with all the requisite rules.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 25 Jul 2013 16:06:58 -0400

> I don't thin 3261 specifies when a user must be alerted, does it? ;)

No, I don't think so.

I didn't say it was an invalid thing to do, just improper and weird. :-)

IOW, it doesn't smell right to me.

	Thanks,
	Paul

> Anyway, it was just one example of how people have achieved "delayed
> user alerting" without using the precondition mechanism.
> Regards,
> Christer
>
> *To:* Christer Holmberg [[email-masked]]
> *CC:* IETF MMUSIC WG [[email-masked]]; Emil Ivov [[email-masked]]
> *Subject:* Re: [MMUSIC] draft-ivov-mmusic-trickle-ice-sip-00
>> Sent from */Windows/* using *TouchDown* (www.nitrodesk.com <http://www.nitrodesk.com>)
>>

---

From: Emil Ivov <[email-masked]>
Date: Thu, 25 Jul 2013 22:42:17 +0200

Hey Paul,

> would require a new precondition type. Nothing to do with the mime type.

Sorry, the above was meant to go underneath your comment about how this: 
"doesn't conform to mime type application/sdp."

But I messed up the quoting.

> But all of that assumes a full SDP body.

I don't see how the syntax of an "a=candidate" line depends on the full 
SDP body, so I don't see the problem with just pointing there. Again, I 
mean this only about syntax.

> And it seems you don't.

Yes agreed. This will have to be expanded in trickle-ice-sip.
> Well, AFAIK there is currently no such mime type. So its necessary to

This is the point of the draft I pasted above:
http://tools.ietf.org/html/draft-ivov-dispatch-sdpfrag-00

Of course, it does need more work (by the way, help there is more than 
welcome so if you want to join just let me know).

> define application/trickle-ice-sdp with all the requisite rules.

The original idea (which I believe came from Adam) was that this could 
be avoided in a way similar to how application/sipfrag does it. I 
basically specifies syntax (as a SIP subset) and leaves semantics to 
specs that are using it, like for example 3515

Do you see any reason why this couldn't work here?

Emil

> .

-- 
https://jitsi.org

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 25 Jul 2013 17:46:02 -0400

> mean this only about syntax.

My point is that 5245 never suggests that ICE will be represented in SDP 
in anything but a full SDP body.

If you said that you were proposing to send subsets of SDP as described 
in 5245, that would make some sense. (As long as you specify how to 
select the subset.)

> welcome so if you want to join just let me know).

Oh, duh. That slipped right by me. But of course it is incomplete.

> Do you see any reason why this couldn't work here?

Its a choice. In the case of sipfrag, IIRC it was defined for use with 
3515. In that it isn't crucial what is in it. So it works there.

In your case what goes in it is more critical. It can still be defined 
this way. But it will take some care to get it right.

The main thing is that it be done somewhere!

Can an INFO trickle ICE candidates for more than one m-line?
If so, it gets messy. Consider a full SDP:

...
m=...
a=mid:1
a=candidate:...
...
m=...
a=candidate:...
a=mid:2
a=candidate:...

(AFAIK the above is entirely legal.)

Now consider a sipfrag for trickle from the above:

a=mid:1
a=candidate:...
a=candidate:...
a=mid:2
a=candidate:...

Now, which candidates go with which m-line? So, I think your sdpfrag 
needs special constraints that don't apply to ICE in full SDP.

	Thanks,
	Paul

---

From: Emil Ivov <[email-masked]>
Date: Fri, 26 Jul 2013 00:32:31 +0200

Hey Paul,

On 25.07.13, 23:46, Paul Kyzivat wrote:
> in 5245, that would make some sense.

The section that deals with this is 9.1

http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-00#section-9.1

The intention is exactly what you describe above.

> (As long as you specify how to
> select the subset.)

The subset is an "a=candidate" line. I don't think select is the right 
word here though. You just encode an ICE candidate, as you would encode 
it for an SDP offer or answer.

> I could help, once I understand what it needs to say.

Great!

> The first decision is:

Did you miss something here?

> The main thing is that it be done somewhere!

Agreed!

> Can an INFO trickle ICE candidates for more than one m-line?

Yes.

> needs special constraints that don't apply to ICE in full SDP.

I think the problem with the above is that you are trying to present it 
as an extract from some pre-existing offer or answer, while it isn't.

When you are trickling you find yourself in a situation where you have 
one or more newly learned candidates. You want to send those to the 
remote agent.

To do this you group them by stream (as in "m=" line). For each group 
you start by creating an "a=mid:x" attribute that matches the one from 
the "m=" line that created the stream. You then create and append 
"a=candidate" lines for every candidate in that group.

That's it.

The receiving peer does the opposite: it parses the "a=mid:x" line, it 
finds the stream object that it refers to, then parses all the 
candidates and adds them there.

Does this make sense?

Emil

-- 
https://jitsi.org

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 25 Jul 2013 19:26:18 -0400

Emil,

> The intention is exactly what you describe above.

Maybe you intended that. But I don't find sufficient words in the doc to 
determine what you mean. The words that seem to pertain to this are:

    Given that such lines do not provide a relationship between the
    candidate and the m line that it relates to, signalling protocols
    using trickle ICE MUST establish that relation themselves.  This can
    be done in one of two ways: using the m-line index, or an MID
    [RFC3388].  The m-line index is a zero-based index, referring to the
    Nth m-line in the SDP.  The MID uses "media stream identification",
    as defined in [RFC3388], to identify the m-line.

So I'm supposed to infer that you are proposing to use a subset of SDP 
from that???

Also, what does "signalling protocols using trickle ICE MUST establish 
that relation themselves" *mean*? Does it mean that you intend the INFO 
message containing the trickle ice info in its body to specify the 
m-line somewhere other than in the same body???

I would expect that the body you send would include something to do 
this. If you use mid, then the syntax to do so already exists, sort of. 
If you use m-line index, then it doesn't.

> Did you miss something here?

I forget. It doesn't matter.

> "a=candidate" lines for every candidate in that group.

I thought that is what you had in mind.

But you have said you want to use application/sdpfrag, which means it 
should be viewed as a subset of a full SDP. And that is especially so if 
you intend to reference m-lines in an SDP, but don't want to include 
them. And you haven't defined any new ordering rules for lines other 
than what exist for SDP. And SDP allows the ordering I show above, which 
doesn't work for you.

I'll also mention that I think you need to explicitly reference the SDP 
offer or answer that this trickle updates. Probably by replicating the 
o-line from that SDP.

So there are some significant syntax rules that need to be followed 
here. I would expect something like:

- must start with o-line of the SDP it is updating
- has one or more "media sections"
- each media section begins with an a:mid line, referencing
   a mid defined in the referenced SDP
- each a:mid line is followed by one or more a:candidate lines
...

If going that way, then I think it is better to define a mime type that 
consists of exactly this syntax, with some extensibility hooks.

	Thanks,
	Paul

---

From: Emil Ivov <[email-masked]>
Date: Fri, 26 Jul 2013 02:24:38 +0200

> So I'm supposed to infer that you are proposing to use a subset of SDP

No, you are not. This is the generic trickle ICE draft and it says: when 
using trickle with a specific protocol, make sure you match candidates 
to m= lines through use of MIDs.

It can't say anything more here because XMPP would encode the MID value 
  one way (i.e. using content names attributes), SIP another (using 
a=mid) and WebRTC apps in yet another (likely json).

> that relation themselves" *mean*?

I hope the above answers your question.

> Does it mean that you intend the INFO

I don't understand this part. Didn't my previous mail clarify this?

Here's an example:

          INFO sip:[email-masked] SIP/2.0
          ...
          Info-Package: trickle-ice
          Content-type: application/sdp
          Content-Disposition: Info-Package
          Content-length: ...

          a=mid:1
          a=candidate:1 1 UDP 1658497328 192.168.100.33 5000 typ host
          a=candidate:2 1 UDP 1658497328 96.1.2.3 5000 typ srflx
          a=mid:2
          a=candidate:2 1 UDP 1658497328 96.1.2.3 5002 typ srflx
          a=end-of-candidates

That's the entire body and there are no m= lines in it.

> If you use m-line index, then it doesn't.

We kind of decided not to use "m=" line index in one of the previous 
meetings so we are only going for MID. The draft hasn't been updated 
since so it still refers to "m=" line index in a few locations but they 
will go.

> should be viewed as a subset of a full SDP.

Doesn't this apply to the INFO example that I pasted above? Why could it 
not be viewed as a subset of *some* valid full SDP?

> And that is especially so if
> you intend to reference m-lines in an SDP

No, there's no such intention any more.

> , but don't want to include

I agree that there's no such definition in the draft. I did provide 
example rules in a couple of paragraphs above though. Do you see a 
problem using this logic as basis for defining the ordering in 
trickle-ice-sip?

> offer or answer that this trickle updates. Probably by replicating the

That's a good point. We do need this for SIP. I'll make sure we add it.

> - each a:mid line is followed by one or more a:candidate lines

Sounds great to me!

> consists of exactly this syntax, with some extensibility hooks.

Are you proposing this because you think this MIME type could be reused 
by someone else?

Personally I don't really mind.

However, if we leave sdpfrag with the current intention (i.e. any SDP 
line or combination of lines work) and then define the specifics in 
trickle-ice-sip, then we have a MIME type for the a=candidate lines that 
come out of WebRTC browsers, should anyone every need this.

Cheers,
Emil

-- 
https://jitsi.org