Subject: [dispatch] My Drafts

From: Тверетин Антон Сергеевич <[email-masked]>
Date: Fri, 18 Mar 2016 00:04:26 +0500

Hello All,
Recently I've updated my I-Ds.
Note: I used my other e-mail in I-Ds. I read both.

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

draft-tveretin-dispatch-remote-02:
I believe that the I-D belongs to sipcore, as it defines new methods. Finally, I did some examples.

Regards,
Anton.

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 21 Mar 2016 10:55:27 -0400

<[email-masked]> writes:
> 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?

> methods. Finally, I did some examples.

Does this proposal enable any behaviors that are not already possible
(e.g., with RFC 3891, "Replaces")?

Dale