Subject: Re: [dispatch] My Drafts

From: Anton Tveretin <[email-masked]>
Date: Mon, 04 Apr 2016 16:17:21 +0500

Thanks for your reply. I will address issues in the next release, of course.
>    The last thing is currently not standartised. This document is to
>    fill the gap.
This thing refers to "maintain connectivity... through a tunnel". It seems that I was too vague. I think I should remove all references to other tunnelling protocols (except L2TP) from this draft.

Also, SDP spec was updated, and now payload types unambiguously form a distinct namespace from MIME types. I'm unsure that "media type" is the most appropriate term for a tunnel.

21.03.2016, 19:55, "Dale R. Worley" <[email-masked]>:
> <[email-masked]> writes:
>>  draft-tveretin-dispatch-l2tp-sdp-01:
>>  Changed proposed status to INFORMATIONAL, and separated normative and
>>  informative references.
>>  I believe that the I-D should get dispatch'ed to mmusic. Or launch a
>>  new WG or BOF to discuss tunnelling using SIP. Someone might argue
>>  that Session Initiation Protocol is not to initiate sessions. :)
>
> Of course, what you are proposing is an application/l2tp as a *media*
> type within a session. And so SIP can be used to set up an L2TP
> connection as part of its media.
>
> Section 1 contains:
>
>    Alice switches to data mode, uses text chat, sends
>    a file using Zmodem, and Bob receives it. Or Bob sends a file. Now
>    Alice starts a PPP [RFC1661] session. To maintain connectivity with
>    Bob, a tunnel (as of L2TP [RFC2661], PPTP [RFC2637], IPsec [RFC2401],
>    GPRS Tunneling Protocol) is needed.
>
>    The last thing is currently not standartised. This document is to
>    fill the gap.
>
> I'm not sure what "the last thing" is; it appears to be "GPRS Tunneling
> Protocol", which is currently not standardized. But since this document
> is about L2TP, the sentence "This document is to fill the gap" is
> incorrect.
>
> There needs to be some discussion of the effect of re-INVITE, subsequent
> offer/answer cycles. I would expect (not knowing anything about L2TP)
> that if the tunnel specified by the last offer/answer cycle was still
> up, the presence of the same m= line in the current offer/answer cycle
> means that the tunnel is to be continued. OTOH, it may require that the
> tunnel send some sort of end-to-end check to ensure that the tunnel is
> working, and a teardown/reopen cycle if it is not. (This needs to be
> based on best current practices in L2TP.)
>
> Is there any need to carry L2TP authentication information in SDP?
>
> Is there practical demand for establishing tunnels as part of the media?
>
>>  draft-tveretin-dispatch-remote-02:
>>  I believe that the I-D belongs to sipcore, as it defines new
>>  methods. Finally, I did some examples.
>
> Does this proposal enable any behaviors that are not already possible
> (e.g., with RFC 3891, "Replaces")?
>
> Dale