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

Hey Paul,

On 25.07.13, 22:04, Paul Kyzivat wrote:
> On 7/25/13 2:57 PM, Emil Ivov wrote:
>> Hey folks,
>>
>> On 25.07.13, 20:36, Christer Holmberg wrote:
>>> Hi Paul,
>>> Are you sure a new type is needed? The existing types are rather
>>> generic, aren't they?
>>
>> Back in Boston we decided to do something like this:
>>
>> 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.

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.

>> More below:
>>
>>> On 25.07.13, 19:09, Paul Kyzivat wrote:
>>>
>>> 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.
>>
>> Well, it just borrows the format from 5245 and says that this is how you
>> represent trickled candidates.
>
> 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.
> 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.

Yes agreed. This will have to be expanded in trickle-ice-sip.
>
>>> 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.
>>
>> Yup, should be application/sdpfrag.
>
> Well, AFAIK there is currently no such mime type. So its necessary to
> define it.

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).

> 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.

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

>>> 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.
>>
>> Will need to fix.
>>
>>> 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.
>>
>> Hmmm ... that's a good point!
>>
>>> 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.)
>>
>> Well, it doesn't have to be mandatory ...
>>
>> Emil
>>
>>>
>>>           Thanks,
>>>           Paul
>>> _______________________________________________
>>> mmusic mailing list
>>> mmusic@ietf.org
>>> https://www.ietf.org/mailman/listinfo/mmusic
>>
>
> .
>

-- 
https://jitsi.org