Re: [Sip] Outbound-10 comments
sergiole@tml.hut.fi Thu, 20 September 2007 22:26 UTC
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYUTx-0004ao-Am; Thu, 20 Sep 2007 18:26:49 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IYUTv-0004Rz-QK for sip-confirm+ok@megatron.ietf.org; Thu, 20 Sep 2007 18:26:47 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYUTv-0004Nx-5d for sip@ietf.org; Thu, 20 Sep 2007 18:26:47 -0400
Received: from smtp-1.hut.fi ([130.233.228.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IYUTl-0003zG-PZ for sip@ietf.org; Thu, 20 Sep 2007 18:26:44 -0400
Received: from localhost (katosiko.hut.fi [130.233.228.115]) by smtp-1.hut.fi (8.13.6/8.12.10) with ESMTP id l8KMQ45W004177; Fri, 21 Sep 2007 01:26:04 +0300
Received: from smtp-1.hut.fi ([130.233.228.91]) by localhost (katosiko.hut.fi [130.233.228.115]) (amavisd-new, port 10024) with LMTP id 07183-08-6; Fri, 21 Sep 2007 01:26:03 +0300 (EEST)
Received: from mail.tml.hut.fi (mail.tml.hut.fi [130.233.47.34]) by smtp-1.hut.fi (8.13.6/8.12.10) with ESMTP id l8KMOKrP003713; Fri, 21 Sep 2007 01:24:20 +0300
Received: from localhost (localhost.tml.hut.fi [127.0.0.1]) by mail.tml.hut.fi (Postfix) with ESMTP id BB2973A2CD9; Fri, 21 Sep 2007 01:24:19 +0300 (EEST)
Received: from mail.tml.hut.fi ([127.0.0.1]) by localhost (mail.tml.hut.fi [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03036-07; Fri, 21 Sep 2007 01:24:15 +0300 (EEST)
Received: from localhost (newhorde.tml.hut.fi [130.233.45.225]) by mail.tml.hut.fi (Postfix) with ESMTP id 76D5D3A2CD8; Fri, 21 Sep 2007 01:24:15 +0300 (EEST)
Received: from tltpc77.hut.fi (tltpc77.hut.fi [130.233.158.137]) by horde.tml.hut.fi (Horde MIME library) with HTTP; Fri, 21 Sep 2007 01:22:59 +0300
Message-ID: <20070921012259.39rpqki5cg84c4wg@horde-intra.tml.hut.fi>
Date: Fri, 21 Sep 2007 01:22:59 +0300
From: sergiole@tml.hut.fi
To: sip@ietf.org
Subject: Re: [Sip] Outbound-10 comments
References: <OFE1CA518D.694C1DC5-ON8525735C.0051D9FD-8525735C.0052F88C@mitel.com>
In-Reply-To: <OFE1CA518D.694C1DC5-ON8525735C.0051D9FD-8525735C.0052F88C@mitel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"; DelSp="Yes"; format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
User-Agent: Internet Messaging Program (IMP) H3 (4.1.3)
X-TML-Virus-Scanned: amavisd-new-2.3.2-tml at tml.hut.fi
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on katosiko.hut.fi
X-TKK-Virus-Scanned: by amavisd-new-2.1.2-hutcc at katosiko.hut.fi
X-Spam-Score: 1.8 (+)
X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1
Cc: fluffy@cisco.com, sip@ietf.org, peter_blatherwick@mitel.com, rohan@ekabal.com
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org
Hi, I composed the email below a month ago related to this thread and thought that I was missing something so I did not posted it, but it seems that there are some issues pending with the keepalive label and processing. Sorry to introduce more questions: -- My comments are about the keep-stun label. It is not very clear how the UA discovers that the Edge Proxy supports STUN. In section 8 (keepalive processing). I read " When a URI is created that refers to a SIP node that supports STUN as described in this section, the 'keep-stun' URI parameter, as defined in Section 12 MUST be added to the URI. This allows a UA to inspect the URI to decide if it should attempt to send STUN requests to this location. For example, an edge proxy could insert this parameter into its Path URI so that the registering UA can discover the edge proxy supports STUN keepalives." Q1. Why "an edge proxy COULD insert this parameter into its Path URI" and not MUST ? (considering that the UA supports STUN) Q2. In what other header can I also add the keep-stun, so that it will be still present when I get back a response? Note that in the example of section 9 the responses 200-OK haven't any keep-stun (Also mentioned in http://www1.ietf.org/mail-archive/web/sip/current/msg20295.html) Q3. For the case in this example, How will the Callee know that it is allowed to send STUN keepalives? (no keep-stun present) For the case in the example, and considering: "Typically, a SIP node first sends a SIP request and waits to receive a final response (other than a 408 response) over a flow to a new target destination, before sending any STUN messages." The callee will never send the keepalives... -- Part II In my opinion, the edge proxy MUST add a list of the supported mechanisms for keepalive in the 200-OK response to REGISTER. The list MUST include ALL the supported mechanisms (so the UA can for example know that if some mechanism is not available for the transport it used to register there are other mechanisms for other protocols. In this case the UA will form a new flow by registering using another protocol.) Example 1: UA sends REGISTER over UDP. It gets back a 200 OK with only keep-crlf. UA recognizes that STUN is not available, so a UDP flow can not succeed. Then it sends a REGISTER over TCP. Example 2: UA sends REGISTER over UDP. It gets back a 200 OK with keep-crlf and keep-stun. UA recognizes that keep-crlf is present so (its logic) can judge that TCP is a better choice. Then the UA forgets using UDP and switches to TCP: sends a REGISTER over TCP. Q: Should not be handy to have something like keep-Scrlf so the UA can knows that TLS is also supported? The same for DTLS. Sergio Quoting peter_blatherwick@mitel.com: > I agree with Jerry here, and believe this has come up before (?). It is > pointless for the originating UA to try to impose, or infer, the keepalive > mechanism before it can know what is applicable. > > An additional comment along these lines. >> a. UA sends REGISTER to the proxy with a "outbound" tag in the Supported > header. > ... >> c. If the "outbound" tag is present in the 200 OK, and if the transport > is UDP, using the STUN keep alive, other connection based transport using > crlf keep alive. > > Step a) would really imply the originating UA MUST support both keepalive > mechanisms, and c) implies it MUST begin using the appropriate one after > 200 OK. The usage is implied, not explicit, which I believe is sufficient > in this case. Alternatively, the usage could be made more explicit by > listing the supported k-a mechanisms in Supported exchange, or some such. > This should be spelled out either way. > > -- Peter Blatherwick > > > > > > > Jerry Yin <jerry.yin@yahoo.com> > 19.09.07 16:40 > > To: sip@ietf.org, fluffy@cisco.com, rohan@ekabal.com > cc: > Subject: [Sip] Outbound-10 comments > > > Hi Cullen and Rohan, > > In the draft, it requires the UA configure the next hop route header with > "keep-stun", "keep-crlf", or "timed-keepalive" tags. This would cause some > problems. > > 1. As an example, the route-set contains this route header as indicated in > section 9 example: > Route: <sip:pri.example.com;lr;keep-stun> > If the DNS NAPTR resolution for pri.example.com is TCP, SCTP or TLS, the > keep-stun will be useless. Vice versa, if the pri.example.com is resolved > as UDP, and if "keep-crlf" was manually configured, it is not working > either. > > 2. Before sending the REGISTER request, the admin/or user does not know > what keep-alive mechanism the proxy (or edge proxy) supports. Blindly > configure the keep-stun, or keep-crlf would cause the problem that the > draft indicated itself in section 8: "the node could be blacklisted for > UDP traffic". > The better approach is to let the UA and the proxy to negotiate, not > manually configure from UA side. > a. UA sends REGISTER to the proxy with a "outbound" tag in the Supported > header. > b. Proxy insert the "outbound" tag in the 200 OK, if the UA indicated that > it supports the outbound. > c. If the "outbound" tag is present in the 200 OK, and if the transport is > UDP, using the STUN keep alive, other connection based transport using > crlf keep alive. > There would be no way to mass up by configurations with this approach. Let > me know if I missed something. > > Regards, > Jerry Yin > > Yahoo! oneSearch: Finally, mobile search that gives answers, not web > links. _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip
- [Sip] WGLC for draft-ietf-sip-subnot-etags-01 DRAGE, Keith (Keith)
- Re: [Sip] WGLC for draft-ietf-sip-subnot-etags-01 Dale.Worley
- RE: [Sip] WGLC for draft-ietf-sip-subnot-etags-01 DRAGE, Keith (Keith)
- [Sip] Outbound-10 comments Jerry Yin
- RE: [Sip] WGLC for draft-ietf-sip-subnot-etags-01 DRAGE, Keith (Keith)
- Re: [Sip] Outbound-10 comments peter_blatherwick
- Re: [Sip] Outbound-10 comments sergiole
- RE: [Sip] WGLC for draft-ietf-sip-subnot-etags-01 DRAGE, Keith (Keith)
- RE: [Sip] WGLC for draft-ietf-sip-subnot-etags-01 Brian Rosen
- Re: [Sip] Outbound-10 comments Rohan Mahy
- Re: [Sip] Outbound-10 comments Rohan Mahy
- Re: [Sip] Outbound-10 comments peter_blatherwick
- Re: [Sip] WGLC for draft-ietf-sip-subnot-etags-01 Aki Niemi
- Re: [Sip] WGLC for draft-ietf-sip-subnot-etags-01 Dale.Worley
- Re: [Sip] WGLC for draft-ietf-sip-subnot-etags-01 Aki Niemi
- Re: [Sip] WGLC for draft-ietf-sip-subnot-etags-01 Dean Willis
- Re: [Sip] WGLC for draft-ietf-sip-subnot-etags-01 Aki Niemi
- Re: [Sip] WGLC for draft-ietf-sip-subnot-etags-01 Dale.Worley
- Re: [Sip] WGLC for draft-ietf-sip-subnot-etags-01 Dale.Worley
- Re: [Sip] WGLC for draft-ietf-sip-subnot-etags-01 Aki Niemi
- Re: [Sip] WGLC for draft-ietf-sip-subnot-etags-01 Dean Willis
- Re: [Sip] WGLC for draft-ietf-sip-subnot-etags-01 Dale.Worley
- Re: [Sip] WGLC for draft-ietf-sip-subnot-etags-01 Dale.Worley