From nobody Mon Jul 4 06:54:27 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EFDF12D0C1 for ; Mon, 4 Jul 2016 06:54:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.024 X-Spam-Level: X-Spam-Status: No, score=-1.024 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, THIS_AD=1.675] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j_S6pvTcllcV for ; Mon, 4 Jul 2016 06:54:23 -0700 (PDT) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28D2912D0ED for ; Mon, 4 Jul 2016 06:54:23 -0700 (PDT) Received: by mail-vk0-x230.google.com with SMTP id c2so232224341vkg.1 for ; Mon, 04 Jul 2016 06:54:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nymfh6JaRxotoaLXfU6hpSxlBWYrDTtdhCe4c/vgkH0=; b=mZbf/M8/gmWvGX9DWDxZxj4nG9RWb8sft0H2H80fvDLLSXRYSyqisg3gNMERkqTtl3 WaGTBvPujRvNOElMo6zlqKuUjOiKLBzU/Veriem1IMNCVaGnfGKbRR0Tair9XDMZ1adH wOgAsw5TaPdDp3OAg/ZK7bNuUk4WmSG6I/KRUd4+68EEn3XjOfOCjH2yxMo7lc4r7VS2 4A3DCXwGwewVLw3QkRSvYRmfbgAS/72cMp/a9h8Ic/9rxrJCqbDpxDWlV9BX+U0wfI4o imHwgAtJWa9vMDG2ivAMami3iddiKlyBKxfbYZAqTigjLY1J1Ti91faOF+ZqkECmpst/ ZQww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nymfh6JaRxotoaLXfU6hpSxlBWYrDTtdhCe4c/vgkH0=; b=UZ0hZVnHbFyUJc6gVlmTTeDZZxRy7z0k/AHqr4FHka7a81+8WZOoAkJVon67RAdlJe 8FftF1uCvaighpqo+RnvNXX9cAX4rRt+kPiax9r1Z6uNUMSSlK2VWs4woPQ9sWXqiALo y7MKNzvK1DDo6X2bjSG5+ugWRCoNojIWdFFkxAqpTLM8bl5YoCKNse+MpJWgED1Bt9Ta 05ooZaNzUq5139sOIRLy9y/PH2O/lutuC6t0eMojXWOgZf3TTZDsxzxHQzSuOGRomkLq 2e/ny+WJNFSnt0kbxx8TwbOaV9Oc/jGRRi1Drf3Ep7SzpFKyIWdD+QuX2s7uccELBHE6 LE+w== X-Gm-Message-State: ALyK8tJf1bEQ/B5dlMuFkvj8gaiXfAsymJXrY2nBBISMS+2K+qV9XMkl+QtXlwAQbVHOLhzbw4G4EZKYvS4kvA== X-Received: by 10.31.165.198 with SMTP id o189mr5178912vke.9.1467640462179; Mon, 04 Jul 2016 06:54:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.2.142 with HTTP; Mon, 4 Jul 2016 06:54:20 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B37F97548@ESESSMB209.ericsson.se> From: Rifaat Shekh-Yusef Date: Mon, 4 Jul 2016 09:54:20 -0400 Message-ID: To: "Peterson, Jon" Content-Type: multipart/alternative; boundary=001a114161186801d80536cfac73 Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] SIP AuthNZ Problem Statement - v3 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2016 13:54:26 -0000 --001a114161186801d80536cfac73 Content-Type: text/plain; charset=UTF-8 On Thu, Jun 30, 2016 at 4:03 PM, Peterson, Jon wrote: > > > > >> But even if we assume a more open environment where the user agent can >> send INVITEs directly to the conference bridge, all the conference bridge >> needs is a signature or similar token that indicates the IdP's approval, >> -not- any specific attribute. >> > > Of course attributes are needed. > How would otherwise the conference server know which type of conference to > start (audio, video, etc)? what is the limitation on the number of > participant? etc... > > > This is exactly what my "deeper level of complexity" in a previous mail > pulled apart. You need to differentiate a) what kind of conference the user > wants from b) what kind of conference the IdP is willing to authorize. > Your token is just an indication of what the IdP is willing to authorize, > and if that is a superset of what the user wants, then the IdP will issue a > token. If it is a subset, then it won't. > > So how does the conference server know which type of conference to start? > Well, again, you've focused this discussion on the corner case of an ad hoc > RFC4579 conference, > I disagree that this is a corner case; you could replace that conference server with any other SIP service and the same mechanism would apply. > in the ad hoc case the conference bridge has to infer that from the type > of session that the user agent creates with the conference bridge with its > initial INVITE. > Not sure why you are saying "the conference bridge has to *infer* that"; the information would be explicitly provided in the token. > It's not really a very good assumption, though, which is why we quickly > run into trouble when we start trying to understand this corner case. > However, I think it would be safe to say that for this ad hoc case, if the > IdP was willing to issue an authorization token, then it authorizes the > media type(s) that the user specified in their INVITE - and thus that > attributes in the token to express what media types the IdP allowed would > be at best redundant. > > But to be clear, a token that conveys what the IdP is willing to authorize > does not serve the same purpose as a SIP means for a user agent to convey > to a conference bridge what kind of conference it would like to have - nor > as a means for a user agent to communicate to an IdP what kind of > conference it intends to propose. Paul is mentioning mechanisms like caller > prefs here because it would be new work, through some SIP mechanism along > those lines, to convey that information with SIP. > > Outside of this corner case, though, the conference URI is acquired in an > out-of-band fashion at the same time as conference policy is set - surely > through HTTP, surely through a web interface, and that's where all the > OAuth goodness can (and should) play into conference policy management. > Trying to inflate this one ad hoc corner case into a murky argument that > SIP needs OAuth is and has this whole time been a stretch. RFC4353 already > says conference policy management is not a SIP function. I'm not > particularly interested in working on overriding that, since it Is > obviously solved by just using HTTP, without any new work on our part. > > >> The semantics of the INVITE method are "hey, remote resource, I'd like to >> set up a session with you involving the following media types." The >> question of whether or not you accept INVITEs, which is to my mind the SIP >> authorization problem, >> > > This is the main difference between how you and I see this. > I think that the authorization problem is much bigger than just > authorizing a specific SIP method. The authorization should be dealing with *access > to services* provided by SIP servers regardless of the SIP method being > used. > > > Our real disconnect I think is the degree to which you think SIP offers > "services" or that application control is inside the scope of SIP. It's not. > Here are few RFCs that do just that; define services and control them: https://tools.ietf.org/html/rfc5359 https://tools.ietf.org/html/rfc3087 https://datatracker.ietf.org/doc/rfc7463/ > SIP is a protocol that allows Internet endpoints to discover one another > and to agree on the character of a session they'd like to share, according > to RFC3261. If I may quote from Section 2 of that document "SIP does not > offer conference control services" and indeed "SIP does not provide > services." > Here is the full quote: "SIP does not provide services. Rather, *SIP provides primitives that* * can be used to implement different services*. For example, *SIP can* * locate a user and deliver an opaque object to his current location*. If this primitive is used to deliver a session description written in SDP, for instance, the endpoints can agree on the parameters of a session. *If the same primitive is used to deliver a photo of the* * caller as well as the session description, a "caller ID" service can* * be easily implemented*. As this example shows, *a single primitive is* * typically used to provide several different services*." This means that SIP is not limited to negotiating session characteristics; it is much more than that and could be used to provide services. The last sentence in the above quote is really important. An INVITE could be used to start a conference, access a voice mail, put a call on hold, etc; these services require different authorizations. Regards, Rifaat > The only thing SIP has to do with conference services is that "SIP can be > used to initiate a session that uses some other conference control > protocol", look ahead to BFCP, and of course that SIP user agents can > initiate sessions with conference bridges. > > Much the same way that HTTP authorizes *access to resources*, regardless > of the HTTP method being used. You do not need a specific token for HTTP > GET vs HTTP POST, because the method does not matter; what matters is the > resource that the method is trying to access. > > > Accessing and changing resources on the Internet is in the scope of HTTP, > which is why HTTP should be used for the purposes you have in mind here. > Yes, in addition to initiating sessions, SIP has a number of methods that > let it convey data, such as INFO, MESSAGE, NOTIFY and so on, and in some > use cases, they can similarly provide access to resources. Maybe there's a > SIP authorization problem for those methods that we could find. But for the > most part, the SIP authorization problem should be aligned with the purpose > of SIP - it should be about deciding whether or not to accept session > initiation attempts. That's a problem I'd be willing to work on. > > Jon Peterson > Neustar, Inc. > > > Regards, > Rifaat > > --001a114161186801d80536cfac73 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Jun 30, 2016 at 4:03 PM, Peterson, Jon <jon.peterson@ne= ustar.biz> wrote:


=C2=A0
But even if we assume a more open environment where the user agent can= send INVITEs directly to the conference bridge, all the conference bridge = needs is a signature or similar token that indicates the IdP's approval= , -not- any specific attribute.

Of course attributes are needed.=C2=A0
How would otherwise the conference server know which type of conferenc= e to start (audio, video, etc)? what is the limitation on the number of par= ticipant? etc...

This is exactly what my "deeper level of complexity" = in a previous mail pulled apart. You need to differentiate a) what kind of = conference the user wants from b) what kind of conference the IdP is willin= g to authorize.=C2=A0 Your token is just an indication of what the IdP is willing to authorize, and if that is a superset of what= the user wants, then the IdP will issue a token. If it is a subset, then i= t won't.

So how does the conference server know which type of conference to sta= rt? Well, again, you've focused this discussion on the corner case of a= n ad hoc RFC4579 conference,

I = disagree that this is a corner case; you could replace that conference serv= er with any other SIP service and the same mechanism would apply.

=C2=A0
= in the ad hoc case the conference bridge has to infer that from the type of= session that the user agent creates with the conference bridge with its initial IN= VITE.

Not sure why you are say= ing "the conference bridge has to infer that"; = the information would be explicitly provided in the token.

=C2=A0
It's= not really a very good assumption, though, which is why we quickly run int= o trouble when we start trying to understand this corner case. However, I t= hink it would be safe to say that for this ad hoc case, if the IdP was willing to issue an autho= rization token, then it authorizes the media type(s) that the user specifie= d in their INVITE - =C2=A0and thus that attributes in the token to express = what media types the IdP allowed would be at best redundant.

But to be clear, a token that conveys what the IdP is willing to autho= rize does not serve the same purpose as a SIP means for a user agent to con= vey to a conference bridge what kind of conference it would like to have - = nor as a means for a user agent to communicate to an IdP what kind of conference it intends to propose. Pa= ul is mentioning mechanisms like caller prefs here because it would be new = work, through some SIP mechanism along those lines, to convey that informat= ion with SIP.

Outside of this corner case, though, the conference URI is acquired in= an out-of-band fashion at the same time as conference policy is set - sure= ly through HTTP, surely through a web interface, and that's where all t= he OAuth goodness can (and should) play into conference policy management. Trying to inflate this one ad hoc corne= r case into a murky argument that SIP needs OAuth is and has this whole tim= e been a stretch. RFC4353 already says conference policy management is not = a SIP function. I'm not particularly interested in working on overriding that, since it Is obviously solved by = just using HTTP, without any new work on our part.


The semantics of the INVITE method are "hey, remote resource, I&#= 39;d like to set up a session with you involving the following media types.= " The question of whether or not you accept INVITEs, which is to my mi= nd the SIP authorization problem,

This is the main difference between how you and I see this.
I think that the authorization problem is much bigger than just author= izing a specific SIP method. The authorization should be dealing with access to services provided by SIP servers regardless of the SIP met= hod being used.

Our real disconnect I think is the degree to which you think SI= P offers "services" or that application control is inside the sco= pe of SIP. It's not.

Here a= re few RFCs that do just that; define services and control them:










=C2=A0
The only thing SIP has to d= o with conference services is that "SIP can be used to initiate a session that uses some other conf= erence control protocol", look ahead to BFCP, and of course that SIP u= ser agents can initiate sessions with conference bridges.

Much the same way that HTTP authorizes access to resources, reg= ardless of the HTTP method being used. You do not need a specific token for= HTTP GET vs HTTP POST, because the method does not matter; what matters is= the resource that the method is trying to access.

Accessing and changing resources on the Internet is in the scop= e of HTTP, which is why HTTP should be used for the purposes you have in mi= nd here. Yes, in addition to initiating sessions, SIP has a number of metho= ds that let it convey data, such as INFO, MESSAGE, NOTIFY and so on, and in some use cases, they can similarly provi= de access to resources. Maybe there's a SIP authorization problem for t= hose methods that we could find. But for the most part, the SIP authorizati= on problem should be aligned with the purpose of SIP - it should be about deciding whether or not to accept sess= ion initiation attempts. That's a problem I'd be willing to work on= .

Jon Peterson
Neustar, Inc.


Regards,
=C2=A0Rifaat

--001a114161186801d80536cfac73-- From nobody Wed Jul 6 13:18:50 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 786FF12D623 for ; Wed, 6 Jul 2016 13:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Go6cKaBN-7C for ; Wed, 6 Jul 2016 13:18:47 -0700 (PDT) Received: from resqmta-ch2-10v.sys.comcast.net (resqmta-ch2-10v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDAB412D0CD for ; Wed, 6 Jul 2016 13:18:46 -0700 (PDT) Received: from resomta-ch2-14v.sys.comcast.net ([69.252.207.110]) by resqmta-ch2-10v.sys.comcast.net with SMTP id KtGRb1dI7EFCNKtHSbYdJA; Wed, 06 Jul 2016 20:18:46 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1467836326; bh=P97TTv12oUkuRb3nDvw/j2STxbHXsXNX1SkxPWlN1gE=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=Pkb0N7fPuyOzx//VeK8FR/1GRppqC01sFZbaXjUAmEmol3r06lFhTN6y6dWGM0+69 iJG3H4miYwmceKibywZGWeMc4r657lG9raW2bKAPqS5gJqsI3w8ItjZcJW8G8z5UG1 hXq3ukTqXrDOjds8B5nzQZhn8UmjrN6uTy0VBES+9LggXDBh2ml2CZCz5OpvVljwdB vqg/K38DwKsYWDX9jxohavhMITuvVezE+4Ca/AauwVoHvq+BfO8N/FHHcV39eTzldZ YpPzDqJpO9lj2ms1aS8W1f2R/aVSxpkiAwoEXkpQX5syPJspgyLsMIepTjXG32VkhC L2BqgN8UI9pxQ== Received: from hobgoblin.ariadne.com ([173.48.63.26]) by resomta-ch2-14v.sys.comcast.net with comcast id FYGQ1t00Q0Zyf7R01YGW0p; Wed, 06 Jul 2016 20:16:40 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u66KGNDc024618 for ; Wed, 6 Jul 2016 16:16:23 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u66KGNfI024615; Wed, 6 Jul 2016 16:16:23 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: sipcore@ietf.org Sender: worley@ariadne.com (Dale R. Worley) Date: Wed, 06 Jul 2016 16:16:23 -0400 Message-ID: <87h9c2a5ew.fsf@hobgoblin.ariadne.com> Archived-At: Subject: [sipcore] Dual-stack GRUU X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2016 20:18:48 -0000 How does dual-stack operation interact with GRUUs? An essential characteristic of a GRUU is that it's globally accessible. But if the device only implements one address family, or the intervening network carries only one protocol, then a URI isn't accessible to a device that only implements the *other* protocol. It seems that the theoretical answer is to require a GRUU to be accessible in practice from the global Internet via either address family, but it seems like that would de-GRUU-ize probably most of the GRUUs that are being used in the universe. Dale From nobody Wed Jul 6 13:53:58 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2400312D64F for ; Wed, 6 Jul 2016 13:53:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4pvVAdvlKvVg for ; Wed, 6 Jul 2016 13:53:55 -0700 (PDT) Received: from resqmta-po-01v.sys.comcast.net (resqmta-po-01v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:160]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C742812D63E for ; Wed, 6 Jul 2016 13:53:55 -0700 (PDT) Received: from resomta-po-08v.sys.comcast.net ([96.114.154.232]) by resqmta-po-01v.sys.comcast.net with SMTP id KtpPbSQgXkzylKtpSbQ8IX; Wed, 06 Jul 2016 20:53:54 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1467838434; bh=crQiv7tsshGysW1jrSwm4ZLhC1T/r0ePYWzSH+xuc34=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=SCtenD3H3JzLTY/sXPFOKRaMhsrH9J0A+ldNPMM3UJHZ1yvBHa8HdzT6llkndEViL iQcETrrltt6clY2gsunxrXau7ra4j/dpdlLggoXKcdl3CVRT0UL6aJQnxzKZNRiqVM 0SB5kW/WliZumKVnjctsHH8wWcjckncCTtm2UaIU3k9Qxi7R0hkaMlfFlZ5sGrdJ2W XQxvwpmHV9WJ4ZPjDtbVPtY7QQGA+6DnslXDs8NZi9K40UZebSq4Ba9L1aXBQJSZaW ljSbZdzBR6g0afTRi+BDi524j/bGHbapQaF+9FA+TGrEAgXNppWwM3Sqx4PZ8kYnku TFIvlBEEWNoJQ== Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by comcast with SMTP id KtpRbZJWGEmQKKtpSbgIVl; Wed, 06 Jul 2016 20:53:54 +0000 To: sipcore@ietf.org References: <87h9c2a5ew.fsf@hobgoblin.ariadne.com> From: Paul Kyzivat Message-ID: Date: Wed, 6 Jul 2016 16:53:52 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <87h9c2a5ew.fsf@hobgoblin.ariadne.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfPkvFE4H8jJy70WaFweYfkhTuBEGwLK8++Q+/en1guDTu3STplKRgxDkF63rIGIaU9aSBN5MWCuTbRLqMsdBSoWCUmAtQMMGOUe+qpDsUuj8h2MQ/YsV ZPofv3U7QQzMdvUskl8hgDSLbe72c94Ui1xYAHMxDBLsqNnvamjTakNeEN4jxeqPTvvb3lJJw/xjmg== Archived-At: Subject: Re: [sipcore] Dual-stack GRUU X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2016 20:53:57 -0000 On 7/6/16 4:16 PM, Dale R. Worley wrote: > How does dual-stack operation interact with GRUUs? > > An essential characteristic of a GRUU is that it's globally accessible. > But if the device only implements one address family, or the intervening > network carries only one protocol, then a URI isn't accessible to a > device that only implements the *other* protocol. > > It seems that the theoretical answer is to require a GRUU to be > accessible in practice from the global Internet via either address > family, but it seems like that would de-GRUU-ize probably most of the > GRUUs that are being used in the universe. IMO that is a step too far. ISTM that if the client using the GRUU can't handle the address family then it can deal with that itself. For instance it can find a TURN server to help. Thanks, Paul From nobody Wed Jul 6 14:00:35 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DDB312D63E for ; Wed, 6 Jul 2016 14:00:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iDlzZoy73CuH for ; Wed, 6 Jul 2016 14:00:32 -0700 (PDT) Received: from resqmta-ch2-07v.sys.comcast.net (resqmta-ch2-07v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C225D12D660 for ; Wed, 6 Jul 2016 14:00:32 -0700 (PDT) Received: from resomta-ch2-15v.sys.comcast.net ([69.252.207.111]) by resqmta-ch2-07v.sys.comcast.net with SMTP id KtvfbXvTMrtfLKtvsbf95D; Wed, 06 Jul 2016 21:00:32 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1467838832; bh=MO7WCVFdeid29O6L3dLTBHmVQSROZ88ZZq5XTqkBaA4=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=Zc7hb2MrjIQK2k5NqRaNwtB9iP+XhewJH2hyR2Jru8hrvBt0bh7VHOmzo8OHSTPSV zt2OZ3uiVpgOV3nbUrUHgfx37pvNYu8NQTf3flIiktnrmWZOBmSzlQ+s/HKMvEJ5+n PpaRbNkpy154zw/ugnja0tUVAchJH7+8Yr2i+6QyMLVhU4rZobyHdrb4P9Suk9+ALK IHgzMgIGPhMmjZ0XpPl2dCtD9NkIlTsTECuG8ulMgVJd/FC/e6ILXBze3ieD8UoMcs GGVP4V3Q60lK01jJYcfEA5rFcRqS3/leePGnS6dbzBackhMvO+dmc8zlebnJ9JUJXT PXDouH2bDoarA== Received: from hobgoblin.ariadne.com ([173.48.63.26]) by resomta-ch2-15v.sys.comcast.net with comcast id FYy61t00C0Zyf7R01YyBum; Wed, 06 Jul 2016 20:58:27 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u66Kw5qF029131; Wed, 6 Jul 2016 16:58:05 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u66Kw5sh029128; Wed, 6 Jul 2016 16:58:05 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Roman Shpount In-Reply-To: (roman@telurix.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Wed, 06 Jul 2016 16:58:05 -0400 Message-ID: <87eg76a3he.fsf@hobgoblin.ariadne.com> Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] Happy Eyeballs: Targets X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2016 21:00:34 -0000 Roman Shpount writes: > One more mechanism for checking a UDP flows is STUN keep-alive message > described in https://tools.ietf.org/html/rfc5626#section-3.5.2. These > messages are even lower overhead then OPTIONS messages. Thanks for mentioning that! I've added that to the rough draft. Dale From nobody Wed Jul 6 14:10:31 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D06F012D59A for ; Wed, 6 Jul 2016 14:10:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9s2cGHOrDvlk for ; Wed, 6 Jul 2016 14:10:28 -0700 (PDT) Received: from resqmta-ch2-01v.sys.comcast.net (resqmta-ch2-01v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB93812B04E for ; Wed, 6 Jul 2016 14:10:28 -0700 (PDT) Received: from resomta-ch2-01v.sys.comcast.net ([69.252.207.97]) by resqmta-ch2-01v.sys.comcast.net with SMTP id Ku4GbhLgL13YVKu5UbAVsY; Wed, 06 Jul 2016 21:10:28 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1467839428; bh=fmmLTHeKfWeEzR+QRfxm3V/DaPlpf4on7z4tERonrEw=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=MCbOrX4jBYFh2ss6znnw8Tc5M6SpQANc/l6Cp1H/etwy34u6bZoCue8Ah8ubB8rTo I9GzzjQl854kOBgQx5O6s8sHkpugbWE8mK3E3DnFhOfobEOcs11CeWp5iiJqoGyTX+ hCuxFc9MT+59zb94KEwmVFgDXgBsALYz7W8fcJNelepieOaP4EbPaqk3Q3oetXFOFJ bU2XB+Sz2Bx+Fe2YMjdn0tWH6El6JCmCxIcgRsyAxrCBc80yUAZW+okm3RIgALbD1h OYiWQFS8DNQSKELwpidqeVU9R/eDbe0WBHmhCvvpnsZDOQh3vc7IXb4Z6cBBvL7d5r gyjZgOyurEqUw== Received: from hobgoblin.ariadne.com ([173.48.63.26]) by comcast with SMTP id Ku37bLZob151PKu3DbDKB3; Wed, 06 Jul 2016 21:08:22 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u66L81gr030134; Wed, 6 Jul 2016 17:08:01 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u66L80A7030131; Wed, 6 Jul 2016 17:08:00 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Brett Tate In-Reply-To: <89c6b358b260d20a188e046840511c2c@mail.gmail.com> (brett@broadsoft.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Wed, 06 Jul 2016 17:08:00 -0400 Message-ID: <87bn2aa30v.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfHm+EM4Ep3tL30sktLn0F9u9pv77ZLVN1CxgDimqtksSzPxPuuYQLavasXj4+LCi7a/9p65AKm+q7fyWiOR705nBKWPOSdBy/nYrsV+fHhnodaywI0+H S011oZlyL/x8+ObGLqVFVZ4lfd682eFoYE2mk1amZqd7DnFyDhT32q6vsyLS9Jv4hJIFq5ssIf55S+gbfNXJnSqxcC/JbQbQO5s= Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] Happy Eyeballs: Targets X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2016 21:10:30 -0000 Brett Tate writes: > Although this draft can update it if needed, RFC 3261 section 17.1.1.2 > paragraph four was the text of potential concern since it looks like an > attempt to limit where T1 can be lowered. [...] Thanks for the discussion. I've added it to the rough draft. Dale From nobody Wed Jul 6 14:13:31 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A930712D1C2 for ; Wed, 6 Jul 2016 14:13:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Tw3nd_WpI4l for ; Wed, 6 Jul 2016 14:13:28 -0700 (PDT) Received: from resqmta-ch2-06v.sys.comcast.net (resqmta-ch2-06v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCD5C12D59A for ; Wed, 6 Jul 2016 14:13:28 -0700 (PDT) Received: from resomta-ch2-18v.sys.comcast.net ([69.252.207.114]) by resqmta-ch2-06v.sys.comcast.net with SMTP id Ku7NbKgM4E8zeKu8ObyCYD; Wed, 06 Jul 2016 21:13:28 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1467839608; bh=hUzDy/SYEeK1SD1HAxUKdbicqjeuXMyR/PoOo0BizEM=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=vMUy8rgdfzI9WhfAB6P/sX56qkgkmXxgUwG1E2G5iMGg87vQB+hhNiAziolzAE5WZ Vm8+uEhVWyNcmAY3ekaXAYltCNMT5yT6heMHem1LUMqR8dwvrQDOkau0ZjNSxcjcVw Dhj1uJqkkL50qeE8OrST73KOGeABbwj08t04hJ+3sDKDOT0L41EfwqGBMY0FSxSCnY mr+8qbvkxuZS1dyhYgBRxlcFSuZHro+l1JZmmnUIhCFd7qnLBgaHVV5hkuFF581PgR EPjU3G2Loxg3Gf3WqdNRcfZy6hU4Udq9+fHtjaLzDT1zcmrFg1SSjL5m5VRBM6jzve An0BDQMhiZijA== Received: from hobgoblin.ariadne.com ([173.48.63.26]) by resomta-ch2-18v.sys.comcast.net with comcast id FZAx1t00L0Zyf7R01ZB3pB; Wed, 06 Jul 2016 21:11:23 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u66LAvZM030464; Wed, 6 Jul 2016 17:10:57 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u66LAuoB030461; Wed, 6 Jul 2016 17:10:56 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Roman Shpount In-Reply-To: (roman@telurix.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Wed, 06 Jul 2016 17:10:56 -0400 Message-ID: <878txea2vz.fsf@hobgoblin.ariadne.com> Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] Happy Eyeballs: Targets X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2016 21:13:30 -0000 Roman Shpount writes: > This all depends what you mean by the "real systems". For USA hosted PBX > systems working with office based networks, RTT is 70ms [...] > Please let me know if you need any more data. That's great, especially since it covers a wide range of operational situations. I've added your discussion to the rough draft. Dale From nobody Wed Jul 6 14:56:42 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C1F812D0C3 for ; Wed, 6 Jul 2016 14:56:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e_sDxRLQBGNU for ; Wed, 6 Jul 2016 14:56:40 -0700 (PDT) Received: from resqmta-ch2-04v.sys.comcast.net (resqmta-ch2-04v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F08E112B05D for ; Wed, 6 Jul 2016 14:56:39 -0700 (PDT) Received: from resomta-ch2-08v.sys.comcast.net ([69.252.207.104]) by resqmta-ch2-04v.sys.comcast.net with SMTP id Kunmb9ZBG8RcDKuoBbubkO; Wed, 06 Jul 2016 21:56:39 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1467842199; bh=E/lRVdrx/a1GipwPUCeLZVAfxqLNaWhzKUPppcfiaIo=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=UNz7y9bTDPixzgHpDq/I2Fzk9SqCKMESh7dPFR3cwmupNclAqnyWt11PUG2U6lw0b OHZpj51SAbMi8oG9iq4RmqSgyydTf+L+0rWRXzrg2v8hJRmvSxY2e+r9QPzs2mRWUW svWI6S/9auCjQ1THAl54UOohtOI0d/tSW1NIZcx5Q0brPVWnsdmLqZR8OgO0aEPtUG 4zfFTPequOkzWsL3hT5YGd6eGk8mkOZXNVRaD0KIkGNzMqlDbR8NZ1cicQFpzQeBjZ ELoappPjtusD2N9ayzdJsqvu2MuXYTHEC2w+cAWlnLTiw2UFIKIlaysS9CpFBUpid5 VEy2uqkFkhuuQ== Received: from hobgoblin.ariadne.com ([173.48.63.26]) by comcast with SMTP id Kulpbb8Rbk7WGKulvbrbOP; Wed, 06 Jul 2016 21:54:34 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u66LsCNg002950; Wed, 6 Jul 2016 17:54:12 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u66LsCAO002947; Wed, 6 Jul 2016 17:54:12 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Roman Shpount In-Reply-To: (roman@telurix.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Wed, 06 Jul 2016 17:54:12 -0400 Message-ID: <8760sia0vv.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfED3SVjnaYYtvbJAACj8Oez0fyVMKylOjxj7D8mFbS9utN7bkEaLaPWdol4i2taJ1QJ2gS+LEGDYZkqp+mY9ytNhhHOSerqKxP8rXzTF/EcNXRpccoLA zHyxSYnyXSeBtMIGn9si8PSmj3+g6TB6o360E/yNqC2ncKfHil+XwKqMMVzagpGqf+5vxmNHJH+s/m5lgQyoIpIG4xidGVsNO6Q= Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] Happy Eyeballs: Outbounde X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2016 21:56:41 -0000 Thanks for the information! I've added your discussion to the rough draft. Roman Shpount writes: > Few observations: > [...] > 3. For server, the most efficient way to keep the NAT hole open is to send > OPTIONS or NOTIFY requests to the client. This is much more efficient then > registrations with small timeouts. > > 4. Registration server which has an in-memory database for current > registrations can be fairly efficient in reducing number of back-end DB > updates due to registrations and subscriptions with small timeouts. It is > not going to be stateless, but its state does not need to be replicated and > would automatically recover on the stand-by server on the next registration > or subscription request from the client. I think what you are saying here is that if the server sends OPTIONS/NOTIFY for keepalive, rather than making the client send frequent re-REGISTERS, then the server doesn't need to record the timers for the keepalives in persistent storage -- if the stand-by server is activated, it simply sends keepalives to all registrations that are recorded as having keepalive service. In the long run, this requires no more processing by the registration server and far less demand on the persistent storage. Is that correct? > 5. One of the big problems with encrypted SIP traffic is that it gets > modified by ALG. For a lot of hosted PBX providers avoiding the need to > troubleshoot customer routers is a bigger incentive to deploy TLS then user > privacy. If I understand you correctly, hosted PBX providers favor TLS to stop routers from modifying SIP messages. But ALGs terminate TLS ... and then modify the SIP messages. Dale From nobody Wed Jul 6 15:01:21 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CD3612B05D for ; Wed, 6 Jul 2016 15:01:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sonusnetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3f-stvRb8_YE for ; Wed, 6 Jul 2016 15:01:17 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0081.outbound.protection.outlook.com [104.47.42.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DBE3128E18 for ; Wed, 6 Jul 2016 15:01:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=uWbxn37v2XAquOpHZRsYMT3bqHwXrxGSFD3Wir/HSuc=; b=SnW5AXJyLmAacHw8cTuzUUULbzQeZ/boSIQadPIqgNxWRI2btCjyPItd+2HcJ0AUcvjGJex7uqjV72U1q9C5HnCwQui1pmv1XWYOoDv1q3gjNGV531FPqYbD5MGeWkUsz4VB7XUHw4u4aEa7dq90KtWuxp48xSpPAqBvvOnUMKI= Received: from SN1PR0301MB1551.namprd03.prod.outlook.com (10.162.129.157) by SN1PR0301MB1549.namprd03.prod.outlook.com (10.162.129.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.523.12; Wed, 6 Jul 2016 22:01:15 +0000 Received: from SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) by SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) with mapi id 15.01.0523.028; Wed, 6 Jul 2016 22:01:15 +0000 From: "Asveren, Tolga" To: "Dale R. Worley" , Roman Shpount Thread-Topic: [sipcore] Happy Eyeballs: Outbounde Thread-Index: AQHR19FL5tLu6d+XVkGJzyOXVUm57KAL88bQ Date: Wed, 6 Jul 2016 22:01:15 +0000 Message-ID: References: (roman@telurix.com) <8760sia0vv.fsf@hobgoblin.ariadne.com> In-Reply-To: <8760sia0vv.fsf@hobgoblin.ariadne.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tasveren@sonusnet.com; x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: 4dd7e8ec-58a8-4538-abaf-08d3a5e90d0a x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1549; 6:iqEZUm+6MeoyxsoxFY9djl/8IVj7bLFTZQRQ151TyBU4lfov4tiFbZXvHD/ZVZxQ+JaJ2L9eS6W1l5Zm8J2IR9xUQpiQgpBXiSWbkdYSuT8C6clsiNWOCe75NV8yKbIgRG4l5oM5hJYIfgHri4p76jq71CqLWuq2Gt2T9kfLuSwYaOsMaCKKIREZr+Bwug1gnpiALntr2fB8TmloaNVQOwZpn89ZyQO0On7TlfvF1An7ywm2otf8GHFyKx8KgWD1tzJlsQ0QTIwAmzMQw8jAs2kRzCVTPYBs3guVuASLDKU=; 5:Sn2cLTM+gkU3aVDsmN06ukmjo15MWzHvNdtQxPAXtztwGp+5vEIW53ilTZsFl0+kmXLXmpAUvk+Eb4IU4hGj/NIlwKoNBkii99wlp6KsObezdJJonZe1Teyn9n9jpKiQJg61PXj7hE/BurOX6oWAJQ==; 24:znAPj1bEN47EEjoimg6ru8C2LyDkImIdI0Tarxq+lGQYPlFDMjipgSo/A0p0fTTcgqm756mTSwD0/QDSRDiP/4+kxFU8goZOVFQRPeocK54=; 7:IErD3LTThdWI7VBp12asz0AzhVGkaRsKsTwcAWqOFnp909Rp+khsQACISlTpKa+o/xH79wrbUobT6epGu0lRmwpE4Bob1/KRBePAUapc1JNgPIkIJ+mdDAAdWMheoxlQ3dPQtOspUBKWyiL8hWIL+zqK5q1gBGpC823rAw5X5lfqMQZN5u3wDEEoDAS98w27URiOhr8FVFvt4/8q/uFUz7JOJMDPn4m/MtO6Br+4hF4mSadWTRs/ILFlDTasDTR8 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1549; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:SN1PR0301MB1549; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1549; x-forefront-prvs: 0995196AA2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(377454003)(13464003)(51914003)(199003)(189002)(9686002)(97736004)(81166006)(81156014)(76576001)(122556002)(87936001)(5001770100001)(92566002)(11100500001)(33656002)(189998001)(77096005)(5002640100001)(10400500002)(7736002)(7696003)(5003600100003)(66066001)(15975445007)(2950100001)(2900100001)(7846002)(106116001)(105586002)(3660700001)(99286002)(3280700002)(54356999)(50986999)(76176999)(86362001)(101416001)(4326007)(68736007)(2906002)(305945005)(586003)(74316002)(106356001)(102836003)(19580395003)(3846002)(8936002)(6116002)(19580405001)(8676002); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR0301MB1549; H:SN1PR0301MB1551.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: sonusnet.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jul 2016 22:01:15.2196 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1549 Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Happy Eyeballs: Outbounde X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2016 22:01:19 -0000 > then the server doesn't need to record the timers for the keepalives in > persistent storage I don't think using OPTIONS/NOTIFY v.s. REGISTER would change anything on t= his front. Roman probably refers more to the overall processing cost. Thanks, Tolga > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Dale R. Worl= ey > Sent: Wednesday, July 06, 2016 5:54 PM > To: Roman Shpount > Cc: sipcore@ietf.org > Subject: Re: [sipcore] Happy Eyeballs: Outbounde >=20 > Thanks for the information! I've added your discussion to the rough draf= t. >=20 > Roman Shpount writes: > > Few observations: > > [...] > > 3. For server, the most efficient way to keep the NAT hole open is to > > send OPTIONS or NOTIFY requests to the client. This is much more > > efficient then registrations with small timeouts. > > > > 4. Registration server which has an in-memory database for current > > registrations can be fairly efficient in reducing number of back-end > > DB updates due to registrations and subscriptions with small timeouts. > > It is not going to be stateless, but its state does not need to be > > replicated and would automatically recover on the stand-by server on > > the next registration or subscription request from the client. >=20 > I think what you are saying here is that if the server sends OPTIONS/NOTI= FY > for keepalive, rather than making the client send frequent re-REGISTERS, > then the server doesn't need to record the timers for the keepalives in > persistent storage -- if the stand-by server is activated, it simply send= s > keepalives to all registrations that are recorded as having keepalive ser= vice. > In the long run, this requires no more processing by the registration ser= ver > and far less demand on the persistent storage. >=20 > Is that correct? >=20 > > 5. One of the big problems with encrypted SIP traffic is that it gets > > modified by ALG. For a lot of hosted PBX providers avoiding the need > > to troubleshoot customer routers is a bigger incentive to deploy TLS > > then user privacy. >=20 > If I understand you correctly, hosted PBX providers favor TLS to stop rou= ters > from modifying SIP messages. But ALGs terminate TLS ... and then modify > the SIP messages. >=20 > Dale >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Wed Jul 6 15:17:49 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C342212D0E9 for ; Wed, 6 Jul 2016 15:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A5orqPpyNlbz for ; Wed, 6 Jul 2016 15:17:46 -0700 (PDT) Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 754DC12D0C3 for ; Wed, 6 Jul 2016 15:17:46 -0700 (PDT) Received: from resomta-ch2-07v.sys.comcast.net ([69.252.207.103]) by resqmta-ch2-08v.sys.comcast.net with SMTP id Kv7yb1lLclVqIKv8bbadxh; Wed, 06 Jul 2016 22:17:45 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1467843465; bh=9IZyQfzsbqI7+RujNc37A4rmh4BrHbfXt13wrmNTYRY=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=fnDeGrQ0e7jUJPhsfkxdwvVyOmRXaJR3HUbBrqXLb+B9FlS1IwSo2EF56HitF+dg0 0mvsQUAmtDHCYuJfymj7hYox+pC4oO27dTgHHLF8cc8uV9d1gHcXB7NPOnz05auS+X 1DMh3KjIn66N/BZm0TNDt1UTsYxkqDoAsDjKbXTquq/7t9VrgwiKg4HlUmTPydIBIw iehD3Sgx3i1W7/s7XuaXqO98QnobspDbVCmh7BsOJry8r65UpNoY158E9lsbh7gBIz AOOsgJNFeRywtQrHGnBrL+g2fliQpsjM9momrbuk88wUhxTCNOueZy+AV6iZXgS3qn lPP1zC8TaBEyg== Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by comcast with SMTP id Kv8bblZArbtHKKv8bbrhVF; Wed, 06 Jul 2016 22:17:45 +0000 To: sipcore@ietf.org References: <8760sia0vv.fsf@hobgoblin.ariadne.com> From: Paul Kyzivat Message-ID: <825113ce-da91-db4a-edf3-c7a4a0701bf6@alum.mit.edu> Date: Wed, 6 Jul 2016 18:17:44 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <8760sia0vv.fsf@hobgoblin.ariadne.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfK8g6Qe4mC/K42k1tjec9U8gZ1i/xREnUNL7OrKPU/pH06oPUOfmcryspIgpV6NlyRJygG1w5p7GNKxZImpORVc3XWm5AeH/tCKidgfuK5SB6vW5Wk9Z timuerR4AtFN39req12YmZcr1P4R28zgA8nWXIeuEcDUS5VByO9AMoeP5jU8ceUUejUSzyl7OuMbCg== Archived-At: Subject: Re: [sipcore] Happy Eyeballs: Outbounde X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2016 22:17:48 -0000 On 7/6/16 5:54 PM, Dale R. Worley wrote: > Thanks for the information! I've added your discussion to the rough > draft. > > Roman Shpount writes: >> Few observations: >> [...] >> 3. For server, the most efficient way to keep the NAT hole open is to send >> OPTIONS or NOTIFY requests to the client. This is much more efficient then >> registrations with small timeouts. Over TCP you can use . (And you don't need it very often.) Over UDP why don't we use STUN? In any case I see how this is a good substitute for frequent registration updates. The timing of both is determined by the server. This makes sense if the NAT is on the server end, and so its characteristics are known to the server. But if the the NAT is at the client end and the client knows what is need is, then it may not be so good. Are we assuming that clients are dumb and won't know this stuff anyway, so a guess by the server is the best you are going to get. Thanks, Paul >> 4. Registration server which has an in-memory database for current >> registrations can be fairly efficient in reducing number of back-end DB >> updates due to registrations and subscriptions with small timeouts. It is >> not going to be stateless, but its state does not need to be replicated and >> would automatically recover on the stand-by server on the next registration >> or subscription request from the client. > > I think what you are saying here is that if the server sends > OPTIONS/NOTIFY for keepalive, rather than making the client send > frequent re-REGISTERS, then the server doesn't need to record the timers > for the keepalives in persistent storage -- if the stand-by server is > activated, it simply sends keepalives to all registrations that are > recorded as having keepalive service. In the long run, this requires no > more processing by the registration server and far less demand on the > persistent storage. > > Is that correct? > >> 5. One of the big problems with encrypted SIP traffic is that it gets >> modified by ALG. For a lot of hosted PBX providers avoiding the need to >> troubleshoot customer routers is a bigger incentive to deploy TLS then user >> privacy. > > If I understand you correctly, hosted PBX providers favor TLS to stop > routers from modifying SIP messages. But ALGs terminate TLS ... and > then modify the SIP messages. > > Dale > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Wed Jul 6 15:46:22 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11FC812D0C3 for ; Wed, 6 Jul 2016 15:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sonusnetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4febgPwylqo2 for ; Wed, 6 Jul 2016 15:46:18 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0062.outbound.protection.outlook.com [104.47.42.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86656127078 for ; Wed, 6 Jul 2016 15:46:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=QJvrLLqfPEYFd+QfSe8ue9XO94aUc2Eh68/qwHsqPro=; b=DGEz+AML7W9AEm/bG/0lOCjEo2ZB/ylvM5/48l9Ra/bvIxJ4SVE9GGEtgCB5Am3kY0Z45NNs64u902sluyuOQC5LInaXZgA7h8JH2nOU/pF8ST0pFyveOpd9udhtNKLD+WfSIelzpeWfEMlbIiE0zJkdjF/CvLS03C8iYNyhoqg= Received: from SN1PR0301MB1551.namprd03.prod.outlook.com (10.162.129.157) by SN1PR0301MB1551.namprd03.prod.outlook.com (10.162.129.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.523.12; Wed, 6 Jul 2016 22:46:17 +0000 Received: from SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) by SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) with mapi id 15.01.0523.028; Wed, 6 Jul 2016 22:46:17 +0000 From: "Asveren, Tolga" To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] Happy Eyeballs: Outbounde Thread-Index: AQHR19FL5tLu6d+XVkGJzyOXVUm57KAL+M0AgAAHUVA= Date: Wed, 6 Jul 2016 22:46:17 +0000 Message-ID: References: <8760sia0vv.fsf@hobgoblin.ariadne.com> <825113ce-da91-db4a-edf3-c7a4a0701bf6@alum.mit.edu> In-Reply-To: <825113ce-da91-db4a-edf3-c7a4a0701bf6@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tasveren@sonusnet.com; x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: 27732c39-922a-4d5e-c42a-08d3a5ef577b x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1551; 6:Ciosi1LiaCshZmvgDVlZD6Tt87BitgoLZi4S3vhOgi9SXNYB4q8tiQ1X7y/0WWexjmpUKXh1VvERhwlNmU1CnMOVeAvimNtzkJdFLO6d9lxf1uxfqLifzo06GbLYuE3YiAXkpxedDqIbh0lpVb4p6g+BC5IHjFlgzn6lP+oXUpnWRGe8RQsOsRGS0zi5RsoRmufCYRE1rF3JUYuohfpecwA25wr2xr8glQfSJdlxPdkaRGj1fUSW5pieVwLoToKgkNjHYg88sNVqeGiJpcKoPfibFS29m2TFF4hlx4hxf2s=; 5:7heXKu5fss7jzLMsZa8BZDMsCYr4zNSXuv0W72fyfTnq86cVqmi3C9we9yhn/SqQwVVFuUhFf2vT+QyfLX1It/5Oxsni/oofnAoArWqjWdX7DzhaR6eDTXrI8dcxfHJneftKKapTFiSgAHjLdem4tw==; 24:meBiIHtsSG11PBsAu5YMoyY2V9eQx9MHC/uKeSvwj1N0z7lHl63yIAVHc41J3aJd0r5MbvTZ/OAAwU7N0HBpbqFuc2fOR2Nbzo/7qBmh4Bc=; 7:p/mVHZ4EbxLtIrRt3gkMt+MSmraeWVgbM5YDjiBRRSLTk2RhY7lztEi7PlbOkFCuZvvJGkwx15w5whqLdH1tsLOCFGGg6LLuffw96g+rd35KhyuJXgWoBdJqiLOz4D9AuswgG/fupj3brv3eXoo5o3nF6xlza0/y8D+xrAff/1/m7QzqEN47OBG3HSETPfHaD4NhJbTIvQnZBYMyQyMGqf+WxykZiZTDWL8K6SH+uzKFk3Dmx6pwGd/sFJ7NYazW x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1551; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:SN1PR0301MB1551; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1551; x-forefront-prvs: 0995196AA2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(377454003)(24454002)(51914003)(189002)(13464003)(199003)(52314003)(105586002)(11100500001)(86362001)(54356999)(76176999)(5002640100001)(106116001)(106356001)(2950100001)(19580405001)(5001770100001)(50986999)(2900100001)(101416001)(19580395003)(189998001)(10400500002)(7846002)(122556002)(2906002)(81166006)(99286002)(5003600100003)(7696003)(92566002)(305945005)(3280700002)(107886002)(7736002)(77096005)(81156014)(8936002)(76576001)(9686002)(97736004)(33656002)(66066001)(3846002)(102836003)(6116002)(586003)(2171001)(68736007)(3660700001)(74316002)(15975445007)(87936001)(8676002)(2501003); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR0301MB1551; H:SN1PR0301MB1551.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: sonusnet.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jul 2016 22:46:17.1546 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1551 Archived-At: Subject: Re: [sipcore] Happy Eyeballs: Outbounde X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2016 22:46:21 -0000 Inline... Thanks, Tolga > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Wednesday, July 06, 2016 6:18 PM > To: sipcore@ietf.org > Subject: Re: [sipcore] Happy Eyeballs: Outbounde >=20 > On 7/6/16 5:54 PM, Dale R. Worley wrote: > > Thanks for the information! I've added your discussion to the rough > > draft. > > > > Roman Shpount writes: > >> Few observations: > >> [...] > >> 3. For server, the most efficient way to keep the NAT hole open is to > >> send OPTIONS or NOTIFY requests to the client. This is much more > >> efficient then registrations with small timeouts. >=20 > Over TCP you can use . (And you don't need it very often.) >=20 > Over UDP why don't we use STUN? >=20 > In any case I see how this is a good substitute for frequent registration > updates. The timing of both is determined by the server. > This makes sense if the NAT is on the server end, and so its characterist= ics are > known to the server. >=20 > But if the the NAT is at the client end and the client knows what is need= is, > then it may not be so good. Are we assuming that clients are dumb and won= 't > know this stuff anyway, so a guess by the server is the best you are goin= g to > get. [TOLGA] In general, it is not common to rely on the client to determine the= refresh timing for NAT. It is either statically configured on the server s= ide or server performs some sort of "probing" to determine a close-to-optim= um refresh time. And agreed that CRLF/STUN-keepalive are the most preferred= approaches, just there are still lots of deployments with no UE support fo= r those though. >=20 > Thanks, > Paul >=20 > >> 4. Registration server which has an in-memory database for current > >> registrations can be fairly efficient in reducing number of back-end > >> DB updates due to registrations and subscriptions with small > >> timeouts. It is not going to be stateless, but its state does not > >> need to be replicated and would automatically recover on the stand-by > >> server on the next registration or subscription request from the clien= t. > > > > I think what you are saying here is that if the server sends > > OPTIONS/NOTIFY for keepalive, rather than making the client send > > frequent re-REGISTERS, then the server doesn't need to record the > > timers for the keepalives in persistent storage -- if the stand-by > > server is activated, it simply sends keepalives to all registrations > > that are recorded as having keepalive service. In the long run, this > > requires no more processing by the registration server and far less > > demand on the persistent storage. > > > > Is that correct? > > > >> 5. One of the big problems with encrypted SIP traffic is that it gets > >> modified by ALG. For a lot of hosted PBX providers avoiding the need > >> to troubleshoot customer routers is a bigger incentive to deploy TLS > >> then user privacy. > > > > If I understand you correctly, hosted PBX providers favor TLS to stop > > routers from modifying SIP messages. But ALGs terminate TLS ... and > > then modify the SIP messages. > > > > Dale > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Wed Jul 6 18:10:43 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D42012B032 for ; Wed, 6 Jul 2016 18:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dq6XVLhn9gml for ; Wed, 6 Jul 2016 18:10:38 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E00F812B054 for ; Wed, 6 Jul 2016 18:10:38 -0700 (PDT) Received: from pps.filterd (m0078666.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u6713jeb010391; Wed, 6 Jul 2016 21:10:38 -0400 Received: from stntexhc10.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 23x9qpfc93-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Wed, 06 Jul 2016 21:10:37 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.94]) by stntexhc10.cis.neustar.com ([169.254.4.225]) with mapi id 14.03.0279.002; Wed, 6 Jul 2016 21:10:36 -0400 From: "Peterson, Jon" To: Rifaat Shekh-Yusef Thread-Topic: [sipcore] SIP AuthNZ Problem Statement - v3 Thread-Index: AQHRqS0TDyFOI6cZKUWBz4pHTe07DJ+vbNaAgAFjyQCAA2UIgIACvqkAgANXvoCABITogIAH9hmAgAMlg4CAF/VngIAF7xoAgAGiQYD//8wQAIAB3CEA///zYgCAAYUpAIAIFXSAgAFN74CAAC7vAIABf0UAgAFhuICABilFgIADX4uAgAZXpQCAA2w+AA== Date: Thu, 7 Jul 2016 01:10:35 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B37F97548@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-originating-ip: [10.96.12.185] Content-Type: multipart/alternative; boundary="_000_D3A12BC51A4777jonpetersonneustarbiz_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-07-06_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1607070008 Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] SIP AuthNZ Problem Statement - v3 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 01:10:42 -0000 --_000_D3A12BC51A4777jonpetersonneustarbiz_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable So how does the conference server know which type of conference to start? W= ell, again, you've focused this discussion on the corner case of an ad hoc = RFC4579 conference, I disagree that this is a corner case; you could replace that conference se= rver with any other SIP service and the same mechanism would apply. We've probably delved excessively into this one use case - it perhaps would= have been more helpful to see examples of the attributes you propose for o= thers services. It is a "corner case" in so far as most of RFC4579 focuses on the "sunny da= y" case where there is a pre-existing conference URI (probably gotten via m= eans like an "IVR, web page") that you just dial into or add people to. Onl= y Section 5.4 deals with this "ad hoc" case. And of course RFC4579 is just = one way of managing conferences in a landscape full of methods that use pro= tocols other than SIP, albeit SIP will be used to actually initiate session= s to the conference. in the ad hoc case the conference bridge has to infer that from the type of= session that the user agent creates with the conference bridge with its in= itial INVITE. Not sure why you are saying "the conference bridge has to infer that"; the = information would be explicitly provided in the token. The main point of my last message was to try to tease apart a) what kind of= conference the user wants from b) what kind of conference the IdP is willi= ng to authorize. The fact that you're still just conflating them here sugg= ests we're making little progress in even communicating, let along persuadi= ng each other. Upleveling, if you think a token, rather than the SDP in the SIP INVITE, te= lls the conference bridge what kind of media the user agent is proposing fo= r its session, then the scope of the problem you're considering is even mor= e unwieldy than I thought. The potential difference between a) the media ty= pes the user (as a matter of personal conference policy) would allow any pa= rticipants to use in the conference vs. c) which media the user is proposin= g in the SDP of the INVITE for its own connection to the conference bridge,= is the further wrinkle I was attempting to untangle in the line you quote = above - many elements need to be teased apart to understand the ad hoc case= . Our real disconnect I think is the degree to which you think SIP offers "se= rvices" or that application control is inside the scope of SIP. It's not. Here are few RFCs that do just that; define services and control them: https://tools.ietf.org/html/rfc5359 https://tools.ietf.org/html/rfc3087 https://datatracker.ietf.org/doc/rfc7463/ These are pretty much landline replacement "services" for CLASS features an= d similar functions, so I'll talk more about them in a minute. But I'd be r= eal interested to hear what kinds of OAuth-style attributes need to be carr= ied in tokens in order to authorize those sorts of functions, and how the p= ost-1970s PSTN managed to live without them for decades. SIP is a protocol that allows Internet endpoints to discover one another an= d to agree on the character of a session they'd like to share, according to= RFC3261. If I may quote from Section 2 of that document "SIP does not off= er conference control services" and indeed "SIP does not provide services." Here is the full quote: "SIP does not provide services. Rather, SIP provides primitives that can be used to implement different services. For example, SIP can locate a user and deliver an opaque object to his current location. If this primitive is used to deliver a session description written in SDP, for instance, the endpoints can agree on the parameters of a session. If the same primitive is used to deliver a photo of the caller as well as the session description, a "caller ID" service can be easily implemented. As this example shows, a single primitive is typically used to provide several different services." This means that SIP is not limited to negotiating session characteristics; = it is much more than that and could be used to provide services. You passed over my RFC3261 quote that "SIP does not offer conference contro= l services" in silence while bolding lots of other 14 point text there. To talk about the paragraph you quote we need to open the more philosophica= l question of "what do we consider a service?" Clearly, if caller-ID is a s= ervice, or call waiting, or similar CLASS features, then in that sense of c= ourse SIP provides "services" via its primitives, and I've worked on defini= ng a few myself. But CLASS features as "services" are not of remotely the s= ame category as OAuth third-party services that consume tokens from IDPs - = you don't need any sort of third-party authorization attribute or token in = an INVITE to put someone on hold to take another call, say, or to send an i= mage between endpoints. Back in the days of IN, these kinds of features had= to be performed by "the network," and it was kind of a big deal that inste= ad in SIP you just implemented them in primitives under the control of user= agents, hence this text. But I think you are more concerned with controlli= ng third party applications than with features like call waiting, and confl= ating those two categories under the umbrella of "services" to make it soun= d like SIP encompasses and legitimizes what you want to do is not going to = persuade me, in any event. SIP does provide the primitives necessary to implement CLASS features, and = a number of RFCs today describe how to implement those features with SIP pr= imitives. And when you initiate a session with a voicemail bridge, say, we = could authorize your access to voicemail boxes in a number of different way= s. But if you wanted to implement a trait-based authorization system for au= thorizing access to voicemails held on a third-party server, realistically,= would (or should) you do it with SIP? Because there are a lot of HTTP and = IMAP based visual voicemail services out there that support advanced featur= es like speech-to-text transcription and so on where OAuth-like primitives = make a lot of sense. Just because you can call a voicemail service with a S= IP INVITE, that doesn't means that a SIP INVITE is the right place to stage= an OAuth "service" like that, nor its security. I feel exactly the same wa= y about conference policy. The last sentence in the above quote is really important. An INVITE could b= e used to start a conference, access a voice mail, put a call on hold, etc;= these services require different authorizations. An INVITE can be used to initiate a session with a conference bridge, becau= se semantics of an INVITE are "hey, I would like to initiate a session with= you with the following media parameters." Setting conference policy requir= es a different semantics than that, and as I've repeatedly said in this thr= ead (and as far as I can tell, you have not contradicted), the relevant RFC= s recommend that you don't set conference policy with SIP. I'm really don't= understand why that does not deter you. I think at this point, if you want to propose your way of setting conferenc= e policy with SIP as a problem space, feel free - I don't happen to think t= here's much of a gap there, given the existence of means other than RFC4579= ad hoc INVITEs to set up conferences when you have more complicated securi= ty needs than an ad hoc conference ordinarily would. If the group agrees th= at there is 1) a need to convey conference policy in SIP, and 2) a need for= attribute-based authorization tokens issued by IdPs to support that confer= ence policy, that could be scoped as its own problem space and put forward = for dispatch. But I don't think this is a general authorization problem for= SIP. Jon Peterson Neustar, Inc. --_000_D3A12BC51A4777jonpetersonneustarbiz_ Content-Type: text/html; charset="us-ascii" Content-ID: <6CEC0B2BD1FBBE4E908F4DEF89C6BAEE@neustar.biz> Content-Transfer-Encoding: quoted-printable


So how does the conference server know which type of conference to sta= rt? Well, again, you've focused this discussion on the corner case of an ad= hoc RFC4579 conference,

I disagree that this is a corner case; you could replace that conferen= ce server with any other SIP service and the same mechanism would apply.

We've probably delved excessively into this one use case - it perhaps = would have been more helpful to see examples of the attributes you propose = for others services.

It is a "corner case" in so far as most of RFC4579 focuses o= n the "sunny day" case where there is a pre-existing conference U= RI (probably gotten via means like an "IVR, web page") that you j= ust dial into or add people to. Only Section 5.4 deals with this "ad hoc" case. And of course RFC4579 is just one way of managing= conferences in a landscape full of methods that use protocols other than S= IP, albeit SIP will be used to actually initiate sessions to the conference= .


in the ad hoc case the conference bridge has to infer that from the ty= pe of session that the user agent creates with the conference bridge with i= ts initial INVITE.

Not sure why you are saying "the conference bridge has to infer that"; the information would be explicitly provide= d in the token.

The main point of my last message was to try to tease apart a) what ki= nd of conference the user wants from b) what kind of conference the IdP is = willing to authorize.  The fact that you're still just conflating them= here suggests we're making little progress in even communicating, let along persuading each other.  

Upleveling, if you think a token, rather than the SDP in the SIP INVIT= E, tells the conference bridge what kind of media the user agent is proposi= ng for its session, then the scope of the problem you're considering is eve= n more unwieldy than I thought. The potential difference between a) the media types the user (as a matter = of personal conference policy) would allow any participants to use in the c= onference vs. c) which media the user is proposing in the SDP of the INVITE= for its own connection to the conference bridge, is the further wrinkle I was attempting to untangle in the line yo= u quote above - many elements need to be teased apart to understand the ad = hoc case.


These are pretty much landline replacement "services" for CL= ASS features and similar functions, so I'll talk more about them in a minut= e. But I'd be real interested to hear what kinds of OAuth-style attributes = need to be carried in tokens in order to authorize those sorts of functions, and how the post-1970s PSTN managed to live with= out them for decades.


SIP is a protocol that allows Internet endpoints to discover one anoth= er and to agree on the character of a session they'd like to share, accordi= ng to RFC3261. If I may quote from Section 2  of that document "S= IP does not offer conference control services" and indeed "SIP does not provide services."  

Here is the full quote:

  "SIP does not provide s= ervices.  Rather, SIP provides primitives that
   ca= n be used to implement different services.  For example, SIP can
   locate a user and d= eliver an opaque object to his current location.
   If this primitive is u= sed to deliver a session description written in
   SDP, for instance, the= endpoints can agree on the parameters of a
   session.  If t= he same primitive is used to deliver a photo of the
   caller as well as t= he session description, a "caller ID" service can
   be easily implement= ed.  As this example shows, a single primitive is
   ty= pically used to provide several different services."=


This means that SIP is not limited to negotiating session characterist= ics; it is much more than that and could be used to provide services.

You passed over my RFC3261 quote that "SIP does not offer confere= nce control services" in silence while bolding lots of other 14 point = text there.

To talk about the paragraph you quote we need to open the more philoso= phical question of "what do we consider a service?" Clearly, if c= aller-ID is a service, or call waiting, or similar CLASS features, then in = that sense of course SIP provides "services" via its primitives, and I've worked on defining a few myself. But CLASS fe= atures as "services" are not of remotely the same category as OAu= th third-party services that consume tokens from IDPs - you don't need any = sort of third-party authorization attribute or token in an INVITE to put someone on hold to take another call, say, or= to send an image between endpoints. Back in the days of IN, these kinds of= features had to be performed by "the network," and it was kind o= f a big deal that instead in SIP you just implemented them in primitives under the control of user agents, hence thi= s text. But I think you are more concerned with controlling third party app= lications than with features like call waiting, and conflating those two ca= tegories under the umbrella of "services" to make it sound like SIP encompasses and legitimizes what you want to do = is not going to persuade me, in any event.

SIP does provide the primitives necessary to implement CLASS features,= and a number of RFCs today describe how to implement those features with S= IP primitives. And when you initiate a session with a voicemail bridge, say= , we could authorize your access to voicemail boxes in a number of different ways. But if you wanted to imp= lement a trait-based authorization system for authorizing access to voicema= ils held on a third-party server, realistically, would (or should) you do i= t with SIP? Because there are a lot of HTTP and IMAP based visual voicemail services out there that suppor= t advanced features like speech-to-text transcription and so on where OAuth= -like primitives make a lot of sense. Just because you can call a voicemail= service with a SIP INVITE, that doesn't means that a SIP INVITE is the right place to stage an OAuth "= ;service" like that, nor its security. I feel exactly the same way abo= ut conference policy. 


The last sentence in the above quote is really important. An INVITE co= uld be used to start a conference, access a voice mail, put a call on hold,= etc; these services require different authorizations.

An INVITE can be used to initiate a session with a conference bridge, = because semantics of an INVITE are "hey, I would like to initiate a se= ssion with you with the following media parameters." Setting conferenc= e policy requires a different semantics than that, and as I've repeatedly said in this thread (and as far as I can tell= , you have not contradicted), the relevant RFCs recommend that you don't se= t conference policy with SIP. I'm really don't understand why that does not= deter you.

I think at this point, if you want to propose your way of setting conf= erence policy with SIP as a problem space, feel free - I don't happen to th= ink there's much of a gap there, given the existence of means other than RF= C4579 ad hoc INVITEs to set up conferences when you have more complicated security needs than an ad hoc conference or= dinarily would. If the group agrees that there is 1) a need to convey confe= rence policy in SIP, and 2) a need for attribute-based authorization tokens= issued by IdPs to support that conference policy, that could be scoped as its own problem space and put f= orward for dispatch. But I don't think this is a general authorization prob= lem for SIP.

Jon Peterson
Neustar, Inc.
--_000_D3A12BC51A4777jonpetersonneustarbiz_-- From nobody Wed Jul 6 18:27:12 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A94212D7AA for ; Wed, 6 Jul 2016 18:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2F9AoWEjwLJJ for ; Wed, 6 Jul 2016 18:27:08 -0700 (PDT) Received: from resqmta-ch2-01v.sys.comcast.net (resqmta-ch2-01v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE29512D121 for ; Wed, 6 Jul 2016 18:27:03 -0700 (PDT) Received: from resomta-ch2-10v.sys.comcast.net ([69.252.207.106]) by resqmta-ch2-01v.sys.comcast.net with SMTP id Ky59bhe2r13YVKy5nbBAEu; Thu, 07 Jul 2016 01:27:03 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1467854823; bh=ExzCzHwF9cYMewUX1yHwy8BRZTxZPn+/5Z7m+Ktqiwg=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=KJ0AlaWBnSfO3WliIAk4uB7Psl33AD5dkqdUp9yiIyIu/K+zAvri4pfdprcyzOpMk VrtHzNDDSMQpceX9sBdJSVpDg0Hu/iG5Z+nPQqcYzDleECSrfP1Zg+YNpWL02Ge5S6 dcrYD7uh/ZWYf5oDYV9YqWoz0wgULC0Wj8VTb7hzeU7SOEPvJRk5OA4J0gCQ7N4SOD C2fyhjkg4oa5pM3rNGZXBgzOveQzR6Qn3Aa9irU66CPFyRhHCYwt4T6SaQ/tfGnK8R RSkpHr1t/ke8LQRjHOsL6b2KzIzE0frKLapQasjMLpo0ITzXvYwj/z/Zg4dDl+Sw4J E+TcLBcIqssyw== Received: from hobgoblin.ariadne.com ([73.143.237.82]) by comcast with SMTP id Ky5mba43xoagXKy5mbtK4P; Thu, 07 Jul 2016 01:27:03 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u671R15a020029 for ; Wed, 6 Jul 2016 21:27:01 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u671R1QG020026; Wed, 6 Jul 2016 21:27:01 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: sipcore@ietf.org Sender: worley@ariadne.com (Dale R. Worley) Date: Wed, 06 Jul 2016 21:27:01 -0400 Message-ID: <87wpky8cgq.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfO3aTnwyvgfITg9txpWEUXBO7OFGbjEptIpWH4RSKq00uhFpoVkPRbDwBwQmeo7EAZU/jIhxx8+wpfpVXbhFMZa23rV26xm/hSNWlit8zSQAdRaTT7fa T+yi+OAe80Cq2/o0mgJGu3z1dxa51aL+SX/iZuZhQevMpM5z9n2iYr3Zot3bXSka9yk/ZJGCcqPZQA== Archived-At: Subject: [sipcore] Very rough draft for remaining Happy Eyeballs work X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 01:27:11 -0000 I've submitted a very rough draft for the remaining Happy Eyeballs work: https://datatracker.ietf.org/doc/draft-worley-sipcore-dual-stack/ At this point, it is an attempt to record the state of the design discussions for a number of topics which are part of -- or related to -- Happy Eyeballs for SIP. Dale From nobody Thu Jul 7 00:50:27 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C299E12D500 for ; Thu, 7 Jul 2016 00:50:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d2EwpPXZWQR4 for ; Thu, 7 Jul 2016 00:50:24 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A33B412D5A3 for ; Thu, 7 Jul 2016 00:50:22 -0700 (PDT) Received: from [192.168.40.20] (h87-96-134-129.cust.se.alltele.net [87.96.134.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id C8D804281; Thu, 7 Jul 2016 09:50:18 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Olle E. Johansson" In-Reply-To: Date: Thu, 7 Jul 2016 09:50:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <87h9c2a5ew.fsf@hobgoblin.ariadne.com> To: Paul Kyzivat X-Mailer: Apple Mail (2.3124) Archived-At: Cc: sipcore@ietf.org, Olle E Johansson Subject: Re: [sipcore] Dual-stack GRUU X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 07:50:27 -0000 > On 06 Jul 2016, at 22:53, Paul Kyzivat wrote: >=20 > On 7/6/16 4:16 PM, Dale R. Worley wrote: >> How does dual-stack operation interact with GRUUs? >>=20 >> An essential characteristic of a GRUU is that it's globally = accessible. >> But if the device only implements one address family, or the = intervening >> network carries only one protocol, then a URI isn't accessible to a >> device that only implements the *other* protocol. >>=20 >> It seems that the theoretical answer is to require a GRUU to be >> accessible in practice from the global Internet via either address >> family, but it seems like that would de-GRUU-ize probably most of the >> GRUUs that are being used in the universe. >=20 > IMO that is a step too far. >=20 > ISTM that if the client using the GRUU can't handle the address family = then it can deal with that itself. For instance it can find a TURN = server to help. Gruu is a good thing (TM) in dual stack environments, but I would not go = as far as to require it to be dual stack. I wonder if there are scenarious = where the AOR is dual stack, but not the GRUU. That=E2=80=99s the only case I can = think of where a GRUU could lead to the problems you describe. The domain in the = GRUU maps the AOR and resolves to the same hosts with the same address families and have the same reachability. If you can reach the AOR you should be able to always reach the GRUU - or am I missing something? A gruu puts the burden of finding the proper flow to the other side on the proxy and ICE solves the media. A dual stack domain-responsible SIP server enables reachability from any address family, even if the UA doesn=E2=80=99t support all of them. = Beautiful migration path. :-) I would conclude with the fact that GRUU makes the contact URI address = family independent. In most cases this is not that important since we have record routed = proxys or simply b2bua=E2=80=99s in the path=E2=80=A6=20 That takes me to the issue of the record-route. In order to have a gruu- like effect (address family independence) the address in the = record-route should be a domain or host name - not an ip address of either family. This also makes TLS better. Sorry for the rambling, just brainstorming /O= From nobody Thu Jul 7 01:14:12 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C240312D618 for ; Thu, 7 Jul 2016 01:14:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9dGqRjQMAWyR for ; Thu, 7 Jul 2016 01:14:02 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A428112D62F for ; Thu, 7 Jul 2016 01:14:01 -0700 (PDT) Received: from [192.168.40.20] (h87-96-134-129.cust.se.alltele.net [87.96.134.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id 91F9E4281; Thu, 7 Jul 2016 10:13:58 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Olle E. Johansson" In-Reply-To: <87wpky8cgq.fsf@hobgoblin.ariadne.com> Date: Thu, 7 Jul 2016 10:13:57 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <87wpky8cgq.fsf@hobgoblin.ariadne.com> To: "Dale R. Worley" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: sipcore@ietf.org, Olle E Johansson Subject: Re: [sipcore] Very rough draft for remaining Happy Eyeballs work X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 08:14:09 -0000 > On 07 Jul 2016, at 03:27, Dale R. Worley wrote: >=20 > I've submitted a very rough draft for the remaining Happy Eyeballs = work: > https://datatracker.ietf.org/doc/draft-worley-sipcore-dual-stack/ >=20 > At this point, it is an attempt to record the state of the design > discussions for a number of topics which are part of -- or related to = -- > Happy Eyeballs for SIP. Comments: Abstract: - I think we are targeting both 3263 and 3261. 3263 describes how to set = up a list of server addresses to reach, while my impression is that 3261 describes more of the connection set = up and connection handling. For server2server connections we touch RFC 5923 too. I would rephrase into =E2=80=9CRFC 3263 describes how to locate a list of addresses to contact = for a given SIP URI and other document desribes how to set up and maintain a working IP flow over the SIP transports. These = procedures doesn=E2=80=99t handle situations where both the SIP Ua that acts as a client and the server are connected to = multiple IP address families. As seen in other protocols this can lead to long delays in flow setup time, which leads to a bad = user experience. In SIP it is especially critical to have a short time used from call attempt to first signal - the busy or ring = tone. This document describes how to implement =E2=80=98Happy Eyeballs=E2=80=99-like IP flow setups in the current set = of transports used by the SIP protocol as well as additional client procedures which improve the SIP user experience in many = circumstances=E2=80=9D To requirements I would add: - Solutions must be documented both for UA=E2=80=99s using SIP Outbound = extensions, GRUU extensions and those that does not support these extensions. The details about a probe and the note about OPTIONS doesn=E2=80=99t = really belong in the terminology section. I wonder if the PROBE also should be used for registration states, not just dialog = states. We should also document that the probe is ONLY used for non-connection-oriented protocols (read UDP). In the solution I think we have to add a flow state somehow. For any = given IP address/port target found by the DNS lookup there=E2=80=99s a state - you have it between the lines -=20 - A. Working flow established and used - B. Working flow established and discarded (other flow preferred) - C. Not attempted to open flow - D. Flow failed, propation mode=20 Seems like state B and D will need a timeout timer (as you point out). = Yay for new timers! ;-) I don=E2=80=99t understand why you let devices break the order implied = by RFC 3263. The order is well defined there. Do you mean that for a given HOST you may contact the targets in = any order (or preferred: simultaneously). Did you quote Roman right in 3.2? "One of the big problems with = encrypted SIP traffic is that it gets modified by ALG. =E2=80=9C Seems to me that he wanted to say the opposite - non-encrypted SIP = traffic is modified by ALGs. /O From nobody Thu Jul 7 09:05:33 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5188212D803 for ; Thu, 7 Jul 2016 09:05:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZYfQBxNyEytF for ; Thu, 7 Jul 2016 09:05:31 -0700 (PDT) Received: from resqmta-ch2-10v.sys.comcast.net (resqmta-ch2-10v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7277712D7CC for ; Thu, 7 Jul 2016 09:05:30 -0700 (PDT) Received: from resomta-ch2-11v.sys.comcast.net ([69.252.207.107]) by resqmta-ch2-10v.sys.comcast.net with SMTP id LBi5b2nGXEFCNLBntbb1ol; Thu, 07 Jul 2016 16:05:29 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1467907529; bh=xbYw0JN0VnaasUUvCr+zStHOV90hHZtBO2MfZTIooT0=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=ZQuwtIncQtIIEpTH3Q63NZcviNp93qwB/NVn+YETrQWoVk6yGxKhtHO2dBn9d1UEd Y2HFH0sZdsC0WC2rl1bTOC81F7QJdre4AVxmZO6+oj7UUBUhi26Bh0PPmbofsGZgbk OdOWymvTm7wifj2Q7dkd7mHUU/ymZrbnZHK3zV9Kb07SuoamNofiZpPRTCSGVQOhuW Rurm7rXwTeGQcV4u3dIo/3MCSK0+U4/hMmf68MRrIwG25cEbzJ3Dpw/A9pjaqtdE1X JPf8tkSXgwTZHFAI6NZ48Tb7/+EQuMekUtYX+HGEtALKC+T0Qn6NtbtasQTmA0aFD8 i8lNSuTeAKoMg== Received: from hobgoblin.ariadne.com ([73.143.237.82]) by comcast with SMTP id LBnrbR4WPZHuALBnsbtVFz; Thu, 07 Jul 2016 16:05:29 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u67G5RIT012931; Thu, 7 Jul 2016 12:05:27 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u67G5QPi012927; Thu, 7 Jul 2016 12:05:26 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: sipcore@ietf.org, oej@edvina.net In-Reply-To: (oej@edvina.net) Sender: worley@ariadne.com (Dale R. Worley) Date: Thu, 07 Jul 2016 12:05:26 -0400 Message-ID: <87h9c177sp.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfOH+oHQskT/WXY6t3dwgOel+a0XjjXzSx/vUOIRvoftHNa54RtMNszCLjNaPllrpyuE899kfGKMIVORdZF/nkoJe1NgHfenxxjuiLvo39FtC2pIbcKRL bC9rlt8fCopKJLsJS9XaLd8qRn4SrhXF0xgu+XTu0H7LFMxnG8kR+Oq4T7kbq1FLPB9u5K5NgPJ68+EJ/TxoM3WUvMfE0jpeNaw= Archived-At: Subject: Re: [sipcore] Dual-stack GRUU X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 16:05:32 -0000 "Olle E. Johansson" writes: > I wonder if there are scenarious where the AOR is dual stack, but not > the GRUU. That's the only case I can think of where a GRUU could lead > to the problems you describe. The domain in the GRUU maps the AOR and > resolves to the same hosts with the same address families and have the > same reachability. If you can reach the AOR you should be able to > always reach the GRUU - or am I missing something? Ah, yes, that's what gets us out of the problem -- the GRUU has the same hostpart as the AOR (presumably), so if you can contact the AOR to set up the call, you can contact the GRUU to manipulate it. That analysis covers all three cases: an IPv4-only system, an IPv6-only system, and a fully dual-stack system. > That takes me to the issue of the record-route. In order to have a > gruu- like effect (address family independence) the address in the > record-route should be a domain or host name - not an ip address of > either family. This also makes TLS better. Record-Route URIs are a complicated case. In many situations, the proxy that adds the Record-Route is directly aware of the capabilities of the next-hop proxy, and may choose the Record-Route URI specifically to be reachable from the next-hop proxy. E.g., in one situation I was designing, the proxy would double-record-route so that it could talk IPv4 to the proxy on one side and IPv6 to the proxy on the other side. In these situations, it could use an IPv4 address for one URI and an IPv6 address for the other URI. But yes, if the proxy wants the R-R URI to be family-independent (or to be resolvable both outside and inside the corporate private network), it has to have a suitable hostname to hand. Oh, yeah, one significant case is where the proxy is dialog-stateless and has a redundant partner. Then it wants to R-R with a URI that resolves to either itself or its partner. Dale From nobody Thu Jul 7 14:42:46 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B989D12D67F for ; Thu, 7 Jul 2016 14:42:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 653z5btUQKpF for ; Thu, 7 Jul 2016 14:42:44 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A09512D5CD for ; Thu, 7 Jul 2016 14:42:44 -0700 (PDT) Received: from unnumerable.local ([173.57.161.14]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u67LghTv046303 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK) for ; Thu, 7 Jul 2016 16:42:43 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [173.57.161.14] claimed to be unnumerable.local From: Robert Sparks To: "sipcore@ietf.org" Message-ID: <2a037768-fe35-dd54-23a3-6b89c818594c@nostrum.com> Date: Thu, 7 Jul 2016 16:42:43 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [sipcore] Registration for SIPIt 32 is open X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 21:42:46 -0000 The SIP Forum's SIPit 32 will be held at the University of New Hampshire Interoperability Laboratory September 12-16, 2016. In addition to the usual thorough testing, we expect this event to focus on new evolutions in SIP Security such as the mechanisms defined in the STIR working group. We also hope to inform the new SIPBRANDY effort in the IETF. More information about the SIPit is available at https://www.sipit.net. Registration is open at https://www.regonline.com/sipit32 RjS From nobody Fri Jul 8 05:21:51 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E88D112B012 for ; Fri, 8 Jul 2016 05:21:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=broadsoft-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MtMYOCzT6LLG for ; Fri, 8 Jul 2016 05:21:47 -0700 (PDT) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8670612D08D for ; Fri, 8 Jul 2016 05:21:46 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id c34so21398225qte.0 for ; Fri, 08 Jul 2016 05:21:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadsoft-com.20150623.gappssmtp.com; s=20150623; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:content-transfer-encoding; bh=+ZveaQXzJTjTbu7QJ1Se/sa8uY89m0TbHHGcX4FvRfo=; b=JGvTRvxuuRWpcwFCZshLrfc3F5UQ3hHbcfKq6PiCTsCDlTw3fwvUZTWiaUVUktkODO xI324xLHHJXwSiB8A29HtVlbd5DWunPqbf9sb0MQ/D0Za/datD+XMJM7vT1yKUSOfOtF u7cS64mA5oz3YxckQ1u/8LNh7aKhyN/s2wDckWglQVRNUwgVOm1nuVQKYDj1SlvZf9mG HAaVfc6+i5H3cRtelPB4EKJ8kvyB6+ylTdbN2lJPmYcED+bVD9xuvW7YY1ZG/DNWl4vf dUBgYzfLkh8bv6XnU8uujytWuD8a3Mk7t6HwvNpjwtB/cPaIv/TozbVbgaVVo39ukzMZ AjiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:content-transfer-encoding; bh=+ZveaQXzJTjTbu7QJ1Se/sa8uY89m0TbHHGcX4FvRfo=; b=ff4WbVdYpODx4be6ko3GGx4vJI5+RpdzlevDovevkyRt3Gc2qXcdQwyDNqlyxBdSch I5+bcNHIQb+PHXgi+enUxv7zkGE0BrJ6/c3HHZ/Ql/c8zpuhHKXwrZ56JOkeD7vxLmWh Fhmkg+LJL5N5lWRXlFuWAPrCBWfXHYLG+kbBWlmRCcpxLAEk2aAp9JWmu7lACgX6M2Wg 5wJ9WTpTzXd5ZJoyfV0rrAr9jhC4ECW6V2Vp6dvJdQtFvJS4yofYKumPyLbfnWMcnhAc OVbQDNyE62TYSAGTs/zlnqWGcE2GbNsAr5SGJm+a05beqKhoF6figkdJTj3smFFjdTpt QtkQ== X-Gm-Message-State: ALyK8tKBP2Zgmn3BjJro7WbpiWnCpkUpVyX82LhcSXgv7ojCY5IrBZISNf9gom55fU7qtREFNpD224+T+ogP3PFN X-Received: by 10.200.42.200 with SMTP id c8mr8515216qta.8.1467980505586; Fri, 08 Jul 2016 05:21:45 -0700 (PDT) From: Brett Tate References: <87wpky8cgq.fsf@hobgoblin.ariadne.com> In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMnCJ8srXW5B7ryqcj7u7jTOG8R/AMQeCFOnUuNVpA= Date: Fri, 8 Jul 2016 08:21:44 -0400 Message-ID: <9c832373309e812327d83cb0f17821ad@mail.gmail.com> To: "Olle E. Johansson" , sipcore@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [sipcore] Very rough draft for remaining Happy Eyeballs work X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 12:21:50 -0000 > I don=E2=80=99t understand why you let devices break the order > implied by RFC 3263. The order is well defined there. > Do you mean that for a given HOST you may contact the > targets in any order (or preferred: simultaneously). I'm not sure what is meant by the current text. However, RFC 3261 does allow the application of a local policy. Similarly, some vendors might fin= d it more appropriate to move previously non responsive locations to the end of the list instead of just skipping them. From nobody Fri Jul 8 05:55:53 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5D4012D5DE for ; Fri, 8 Jul 2016 05:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=broadsoft-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HEZegvu8xBnT for ; Fri, 8 Jul 2016 05:55:49 -0700 (PDT) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3620912D671 for ; Fri, 8 Jul 2016 05:55:46 -0700 (PDT) Received: by mail-qt0-x229.google.com with SMTP id m2so21630865qtd.1 for ; Fri, 08 Jul 2016 05:55:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadsoft-com.20150623.gappssmtp.com; s=20150623; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to; bh=fibWjE/UlMCa+vKdTjeeEp9e7sm82WkRU8aL3T9LbmU=; b=DHYl9UvgAS5aHfU6J3heNR6muQwEqMAAPKOmbgxcRaC/O4TfC8I9Ivbq23NB+zt4Ic uMS4cFdoAmyKRwBmgEN5lue849V1ReZXJXyKWudb/b2+pn0/VVSkQ8bUBu8Kihj2poQq MbUhoPWv7MonwwRsRvRBwE855nBMPF8dHd/guWvmdX6EqOanqSmmmo0EqSt4vS9deh6q QriS1ViXTy9rwrvDxV9MdketG1JmUfvQjjLM9qLsQUpnknz0VTaE/FlBKpReYtlMHPlP Qe60XHjEf6sEWH7OsYG7Vz6C40i/Qw59fpwC1T1EARFsIj3D8Dvl9jZvt/8QCrGDB1R2 0TGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to; bh=fibWjE/UlMCa+vKdTjeeEp9e7sm82WkRU8aL3T9LbmU=; b=Z2JNexM7igy/vtOE90y8k/qdRfqj+1FikMapoboupP5hfzYGZXJCFb/FzrG0QPeggJ 7qI9unz8GysqFLsFvVzG1WyELLB8Xb9jj9cxRsqshyr3EvnIrIDMaRp/YxLvx9OoIcHY 0mbB/nWg8NwpuIZA03uXauM9Ps+0RRsSEEaJizkRQ0cWfqYSMSDVh9iaPAlZL7E0NfaX DVeJKFY8In5BPPEerQ6jBPwBnQfWnDVKMJj7IpwHfrrsRvDfSzB0LO9s0YNG+G0uDMEG acy/tl77SAM755WjJj2cb5flcIkic2iRbcrO8lfI7UxSuDXWz4vaOo3YA6yMhWF2gOu4 0cWA== X-Gm-Message-State: ALyK8tISJxZjHsewiEwlUOJMSdGU9ZG3/oArCVULSApHhmYlE60Kp+bIt4nqiP+EwTOLsKCP0vrf1uaSTRNbxs67 X-Received: by 10.200.52.72 with SMTP id v8mr8339110qtb.21.1467982545266; Fri, 08 Jul 2016 05:55:45 -0700 (PDT) From: Brett Tate References: (roman@telurix.com) <8760sia0vv.fsf@hobgoblin.ariadne.com> In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQExhCXARuMNJJ29RAOMX4WZUxsYDQLdrjeAAYkm5behK+mW0A== Date: Fri, 8 Jul 2016 08:55:43 -0400 Message-ID: <22b6b93d15568d356c511ff18cf81e3a@mail.gmail.com> To: "Asveren, Tolga" , sipcore@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [sipcore] Happy Eyeballs: Outbounde X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 12:55:52 -0000 > > then the server doesn't need to record the timers > > for the keepalives in persistent storage > > I don't think using OPTIONS/NOTIFY v.s. REGISTER > would change anything on this front. Roman probably > refers more to the overall processing cost. Because refreshing a registration typically involves updating persistent information, performing authentication, et cetera, the impacts a REGISTER can be significantly higher than that of OPTIONS. This is the reason why some vendors prefer receiving OPTIONS instead of REGISTER when sent frequently as a workaround for NAT involvement. Since OPTIONS is frequently used as a ping instead of the original purpose, sipcore might want to standardize a mechanism to distinguish between the two usages. I don't recall why prior attempts such as draft-jones-sip-options-ping failed. From nobody Fri Jul 8 06:42:59 2016 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3327F12D16B; Fri, 8 Jul 2016 06:42:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.25.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160708134253.32139.86767.idtracker@ietfa.amsl.com> Date: Fri, 08 Jul 2016 06:42:53 -0700 Archived-At: Cc: sipcore@ietf.org Subject: [sipcore] I-D Action: draft-ietf-sipcore-dns-dual-stack-07.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 13:42:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core of the IETF. Title : Locating Session Initiation Protocol (SIP) Servers in a Dual-Stack IP Network Authors : Olle E. Johansson Gonzalo Salgueiro Vijay Gurbani Dale R. Worley Filename : draft-ietf-sipcore-dns-dual-stack-07.txt Pages : 11 Date : 2016-07-08 Abstract: RFC 3263 defines how a Session Initiation Protocol (SIP) implementation, given a SIP Uniform Resource Identifier (URI), should locate the next-hop SIP server using Domain Name System (DNS) procedures. As SIP networks increasingly transition from IPv4-only to dual-stack, a quality user experience must be ensured for dual- stack SIP implementations. This document updates the DNS procedures described in RFC 3263 for dual-stack SIP implementations in preparation for forthcoming specifications for applying Happy Eyeballs principles to SIP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-dns-dual-stack/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sipcore-dns-dual-stack-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-dns-dual-stack-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 8 09:14:31 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E8DD12D685 for ; Fri, 8 Jul 2016 09:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DGryz2JY4Why for ; Fri, 8 Jul 2016 09:14:25 -0700 (PDT) Received: from resqmta-ch2-11v.sys.comcast.net (resqmta-ch2-11v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE5CB12D0D3 for ; Fri, 8 Jul 2016 09:14:15 -0700 (PDT) Received: from resomta-ch2-17v.sys.comcast.net ([69.252.207.113]) by resqmta-ch2-11v.sys.comcast.net with SMTP id LYPdbUkmJTKbsLYPvbbXiO; Fri, 08 Jul 2016 16:14:15 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1467994455; bh=D135halWsaPH4/oryAz4qT/5VkH3uoTlUWJjmZbAInc=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=aQH4fhcNNufWw2sogHWCoD5QlIrxt6skAKoRjBoLlLJqStbb9Zr5aIBBUJMlsOF6Q IBLSbDsbR79IZHPh/J8ngIJQi0zbpdRsyudH7C8l86soB0W4+q4yzNp+K2YPOlcrwt ja9YMVkOqU5M4xOlPbiEtZ/yGHF1MENgEu5a+fFCvsvsTASt7Xw1kmV7GTwD/Q2pk1 oGyZfmP0DdsUvXdNJWX1cBk3la+wSlDfIqw5X+ZU/T4bX81zCjD+NAsLBFbCH28NOs eLuQnTV7FCKVI1OD4ecfd6X+9cA3Y5hg4aZK0ihArk8hygTLXT7jqG4CRuZkt+sUVE 1oDVZPcNqoXLg== Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by comcast with SMTP id LYPubsxnrVjbBLYPubifmJ; Fri, 08 Jul 2016 16:14:15 +0000 To: sipcore@ietf.org References: <8760sia0vv.fsf@hobgoblin.ariadne.com> <22b6b93d15568d356c511ff18cf81e3a@mail.gmail.com> From: Paul Kyzivat Message-ID: <6ffed47b-e7ab-88db-0026-7c9a6e1aa52f@alum.mit.edu> Date: Fri, 8 Jul 2016 12:14:13 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <22b6b93d15568d356c511ff18cf81e3a@mail.gmail.com> Content-Type: multipart/mixed; boundary="------------B005E6949D16541E27699E88" X-CMAE-Envelope: MS4wfKLWijIRUSWtN+qE+IiJ2GDTVq1YCDKTJw6QRPvv0FdbyJ6NGM/FCyzvqT4I4oqSx2p4lPtWUZg3KYAIZjv4OELqx2Ax+HiivJQ/mevOdvw0n6JOv3TW KM1WjudkjgHtX4viKIy1nO7IY0U+unE9j7nLpF/0NXV8NdjP3fFHbHOjz4E47CwLSW0qwIbI4PgVcA== Archived-At: Subject: Re: [sipcore] Happy Eyeballs: Outbounde X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 16:14:29 -0000 This is a multi-part message in MIME format. --------------B005E6949D16541E27699E88 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 7/8/16 8:55 AM, Brett Tate wrote: > Since OPTIONS is frequently used as a ping instead of the original > purpose, sipcore might want to standardize a mechanism to distinguish > between the two usages. I don't recall why prior attempts such as > draft-jones-sip-options-ping failed. I just looked back at my private archive. The discussions took place in May and July of 2010 on the sipcore list. (I haven't looked for these in the archives. These days I can get a URL into the archives from my copy of a message, but not with ones from that far back.) I have attached a couple of messages as hooks into those discussions Basically we could never agree on the groundrules for when using OPTIONS in the way proposed made sense. Thanks, Paul --------------B005E6949D16541E27699E88 Content-Type: message/rfc822; name="Attached Message" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Attached Message" X-Account-Key: account2 X-Mozilla-Keys: Received: from xbh-rcd-101.cisco.com ([72.163.62.138]) by xmb-rcd-203.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 1 Jul 2010 11:23:30 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 1 Jul 2010 11:23:30 -0500 Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.53,520,1272844800"; d="scan'208";a="127784481" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 01 Jul 2010 16:23:30 +0000 Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o61GNTd6022203; Thu, 1 Jul 2010 16:23:29 GMT Message-ID: <4C2CC102.6040405@cisco.com> Date: Thu, 01 Jul 2010 12:23:30 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Victor Pascual Subject: Re: [sipcore] Revised draft-jones-sip-options-ping-02.txt References: <037201cb18d9$05dab420$11901c60$@packetizer.com> <4C2CA93D.5050806@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-Path: pkyzivat@cisco.com X-OriginalArrivalTime: 01 Jul 2010 16:23:30.0522 (UTC) FILETIME=[BE35D3A0:01CB1939] Victor Pascual wrote: > Would sip-ops be a better place for this? I don't know - I don't follow that list. If you think so, feel free to propose that publicly. Thanks, Paul > https://www.ietf.org/mailman/listinfo/sip-ops > > Sent from my iPad > > On Jul 1, 2010, at 4:42 PM, Paul Kyzivat wrote: > >> [as co-chair] >> >> Paul J, >> >> What are your intentions/expectations with respect to this draft? >> >> While it is written using normative language, I find nothing in it that is enhanced by being normative. So I would imagine if this is to go anywhere, it would be as a Informational document. >> >> At the moment I don't envision this rising to the level of becoming a milestone for this group. >> >> I have no problem with using this list for a modest amount of discussion about this draft - especially about its eventual outcome. >> >> Thanks, >> Paul >> >> Paul E. Jones wrote: >>> Folks, >>> I just wanted to bring to your attention the fact that we've submitted a new >>> revised version of the OPTIONS "ping" draft. This document contains input >>> from a number of folks who provided comments to me on various aspects of the >>> draft. >>> We had some discussion of moving this work to the SIP Overload Control (SOC) >>> WG. Given my current understanding of the scope of the SOC WG, I do not >>> think that OPTIONS falls within the scope of their charter. Further, this >>> document was never produced for the purpose of providing an overload >>> mechanism, either. >>> I would like to have some further dialog on this document. I've received >>> some positive feedback from several people, as this has been seen as a >>> useful first step in trying to define use of OPTIONS as a "ping" mechanism >>> that is interoperable. As I had mentioned before, there are several >>> different variants of the same procedure in production networks and I think >>> it's useful that we reach some agreement on how OPTIONS should be used as an >>> application-level "ping", as RFC 3261 is a bit light on detail in this area. >>> I know I might not have captured every comment, but that's because the >>> discussions went in a variety of directions last time. :-) So, my edits >>> were primarily editorial or to add clarity to what was already written. >>> Comments are most certainly welcome. >>> Paul >>>> -----Original Message----- >>>> From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] >>>> On Behalf Of Internet-Drafts@ietf.org >>>> Sent: Thursday, July 01, 2010 12:30 AM >>>> To: i-d-announce@ietf.org >>>> Subject: I-D Action:draft-jones-sip-options-ping-02.txt >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. >>>> >>>> Title : Using OPTIONS to Query for Operational Status in >>>> the Session Initiation Protocol (SIP) >>>> Author(s) : V. Bhargava, et al. >>>> Filename : draft-jones-sip-options-ping-02.txt >>>> Pages : 8 >>>> Date : 2010-06-30 >>>> >>>> This document describes a procedure for using the Session Initiation >>>> Protocol (SIP) OPTIONS method in order to allow one SIP entity to query >>>> the operational status of another SIP entity. Through discovery of the >>>> status of a SIP entity, it is possible to expedite session establishment >>>> or provide diagnostic information to network administrators. >>>> >>>> A URL for this Internet-Draft is: >>>> http://www.ietf.org/internet-drafts/draft-jones-sip-options-ping-02.txt >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> Below is the data which will enable a MIME compliant mail reader >>>> implementation to automatically retrieve the ASCII version of the >>>> Internet-Draft. >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore > --------------B005E6949D16541E27699E88 Content-Type: message/rfc822; name="Attached Message" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Attached Message" X-Account-Key: account2 X-Mozilla-Keys: Received: from xbh-rcd-202.cisco.com ([72.163.62.201]) by xmb-rcd-203.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 May 2010 19:39:56 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 May 2010 19:39:56 -0500 Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-6.cisco.com with ESMTP; 12 May 2010 00:39:47 +0000 Received: from sj-inbound-b.cisco.com (sj-inbound-b.cisco.com [128.107.234.205]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o4C0dkSq023391; Wed, 12 May 2010 00:39:47 GMT X-from-outside-Cisco: 64.170.98.32 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao0BAEeV6UtAqmIgjmdsb2JhbACeKxcCCQsgBx2hGplGgnaCGwQ X-IronPort-AV: E=Sophos;i="4.53,211,1272844800"; d="scan'208";a="160065474" Received: from mail.ietf.org ([64.170.98.32]) by sj-inbound-b.cisco.com with ESMTP; 12 May 2010 00:39:47 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4341828B23E; Tue, 11 May 2010 17:39:57 -0700 (PDT) X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BA603A6C1C for ; Tue, 11 May 2010 17:39:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.258 X-Spam-Level: X-Spam-Status: No, score=-10.258 tagged_above=-999 required=5 tests=[AWL=0.341, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vnQmSXEqit1Q for ; Tue, 11 May 2010 17:39:54 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 8FA0E3A693A for ; Tue, 11 May 2010 17:39:53 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAEeV6UtAZnwN/2dsb2JhbACeK3GhGplGgnaCGwQ X-IronPort-AV: E=Sophos;i="4.53,211,1272844800"; d="scan'208";a="110212279" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 12 May 2010 00:39:42 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o4C0dgS1016627; Wed, 12 May 2010 00:39:42 GMT Message-ID: <4BE9F8CE.2050207@cisco.com> Date: Tue, 11 May 2010 20:39:42 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Hadriel Kaplan References: <01c501caec0e$48e624e0$dab26ea0$@com> <430FC6BDED356B4C8498F634416644A91A8A7D7192@mail> <430FC6BDED356B4C8498F634416644A91A8A7D71A2@mail> <4BE2BCB0.10909@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D760B@mail> <4BE44683.9040405@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D7771@mail> <4BE81570.5080803@cisco.com> <00d901caf076$bdd21770$39764650$@com> <4BE86339.6020709@cisco.com> <010501caf087$53ff6c60$fbfe4520$@com> <4BE889BD.2030901@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D7AB9@mail> <4BE95E6E.3000601@cisco.com> <430FC6BDED356B4C8498F634416644A91C139909C2@mail> <4BE998FE.5040703@cisco.com> <430FC6BDED356B4C8498F634416644A91C13990ABF@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91C13990ABF@mail> Cc: "Paul E. Jones" , "sipcore@ietf.org" Subject: Re: [sipcore] The predictive value of OPTIONS X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sipcore-bounces@ietf.org Errors-To: sipcore-bounces@ietf.org Return-Path: sipcore-bounces@ietf.org X-OriginalArrivalTime: 12 May 2010 00:39:56.0335 (UTC) FILETIME=[A4DEF3F0:01CAF16B] This is fragmenting into multiple issues that ought to be discussed separately. But I want to go home so I'm not splitting it up. inline... Hadriel Kaplan wrote: > >> -----Original Message----- >> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf >> Of Paul Kyzivat >> Sent: Tuesday, May 11, 2010 1:51 PM >> >>> For me it is. >>> I do also have a need to actually learn what the next-hop's >>> supported extensions are (and I do mean "box-level" ones), >>> but that's not the main driver use-case for me at this instant in time. >> Well, I would put that into somewhat the same bucket: >> You are looking to predict which options will be supported for requests >> you might send in the future. >> >> You seem to be making an assumption that extension support is uniquely >> defined at the "box-level". I don't think its proper to assume that in >> general, for a variety of reasons. For instance, a B2BUA may choose not >> to admit to support for an extension in the context of a dialog unless >> the "other leg" supports that extension. >> This goes double for other "attributes" that may be reported by OPTIONS, >> such as: event packages, mime types, media formats, even methods. > > Yup, I know that quite well, and have made that argument before in IETF. :) > > When I said "box-level", I meant capabilities *of* the B2BUA, at least with respect to me. Not of any other "side", but of "my side". In practice, there is a set of capabilities that could be indicated, and are. Some of them would be quite useful, and really only apply on a per-hop basis anyway. It's not everything, which makes it dangerous (and why I'm not suggesting doing it right now), but that's for a later time. > > >> (For the latter, what is a B2BUA supposed to do if it understands some >> method, but the other "side" doesn't?) > > If it accepts the method on my "side", it accepts the method. If the other side doesn't, then it will reject it when I send it. Those two cases are not mutually inconsistent. The B2BUA can make a routing decision which of many "sides" to send the request to, but it really does accept it and I really should send it to find out - as opposed to when it does not accept it on my side and there's no point ever sending it such a method. Lets use MESSAGE for discussion. You would report MESSAGE in an Accept header. Then later you receive MESSAGE, forward it to the "other side", and get back a 405, including a list of methods that are supported, not including MESSAGE. Do you pass that Accept on? Or alter it to indicate that you *do* support MESSAGE even though you are rejecting it with a 405? There is no way to win here. You must be inconsistent at some point. So the result of the OPTIONS wrt Accept cannot be trusted to predict future behavior. The same is true for most of the other things reported in OPTIONS - its really hard to say much about how relevant they are for predicting future behavior. To do better, I think it is necessary to either: - specify in the query the context of the question, or - return a complex document that describes what is supported under a variety of circumstances. I doubt we want the latter (at least I don't). Specifying the context for which you want an answer is also pretty difficult to do, given the number of different contexts that are possible. Maybe its possible to do a few interesting ones. One is to send an OPTIONS to a URL and get an answer that pertains to *that* URL, while not necessarily pertaining to any other URL. AFAIK that is, more or less, what the current definition of OPTIONS does. You might choose to extrapolate the results for that URL to other URLs, but that may or may not produce correct results. Of course this is also limited, in that it only reports the results for OPTIONS. It has no way to customize the results for other methods. (For instance, some MIME types are likely to be acceptable only in the context of certain methods. Application/SDP may not be acceptable for MESSAGE.) To get beyond the answer for one URL, we need a way to indicate we want an answer for a class of URLs, maybe all of them. Some seem to think that a URL with no user part is an indicator for this. I think that is probably a sensible meaning for some servers, but not all of them. IMO there is no good value you can pick to put in the user part of the R-URI to indicate this. But perhaps it could be indicated via some new header. If this is the desire, and single answers are desired, then some accuracy must be given up. Presumably the answer must be the union of the answers for all the URIs it applies to. So for any particular URI the answer might be less. Also, there is the distinction between what might be available on a good day, vs. what the server is currently capable of, vs. what it is *willing* to do. Again, I don't see how any one answer is the right one for this. (E.g. the server is heavily loaded. It is capable of accepting *some* requests, but is only willing to accept requests from privileged callers. Or, it is in shutting-down mode. It has plenty of resources, but is only willing to accept in-dialog requests.) Again, I think to get at this will require an indicator in the request of which sort of answer you want. Unless we can agree the answer is always and only about *capability*, and never about policy. Bottom line here: I think there needs to be a selector, or selectors, for which kind of answer is desired. >>> So for me, the main use-case for sending OPTIONS right now is to >>> learn the capability of the next-hop to process messages. >> You mean the dynamic, current "capacity" to process messages, not the >> theoretical "ability" to do so when resources are available? Or do you >> mean both? > > Current. Sorry - I botched my message that you are replying to. I wrote the above, then the list immediately below to replace that. >> Do you mean: >> - the theoretical "ability" to do so when resources are available, >> - the "capacity" to do so given current load and resource availability, >> - the "willingness" to do so, at this time, for this requestor? > > If you mean "for this requestor" to mean for the same hop (as opposed to for the same source Contact URI), then I'd argue the second and third are effectively the same thing, in practice. I believe that has even come up in the overload discussions a long time ago, and I think there was agreement they are effectively the same thing, logically. Just because a next-hop tells me it can't do any more, but tells someone else something different, doesn't matter to my local processing of future requests to it. I meant whatever the server would use as input to any policy decisions it might make. That might mean the sender of the message (top Via value), the originator of the request, whatever. For instance, administrative shutdown would be a policy that determines willingness to handle requests. (At least until the listeners are stopped.) It might apply to certain links, which is what you are getting at. It might also apply to certain request originators, or to in-dialog vs. out-of-dialog requests, etc. It might also apply to certain R-URIs. Policies to throttle load before overload occurs could also fall into this category of "willingness". The specified expectation that an OPTIONS should return 486 if the device (a phone presumably) is on a call also falls into this "policy" category, since it could alternatively hang up the existing call or put it on hold to accept the new call. I can see utility in getting theoretical capability as well: it would be nice to be able to determine which if any of your devices could support video, even if currently busy. I might then choose to wait till the video phone is free rather than calling now on the audio phone. (But of course this is better done with presence.) But, if the majority of people can agree on a single context in which they want an answer, then perhaps we can simply have a single indicator that says we want that, rather than whatever it is that OPTIONS otherwise returns. >> I expect that people have had one, or more, of the meanings I list above >> in mind, perhaps without realizing that they are different. I'm willing >> to bet not everyone will agree its the same one of the above. OPTIONS, >> as currently defined, cannot provide all three answers. Nor will >> tightening up the specs change that, though doing so might make it do a >> better job of *one* of those. > > In every case I have seen this used for in deployment, as far as I can tell they have actually meant the same thing. To be fair, ACME has a particular perspective. SBCs talk to a certain class of equipment. I doubt you have need to interface directly to phones. But others do use OPTIONS to phones. >> Then, lets talk about what range of things a given response applies to: >> >> Suppose I send OPTIONS to >> - sip:198.51.100.101:5060 >> Does the response I get apply also to >> - sip:198.51.100.101:5061, >> - sip:alice@198.51.100.101:5060, >> - sip:alice@198.51.100.101:5060, >> - sips:carol@198.51.100.101:5061 >> - sip:example.com (maps to 198.51.100.101) >> - sip:pbx1.example.com (also maps to 198.51.100.101) > > YES. If the responder understands the Header, then it's reporting a system-level capability. (luckily you forgot about anycasting ;) I slipped some ringers in there for you. :-) There is no guarantee that two ports for the same ip address are served by the same "server". They may be served by separate processes with independent resources. Statistically there is probably a good chance that 5060 and 5061 are served by the same server. But once you get past that, then what? I didn't put in multi-homing situations, or IPv6/IPv6 cases, but they apply too. For all of these I can't see a good alternative to assuming they are distinct and asking on each, or *configuring* the cases when you *know* they are the same. And I still disagree with assuming they are the same when the user part varies, unless we add something to the message to indicate that is what is desired. But even an indicator won't deal with the port issue, or with multihoming, since you can't know if the device speaks for the others. OR, the response could be altered to indicate all the different addresses is applies to. >> But for a "phone" sip:198.51.100.101:5060 might just denote the "primary >> line", while sip:2@198.51.100.101:5060 may denote the "secondary line". >> And then the answer for one might have little predictive value over >> requests to the other. E.g. an OPTIONS to one might return 486 because >> the phone is busy, while an OPTIONS to the other might return 200. > > Hence the need/desire for a Header. > > >> For a gateway, there may well be DSP resources required to establish a >> call, and how much, or what type may depend on the codecs used in the >> call. So an answer to OPTIONS won't be valuable in predicting if a >> particular call can succeed. > > That's OK. A "box-wide" semantic is a superset. If you can handle ANY more calls (from that previous hop), then "box-wide" you can handle more calls. That doesn't mean you can't reject future calls due to unavailable resources such as DSPs. If you can NOT handle any more "box-wide", for example due to CPU, then the number of DSP resources you have really doesn't matter. That is a possible interpretation. If some (expensive) codecs are disabled during peak load, should that be reflected in the response? What if some destinations are currently unreachable? Should OPTIONS for a particular address reflect that? (E.g. only +1... calls are currently operational because the international trunk is down. Should OPTIONS to sip:+44... return 480 or 200?) Thanks, Paul _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore --------------B005E6949D16541E27699E88-- From nobody Fri Jul 8 09:30:06 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32D4712D7F8 for ; Fri, 8 Jul 2016 09:30:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vy0lpStIa6SB for ; Fri, 8 Jul 2016 09:29:57 -0700 (PDT) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80F0512D605 for ; Fri, 8 Jul 2016 09:29:47 -0700 (PDT) Received: by mail-vk0-x234.google.com with SMTP id d67so60948864vkh.1 for ; Fri, 08 Jul 2016 09:29:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=26yYrvvODoo/epLXc7DHasSRKyEY5v9JYfyOE/y2EEE=; b=KYTTaHoRLTHSsnxxBCxy1qLPGEYL0lmA4/VYkRV5avqVrF6ZlDtwdHcERvNO1RbAO7 P1ssxAw4xiLaTGz+1l2oa46kS5s4VnlsWPto2hGcYcK8c56LAQ3BG5n3IlckFlPQnMuQ Nej0h8SAjgVlbTuEYbygHVir6X0fxVhZN8cbp6mC9RWK50F+xsGqejTZmR8B4nOS588/ H5E5GMtEW0IjK874MMug0y4hKSn5jJeTSNNWgrDpenoGWKW6QQnbbum2TstsJInugnVb uV3UdMXyOYuFWBLPDjV+PXShp2hEgaWXDBbS1qy4ooWZsETI2hV4+1A1Ijk5iwxKk+Z7 2xxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=26yYrvvODoo/epLXc7DHasSRKyEY5v9JYfyOE/y2EEE=; b=DeTLoTbO0dFtt5D0Rw4RY28P+sksUuPNSauzMPmg1jdBVRypAvmut+0Ept/907tevu 838gVLrzCFK9JAHI0SuVW9oO4nkYt3YEIiHFYds3lzexg0bEfrD36C2jIMdS3wE+WQ8u aogcAEM3p2b7xBz5JtL6gPwkKv4helIXrtOdgNuE61cui+4Hq8MHkwvaHfhpfe3hZVKe Xh/RnRpSFrOhO+id1MWSpwNWbGySuLF43YgM8zg6viQ0EeefJYqDF4JrNSPrPCmI65BW dpdWwMt66EbmY1n5+qYmgIQMjHCs1+XirRAqU+xRcxu90ynKWoV9Ba5oymehuFRKgZk8 QRrQ== X-Gm-Message-State: ALyK8tIOhkdtUKTwMmDxSRna7Ad7i7SiBoCb6oDf/SaoFDMWZo6VbWevu1ibq4ggYjzjC3rvoCrnCRXvd49K/g== X-Received: by 10.159.41.69 with SMTP id t63mr1315228uat.66.1467995381616; Fri, 08 Jul 2016 09:29:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.2.142 with HTTP; Fri, 8 Jul 2016 09:29:40 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B37F97548@ESESSMB209.ericsson.se> From: Rifaat Shekh-Yusef Date: Fri, 8 Jul 2016 12:29:40 -0400 Message-ID: To: "Peterson, Jon" Content-Type: multipart/alternative; boundary=94eb2c0c512040d45b0537224f33 Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] SIP AuthNZ Problem Statement - v3 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 16:30:03 -0000 --94eb2c0c512040d45b0537224f33 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jul 6, 2016 at 9:10 PM, Peterson, Jon wrote: > > >> So how does the conference server know which type of conference to start= ? >> Well, again, you've focused this discussion on the corner case of an ad = hoc >> RFC4579 conference, >> > > I disagree that this is a corner case; you could replace that conference > server with any other SIP service and the same mechanism would apply. > > > We've probably delved excessively into this one use case - it perhaps > would have been more helpful to see examples of the attributes you propos= e > for others services. > Sure. I could do that. > > It is a "corner case" in so far as most of RFC4579 focuses on the "sunny > day" case where there is a pre-existing conference URI (probably gotten v= ia > means like an "IVR, web page") that you just dial into or add people to. > Only Section 5.4 deals with this "ad hoc" case. And of course RFC4579 is > just one way of managing conferences in a landscape full of methods that > use protocols other than SIP, albeit SIP will be used to actually initiat= e > sessions to the conference. > > As I mentioned multiple times already, my intention is *not* to specifically discuss the conference use case, but discuss the idea of delegating AuthNZ to a separate party other than the server providing the service. > > in the ad hoc case the conference bridge has to infer that from the type >> of session that the user agent creates with the conference bridge with i= ts >> initial INVITE. >> > > Not sure why you are saying "the conference bridge has to *infer* that"; > the information would be explicitly provided in the token. > > > The main point of my last message was to try to tease apart a) what kind > of conference the user wants from b) what kind of conference the IdP is > willing to authorize. The fact that you're still just conflating them he= re > suggests we're making little progress in even communicating, let along > persuading each other. > > Upleveling, if you think a token, rather than the SDP in the SIP INVITE, > tells the conference bridge what kind of media the user agent is proposin= g > for its session, > No, that is *not* what I am suggesting at all. > then the scope of the problem you're considering is even more unwieldy > than I thought. The potential difference between a) the media types the > user (as a matter of personal conference policy) would allow any > participants to use in the conference vs. c) which media the user is > proposing in the SDP of the INVITE for its own connection to the conferen= ce > bridge, is the further wrinkle I was attempting to untangle in the line y= ou > quote above - many elements need to be teased apart to understand the ad > hoc case. > > >> Our real disconnect I think is the degree to which you think SIP offers >> "services" or that application control is inside the scope of SIP. It's = not. >> > > Here are few RFCs that do just that; define services and control them: > https://tools.ietf.org/html/rfc5359 > https://tools.ietf.org/html/rfc3087 > https://datatracker.ietf.org/doc/rfc7463/ > > > These are pretty much landline replacement "services" for CLASS features > and similar functions, > I have no idea what you mean by "CLASS feature"; can you please elaborate? > so I'll talk more about them in a minute. But I'd be real interested to > hear what kinds of OAuth-style attributes need to be carried in tokens in > order to authorize those sorts of functions, and how the post-1970s PSTN > managed to live without them for decades. > > > SIP is a protocol that allows Internet endpoints to discover one another >> and to agree on the character of a session they'd like to share, accordi= ng >> to RFC3261. If I may quote from Section 2 of that document "SIP does no= t >> offer conference control services" and indeed "SIP does not provide >> services." >> > > Here is the full quote: > > "SIP does not provide services. Rather, * SIP provides primitives that= * > * can be used to implement different services*. For example, *SIP can* > * locate a user and deliver an opaque object to his current location*. > If this primitive is used to deliver a session description written in > SDP, for instance, the endpoints can agree on the parameters of a > session. *If the same primitive is used to deliver a photo of the* > * caller as well as the session description, a "caller ID" service can* > * be easily implemented*. As this example shows, *a single primitive > is* > * typically used to provide several different services*." > > > > This means that SIP is not limited to negotiating session characteristics= ; > it is much more than that and could be used to provide services. > > > You passed over my RFC3261 quote that "SIP does not offer conference > control services" in silence while > As I mentioned above, my goal is not to specifically discuss conference control services. > bolding lots of other 14 point text there. > Sorry about that. I use Gmail which does not provide much control over the size of the font, I selected the one above Normal, which happened to be Large =F0=9F=98=80. > To talk about the paragraph you quote we need to open the more > philosophical question of "what do we consider a service?" Clearly, if > caller-ID is a service, or call waiting, or similar CLASS features, then = in > that sense of course SIP provides "services" via its primitives, and I've > worked on defining a few myself. But CLASS features as "services" are not > of remotely the same category as OAuth third-party services that consume > tokens from IDPs - you don't need any sort of third-party authorization > attribute or token in an INVITE to put someone on hold to take another > call, say, or to send an image between endpoints. > While I agree that some of these are basic features that would probably be provided by default, I do not think that our goal here is to tell the service provided what and what not to authorize. The goal should be to define a *framework *that would allow them to choose what they want to authorize. > Back in the days of IN, these kinds of features had to be performed by > "the network," and it was kind of a big deal that instead in SIP you just > implemented them in primitives under the control of user agents, hence th= is > text. But I think you are more concerned with controlling third party > applications than with features like call waiting, and conflating those t= wo > categories under the umbrella of "services" to make it sound like SIP > encompasses and legitimizes what you want to do is not going to persuade > me, in any event. > Let me make sure I understand what you are saying here, Are you saying that just because the SIP application is provided by a third party server you would not consider that to be a SIP service? > > SIP does provide the primitives necessary to implement CLASS features, an= d > a number of RFCs today describe how to implement those features with SIP > primitives. And when you initiate a session with a voicemail bridge, say, > we could authorize your access to voicemail boxes in a number of differen= t > ways. But if you wanted to implement a trait-based authorization system f= or > authorizing access to voicemails held on a third-party server, > realistically, would (or should) you do it with SIP? > Why not? There are existing SIP application servers that do that already. > Because there are a lot of HTTP and IMAP based visual voicemail services > out there that support advanced features like speech-to-text transcriptio= n > and so on where OAuth-like primitives make a lot of sense. Just because y= ou > can call a voicemail service with a SIP INVITE, that doesn't means that a > SIP INVITE is the right place to stage an OAuth "service" like that, nor > its security. I feel exactly the same way about conference policy. > We are obviously in disagreement here, but I am not sure I understand the "= nor its security" comment; can you elaborate? > > > The last sentence in the above quote is really important. An INVITE could > be used to start a conference, access a voice mail, put a call on hold, > etc; these services require different authorizations. > > > An INVITE can be used to initiate a session with a conference bridge, > because semantics of an INVITE are "hey, I would like to initiate a sessi= on > with you with the following media parameters." Setting conference policy > requires a different semantics than that, and as I've repeatedly said in > this thread (and as far as I can tell, you have not contradicted), the > relevant RFCs recommend that you don't set conference policy with SIP. I'= m > really don't understand why that does not deter you. > > I think at this point, if you want to propose your way of setting > conference policy with SIP as a problem space, feel free - I don't happen > to think there's much of a gap there, given the existence of means other > than RFC4579 ad hoc INVITEs to set up conferences when you have more > complicated security needs than an ad hoc conference ordinarily would. If > the group agrees that there is 1) a need to convey conference policy in > SIP, and 2) a need for attribute-based authorization tokens issued by IdP= s > to support that conference policy, > Again, I am *not* suggesting to use SIP to set the policy (1); SIP will only be used to carry the authorization (2). Regards, Rifaat > that could be scoped as its own problem space and put forward for > dispatch. But I don't think this is a general authorization problem for S= IP. > > Jon Peterson > Neustar, Inc. > --94eb2c0c512040d45b0537224f33 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jul 6, 2016 at 9:10 PM, Peterson, Jon <jon.peterson@neu= star.biz> wrote:


So how does the conference server know which type of conference to sta= rt? Well, again, you've focused this discussion on the corner case of a= n ad hoc RFC4579 conference,

I disagree that this is a corner case; you could replace that conferen= ce server with any other SIP service and the same mechanism would apply.

We've probably delved excessively into this one use case - = it perhaps would have been more helpful to see examples of the attributes y= ou propose for others services.

Sure. I could do that.
=C2=A0

It is a "corner case" in so far as most of RFC4579 focuses o= n the "sunny day" case where there is a pre-existing conference U= RI (probably gotten via means like an "IVR, web page") that you j= ust dial into or add people to. Only Section 5.4 deals with this "ad hoc" case. And of course RFC4579 is just one way of managing= conferences in a landscape full of methods that use protocols other than S= IP, albeit SIP will be used to actually initiate sessions to the conference= .

As I mentioned multiple times= already, my intention is not to specifically discuss the conference= use case, but discuss the idea of delegating AuthNZ to a separate party ot= her than the server providing the service.
=C2=A0

in the ad hoc case the conference bridge has to infer that from the ty= pe of session that the user agent creates with the conference bridge with i= ts initial INVITE.

Not sure why you are saying "the conference bridge has to infer that"; the information would be explicitly provide= d in the token.

The main point of my last message was to try to tease apart a) = what kind of conference the user wants from b) what kind of conference the = IdP is willing to authorize.=C2=A0 The fact that you're still just conf= lating them here suggests we're making little progress in even communicating, let along persuading each other. =C2=A0

Upleveling, if you think a token, rather than the SDP in the SIP INVIT= E, tells the conference bridge what kind of media the user agent is proposi= ng for its session,

No, that i= s not what I am suggesting at all.

=C2=A0
then the scope of the pro= blem you're considering is even more unwieldy than I thought. The potential difference between a) the media types the user (as a matter = of personal conference policy) would allow any participants to use in the c= onference vs. c) which media the user is proposing in the SDP of the INVITE= for its own connection to the conference bridge, is the further wrinkle I was attempting to untangle in the line yo= u quote above - many elements need to be teased apart to understand the ad = hoc case.
Our real disconnect I think is the degree to which you think SIP offer= s "services" or that application control is inside the scope of S= IP. It's not.

Here are few RFCs that do just that; define services and control them:=

These are pretty much landline replacement "services"= for CLASS features and similar functions,
I have no idea what you mean by "CLASS feature"; can = you please elaborate?


=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);pa= dding-left:1ex">
so I'll talk more about t= hem in a minute. But I'd be real interested to hear what kinds of OAuth= -style attributes need to be carried in tokens in order to authorize those sorts of functions, and how the post-1970s PSTN managed to live with= out them for decades.


SIP is a protocol that allows Internet endpoints to discover one anoth= er and to agree on the character of a session they'd like to share, acc= ording to RFC3261. If I may quote from Section 2 =C2=A0of that document &qu= ot;SIP does not offer conference control services" and indeed "SIP does not provide services." =C2=A0

Here is the full quote:

=C2=A0 "SIP does not provide s= ervices.=C2=A0 Rather, SIP provides primitives that
=C2=A0 =C2=A0ca= n be used to implement different services.=C2=A0 For example, SIP can
=C2=A0 =C2=A0locate a user and d= eliver an opaque object to his current location.
=C2=A0 =C2=A0If this primitive is u= sed to deliver a session description written in
=C2=A0 =C2=A0SDP, for instance, the= endpoints can agree on the parameters of a
=C2=A0 =C2=A0session. =C2=A0If t= he same primitive is used to deliver a photo of the
=C2=A0 =C2=A0caller as well as t= he session description, a "caller ID" service can
=C2=A0 =C2=A0be easily implement= ed.=C2=A0 As this example shows, a single primitive is
=C2=A0 =C2=A0ty= pically used to provide several different services."=


This means that SIP is not limited to negotiating session characterist= ics; it is much more than that and could be used to provide services.

You passed over my RFC3261 quote that "SIP does not offer confere= nce control services" in silence while
=

=C2=A0As I mentioned above, my goal is not to spec= ifically discuss conference control services.

=C2=A0
bolding lo= ts of other 14 point text there.

Sorry about that. I use Gmail which does not provide much control o= ver the size of the font, I selected the one above Normal, which happened t= o be Large=C2=A0=F0=9F=98=80.



To talk about the paragraph you quote we need to open the more philoso= phical question of "what do we consider a service?" Clearly, if c= aller-ID is a service, or call waiting, or similar CLASS features, then in = that sense of course SIP provides "services" via its primitives, and I've worked on defining a few myself. But CLAS= S features as "services" are not of remotely the same category as= OAuth third-party services that consume tokens from IDPs - you don't n= eed any sort of third-party authorization attribute or token in an INVITE to put someone on hold to take another call, say, or= to send an image between endpoints.

While I agree that some of these are basic features that would proba= bly be provided by default, I do not think that our goal here is to tell th= e service provided what and what not to authorize.
The goal shoul= d be to define a framework that would allow them to choose what they= want to authorize.

=C2=A0
=
Back in the days of IN, these kinds of feature= s had to be performed by "the network," and it was kind of a big = deal that instead in SIP you just implemented them in primitives under the control of user agents, hence thi= s text. But I think you are more concerned with controlling third party app= lications than with features like call waiting, and conflating those two ca= tegories under the umbrella of "services" to make it sound like SIP encompasses and legitimizes what you want to do = is not going to persuade me, in any event.
Let me make sure I understand what you are saying here,
Are you saying that just because the SIP application is provided by a th= ird party server you would not consider that to be a SIP service?

=C2=A0

SIP does provide the primitives necessary to implement CLASS features,= and a number of RFCs today describe how to implement those features with S= IP primitives. And when you initiate a session with a voicemail bridge, say= , we could authorize your access to voicemail boxes in a number of different ways. But if you wanted to imp= lement a trait-based authorization system for authorizing access to voicema= ils held on a third-party server, realistically, would (or should) you do i= t with SIP?

Why not?
There are existing SIP application servers that do that already.

=C2=A0
Because there are a lot of HTTP and IMAP based visual voicemail services out there that suppor= t advanced features like speech-to-text transcription and so on where OAuth= -like primitives make a lot of sense. Just because you can call a voicemail= service with a SIP INVITE, that doesn't means that a SIP INVITE is the right place to stage an OAuth &= quot;service" like that, nor its security. I feel exactly the same way= about conference policy.=C2=A0=C2=A0
=

We are obviously in disagreement here, but I am not sur= e I understand the "nor its security" comment; can you= elaborate?

=C2=A0


The last sentence in the above quote is really important. An INVITE co= uld be used to start a conference, access a voice mail, put a call on hold,= etc; these services require different authorizations.

An INVITE can be used to initiate a session with a conference b= ridge, because semantics of an INVITE are "hey, I would like to initia= te a session with you with the following media parameters." Setting co= nference policy requires a different semantics than that, and as I've repeatedly said in this thread (and as far as I can = tell, you have not contradicted), the relevant RFCs recommend that you don&= #39;t set conference policy with SIP. I'm really don't understand w= hy that does not deter you.=C2=A0

I think at this point, if you want to propose your way of setting conf= erence policy with SIP as a problem space, feel free - I don't happen t= o think there's much of a gap there, given the existence of means other= than RFC4579 ad hoc INVITEs to set up conferences when you have more complicated security needs than an ad hoc conference or= dinarily would. If the group agrees that there is 1) a need to convey confe= rence policy in SIP, and 2) a need for attribute-based authorization tokens= issued by IdPs to support that conference policy,

Again, I am= not suggesting to use SIP to set the policy (1); SIP will only be u= sed to carry the authorization (2).

Regards,
=
=C2=A0Rifaat

=C2=A0
that could be scoped as its own problem space an= d put forward for dispatch. But I don't think this is a general authori= zation problem for SIP.

Jon Peterson
Neustar, Inc.

--94eb2c0c512040d45b0537224f33-- From nobody Wed Jul 13 07:15:25 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A09CC12D81F for ; Wed, 13 Jul 2016 07:15:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P1Bu5QMSkCsS for ; Wed, 13 Jul 2016 07:15:18 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE13A12D824 for ; Wed, 13 Jul 2016 07:15:17 -0700 (PDT) Received: from [192.168.40.18] (h87-96-134-129.cust.se.alltele.net [87.96.134.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id 82B3842AB; Wed, 13 Jul 2016 16:15:14 +0200 (CEST) From: "Olle E. Johansson" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Wed, 13 Jul 2016 16:15:14 +0200 Message-Id: <1EE2D149-1E1A-49DA-ACB8-625FEC4E4508@edvina.net> To: sipcore@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Olle E Johansson Subject: [sipcore] Declaring SIP 1.0 historic? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 14:15:24 -0000 Friends, Is it time to declare SIP 1.0 historic? I haven=E2=80=99t met a SIP 1.0 = implementation in use for many, many years. https://tools.ietf.org/html/rfc2543 /O= From nobody Wed Jul 13 07:23:48 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B11E12D8C8 for ; Wed, 13 Jul 2016 07:23:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ryfTDbR40Nrf for ; Wed, 13 Jul 2016 07:23:42 -0700 (PDT) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A957D12D87D for ; Wed, 13 Jul 2016 07:23:42 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id f6so21715470ith.1 for ; Wed, 13 Jul 2016 07:23:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xZIQe/VkFNipH/rnjps6tDufMQTK26VpGgSS38mJKqE=; b=yNiT/8FcmPph9HssR/cfA82imbqSFICybu1Zw25D854wUOlMFyOvAqb77tOB0IBwOU l5c8KmXkj+Tj0sKZaBCqf46l2FLCQGLhswdgzaO8XQQFippwhtl2MN+hv6NCCtN7X5fT hNqg1CKcqaZzhFvOUtKqLZyyDuWJcZF5LPS+wrXec6DtXZuTz8P85YtTD5JPqFxJ4KAx dsDRaZx3k7MnJ5/e7iL0MeWwJXqwzn9IPg06T4k/jSErnhe3hW0NvtnQ36j6wXm5itiA 3TVbnubgWEZzUQYo+FzI4HTI/f9+ZlHm4nPkZO+EE0RID5isl7k9Qlekj/2h6oILZ/a6 tmWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xZIQe/VkFNipH/rnjps6tDufMQTK26VpGgSS38mJKqE=; b=exgUbsTzscrSX1JrmrVQNVJJRj0N3BySj/qDhk/zly88Qdqc2D1c97r1fETic/vxm7 h7rg5AUwK+UQhdstiImpego+OzVQawr7LrhEqd6Ltn73x9jnrw45t4QDLfVCMhLX0k8T pTqYENeBWu513VKOdm42B64pFTbbYX7kuMbpnLWh5EBf1sZ3e2UnBlkCHRsDrGlGtk1e 5EPPp7FfirAa0J5dTtvJmVTcItff+g3U8btDN3uZZTWL4TRdQA1G8ZqToCJ53PxvAHxa 5X9uj5VZNCEqjwlb6Sp9GJsBtmLG7GLV9nW2Ohc96VMLCfGFO7fOjLM9omY7cHBzGSd+ qIrA== X-Gm-Message-State: ALyK8tJBAF1+ek2TYFewisLH3IobFAH16ULSCMjhQ/Q7dv0NiDjxFJ69KwMoU5V1Uh0yUQ== X-Received: by 10.36.155.198 with SMTP id o189mr23094856itd.54.1468419820897; Wed, 13 Jul 2016 07:23:40 -0700 (PDT) Received: from mail-io0-f179.google.com (mail-io0-f179.google.com. [209.85.223.179]) by smtp.gmail.com with ESMTPSA id 97sm2413235ioi.12.2016.07.13.07.23.40 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Jul 2016 07:23:40 -0700 (PDT) Received: by mail-io0-f179.google.com with SMTP id q83so47811481iod.1 for ; Wed, 13 Jul 2016 07:23:40 -0700 (PDT) X-Received: by 10.107.130.31 with SMTP id e31mr8860842iod.66.1468419820312; Wed, 13 Jul 2016 07:23:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.62.139 with HTTP; Wed, 13 Jul 2016 07:23:39 -0700 (PDT) In-Reply-To: <1EE2D149-1E1A-49DA-ACB8-625FEC4E4508@edvina.net> References: <1EE2D149-1E1A-49DA-ACB8-625FEC4E4508@edvina.net> From: Roman Shpount Date: Wed, 13 Jul 2016 10:23:39 -0400 X-Gmail-Original-Message-ID: Message-ID: To: "Olle E. Johansson" Content-Type: multipart/alternative; boundary=001a113ed0d0c55ebb053785214c Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] Declaring SIP 1.0 historic? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 14:23:47 -0000 --001a113ed0d0c55ebb053785214c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yes, please. I would be happy to remove the RFC 2543 transaction matching. _____________ Roman Shpount On Wed, Jul 13, 2016 at 10:15 AM, Olle E. Johansson wrote: > Friends, > > Is it time to declare SIP 1.0 historic? I haven=E2=80=99t met a SIP 1.0 > implementation in use for many, many years. > > https://tools.ietf.org/html/rfc2543 > > /O > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --001a113ed0d0c55ebb053785214c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yes, please. I would be happy to remove the RFC 2543 trans= action matching.

____________= _
Roman Shpount

On Wed, Jul 13, 2016 at 10:15 AM, Olle E. Jo= hansson <oej@edvina.net> wrote:
Friends,

Is it time to declare SIP 1.0 historic? I haven=E2=80=99t met a SIP 1.0 imp= lementation in use for many, many years.

https://tools.ietf.org/html/rfc2543

/O
_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

--001a113ed0d0c55ebb053785214c-- From nobody Wed Jul 13 07:28:42 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9571B12D838 for ; Wed, 13 Jul 2016 07:28:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=broadsoft-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PKIp5YrfV9mZ for ; Wed, 13 Jul 2016 07:28:37 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E8B812D81C for ; Wed, 13 Jul 2016 07:28:37 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id s63so45096980qkb.2 for ; Wed, 13 Jul 2016 07:28:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadsoft-com.20150623.gappssmtp.com; s=20150623; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:content-transfer-encoding; bh=jOCArDywZ18looU6/x5yn4WhfiDM0Y+518sMALnT9dw=; b=m8mE3p8ez8DyfkC2svbZPq28TWxkUvgxIv0hHOnMK1/QZKNh60Th/Pyj25zroq0Ho/ ECjZlaS2JfPK9vU5pxlJrB7UNDEWUuOiLAChmNGvZE3EivixCa/szTAWceQCfG1B5kKb gAK9fH8aZfSTvFXP2JqszkRH0Q+GJ/eLL34D3BRBwM7t6qiBhlP2WgWpLcVJGe6/8Tpr MuyS5TMNcX87Ab37Qw0Jf0hXkC6PtnEvgHn0juQzUh7T2qJwkedb6UpOatftpZXgbUsc Utu0JSeIiD4dWGfvRXZVt+zUfcHZzAbQrngIfr03+qnL4AVdKEFQsNCXnJpuWONiaotR 9aFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:content-transfer-encoding; bh=jOCArDywZ18looU6/x5yn4WhfiDM0Y+518sMALnT9dw=; b=WF6d0XG78EoEzaIWVfQ0auwEb/skpIrf0A3WsjXFTjEFzF2Xf2mDvRWVGEY2gC5Ntq ne9wA5btXz0dRqZeak6I6hm9zgbmdKvnLF9zQIuJGD6gznNU2mSFWw296argXsA7e8/z l5nSt+f6Lb2g/odtoLoLVu8wxJdW70MnZLoJo05XEpwLyeetIbGGIxwFZv8sbQ04+jFO dhnCJkXmtlWGaYBM0IgKNuEMW6rUqIjw4XQJEUGEWawnPJ9Yfklnh1S7zUS4mD0iNz6/ 0sEbz7YsJl1g/qBDbWMdGvH+kxNfh2w1ieIPWAVemO1YgzkaU1JLlWTAv4H89HFUV7ll dZ6w== X-Gm-Message-State: ALyK8tJaxsS2JqSynvjootb2mUHX5rBGLsUdYGWznHent7bW77VjtYh7Jsiyy5xA3llipwvQAPqPJwa7rrB76mV5 X-Received: by 10.55.4.133 with SMTP id 127mr10895474qke.207.1468420116524; Wed, 13 Jul 2016 07:28:36 -0700 (PDT) From: Brett Tate References: <1EE2D149-1E1A-49DA-ACB8-625FEC4E4508@edvina.net> In-Reply-To: <1EE2D149-1E1A-49DA-ACB8-625FEC4E4508@edvina.net> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGhNHGVYLaedcNWJpc8nhZijnHPt6B3uY8Q Date: Wed, 13 Jul 2016 10:28:35 -0400 Message-ID: <76f2fd5e65bfa393281d682d23e18f11@mail.gmail.com> To: "Olle E. Johansson" , sipcore@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [sipcore] Declaring SIP 1.0 historic? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 14:28:41 -0000 Hi, RFC 2543 is version 2.0. Are you wanting to declare RFC 2543 as historic or whatever defined version 1.0 as historic? What would be the benefit of declaring RFC 2543 (or version 1.0) as historic? For instance, are you wanting to remove some of the backward compatibility related mandates contained within RFC 3261? Thanks, Brett > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Olle E. > Johansson > Sent: Wednesday, July 13, 2016 10:15 AM > To: sipcore@ietf.org > Cc: Olle E Johansson > Subject: [sipcore] Declaring SIP 1.0 historic? > > Friends, > > Is it time to declare SIP 1.0 historic? I haven=E2=80=99t met a SIP 1.0 > implementation in use for many, many years. > > https://tools.ietf.org/html/rfc2543 > > /O > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Wed Jul 13 07:41:18 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11AF312D923 for ; Wed, 13 Jul 2016 07:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q0AZ58ILRta0 for ; Wed, 13 Jul 2016 07:41:13 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4DB012D661 for ; Wed, 13 Jul 2016 07:41:13 -0700 (PDT) Received: from [192.168.40.18] (h87-96-134-129.cust.se.alltele.net [87.96.134.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id 15C5542C1; Wed, 13 Jul 2016 16:41:11 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Olle E. Johansson" In-Reply-To: <76f2fd5e65bfa393281d682d23e18f11@mail.gmail.com> Date: Wed, 13 Jul 2016 16:41:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <14FD7D34-CE8C-474C-A69F-D55A632193BE@edvina.net> References: <1EE2D149-1E1A-49DA-ACB8-625FEC4E4508@edvina.net> <76f2fd5e65bfa393281d682d23e18f11@mail.gmail.com> To: Brett Tate X-Mailer: Apple Mail (2.3124) Archived-At: Cc: sipcore@ietf.org, Olle E Johansson Subject: Re: [sipcore] Declaring SIP 1.0 historic? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 14:41:16 -0000 > On 13 Jul 2016, at 16:28, Brett Tate wrote: >=20 > Hi, >=20 > RFC 2543 is version 2.0. My mistake. >=20 > Are you wanting to declare RFC 2543 as historic or whatever defined = version > 1.0 as historic? RFC 2543 to historic >=20 > What would be the benefit of declaring RFC 2543 (or version 1.0) as > historic? For instance, are you wanting to remove some of the = backward > compatibility related mandates contained within RFC 3261? I don=E2=80=99t really know - but I suspect there are a lot of legacy = stuff hanging around like Roman pointed out. Maybe we can make things more simple. Just wanting to open a discussion and some housecleaning. /O >=20 > Thanks, > Brett >=20 >> -----Original Message----- >> From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Olle E. >> Johansson >> Sent: Wednesday, July 13, 2016 10:15 AM >> To: sipcore@ietf.org >> Cc: Olle E Johansson >> Subject: [sipcore] Declaring SIP 1.0 historic? >>=20 >> Friends, >>=20 >> Is it time to declare SIP 1.0 historic? I haven=E2=80=99t met a SIP = 1.0 >> implementation in use for many, many years. >>=20 >> https://tools.ietf.org/html/rfc2543 >>=20 >> /O >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore From nobody Wed Jul 13 07:57:28 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C3DB12D8C8 for ; Wed, 13 Jul 2016 07:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id twTuDR-AohEh for ; Wed, 13 Jul 2016 07:57:23 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0815512DA28 for ; Wed, 13 Jul 2016 07:57:23 -0700 (PDT) Received: from [192.168.40.18] (h87-96-134-129.cust.se.alltele.net [87.96.134.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id C520042C1; Wed, 13 Jul 2016 16:57:19 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Olle E. Johansson" In-Reply-To: <76f2fd5e65bfa393281d682d23e18f11@mail.gmail.com> Date: Wed, 13 Jul 2016 16:57:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1EE2D149-1E1A-49DA-ACB8-625FEC4E4508@edvina.net> <76f2fd5e65bfa393281d682d23e18f11@mail.gmail.com> To: Brett Tate X-Mailer: Apple Mail (2.3124) Archived-At: Cc: sipcore@ietf.org, Olle E Johansson Subject: Re: [sipcore] Declaring SIP 1.0 historic? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 14:57:26 -0000 > On 13 Jul 2016, at 16:28, Brett Tate wrote: >=20 > Hi, >=20 > RFC 2543 is version 2.0. I started googling for version 1.0 and it seems half of the Internet = believes that 2543 is version 1.0. "Session Initiation Protocol was first introduced in March 1999 by IETF = RFC 2543. This RFC (Request for Comments) was the original core = specification and was obsolete by IETF RFC 3261 in June 2002. These = RFC=E2=80=99s are more commonly known as SIP 1.0 (2543) and SIP 2.0 = (3261). There are many related RFCs that are summarized at the end of = this document.=E2=80=9D http://www.whichvoip.com/voip/protocols/sip.htm =E2=80=9Cthe protocol was standardized as RFC 2543 in 1999 (SIP 1.0). In = November 2000, SIP was accepted as a 3GPP signaling protocol and = permanent element of the IP Multimedia Subsystem (IMS) architecture for = IP-based streaming multimedia services in cellular systems. As of 2014, = the latest version (SIP 2.0) of the specification is RFC 3261, published = in June 2002,[2] with extensions and clarifications since then.[3]=E2=80=9D= https://en.wikipedia.org/wiki/Session_Initiation_Protocol As Brett says, RFC 2543 is indeed version 2.0: "4.3.1 SIP Version Both request and response messages include the version of SIP in use, and follow [H3.1] (with HTTP replaced by SIP, and HTTP/1.1 replaced by SIP/2.0) regarding version ordering, compliance requirements, and upgrading of version numbers. To be compliant with this specification, applications sending SIP messages MUST include a SIP- Version of "SIP/2.0=E2=80=9D.=E2=80=9D Realising I=E2=80=99ve been fooled by folklore I am still searching for = version 1.0. Any pointers? If we have 2.0 according to 2543 and 2.0 according to 3261 it=E2=80=99s = going to be hard to get rid of 2543. I would have no problem hearing that story - why did we keep the 2.0 = version in 3261 - while gently SIPping a german beer in Berlin next week :-) /O >=20 > Are you wanting to declare RFC 2543 as historic or whatever defined = version > 1.0 as historic? >=20 > What would be the benefit of declaring RFC 2543 (or version 1.0) as > historic? For instance, are you wanting to remove some of the = backward > compatibility related mandates contained within RFC 3261? >=20 > Thanks, > Brett >=20 >> -----Original Message----- >> From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Olle E. >> Johansson >> Sent: Wednesday, July 13, 2016 10:15 AM >> To: sipcore@ietf.org >> Cc: Olle E Johansson >> Subject: [sipcore] Declaring SIP 1.0 historic? >>=20 >> Friends, >>=20 >> Is it time to declare SIP 1.0 historic? I haven=E2=80=99t met a SIP = 1.0 >> implementation in use for many, many years. >>=20 >> https://tools.ietf.org/html/rfc2543 >>=20 >> /O >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore From nobody Wed Jul 13 08:32:22 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19E4612D18E for ; Wed, 13 Jul 2016 08:32:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sonusnetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RKD4qUb1aZKn for ; Wed, 13 Jul 2016 08:32:18 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0042.outbound.protection.outlook.com [104.47.32.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21D8A12D0AD for ; Wed, 13 Jul 2016 08:32:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=NPbtfEkMjmdG7BaPp1lFM7CG38UxoulLyKx8lm9KU4M=; b=BMWadWne/l0SGxuOcAYoikF0Hn+oRuslWyJW9P/PNK/z4Z11gYqWkVSjiLHATrJZ6Wrin05AnTHI/fm6+Zr6E8MTytBIZy72w94EEsMg6CXCO+Jvc0zCJon/UxOQXaXzLe6PdWNnZuQ2XYxYqNFwmbK2iKrGHhnwVndLP6ihvNs= Received: from DM2PR0301MB1213.namprd03.prod.outlook.com (10.160.219.154) by DM2PR0301MB1216.namprd03.prod.outlook.com (10.160.219.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.539.14; Wed, 13 Jul 2016 15:32:15 +0000 Received: from DM2PR0301MB1213.namprd03.prod.outlook.com ([10.160.219.154]) by DM2PR0301MB1213.namprd03.prod.outlook.com ([10.160.219.154]) with mapi id 15.01.0539.019; Wed, 13 Jul 2016 15:32:15 +0000 From: "Neelakantan, Neel" To: "Olle E. Johansson" , Brett Tate Thread-Topic: [sipcore] Declaring SIP 1.0 historic? Thread-Index: AQHR3REE86lXcAznHUKt47gnjWwR5aAWa4uAgAAIB4CAAANu4A== Date: Wed, 13 Jul 2016 15:32:15 +0000 Message-ID: References: <1EE2D149-1E1A-49DA-ACB8-625FEC4E4508@edvina.net> <76f2fd5e65bfa393281d682d23e18f11@mail.gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=nneelakantan@sonusnet.com; x-originating-ip: [12.171.83.97] x-ms-office365-filtering-correlation-id: 1df84ad1-cdca-461c-81cb-08d3ab32de55 x-microsoft-exchange-diagnostics: 1; DM2PR0301MB1216; 6:Y/5nzph1uXHJF46Vx5k+eGtp/q5RoxXrAjLNyw8K5tfVUgH1sOuoJYlluzpozvP+ux/bexeMemJPqvao5zKu143bvwSMUa2AGxwt/WVAAzxGMOLlPNA1xlDwnU7aVeDWykTeKRSA0gXqMKQ9CNmeIATC4dsuqGd30SU1aPryEBzy224NXYaA1VGzKRshj1aYG7ldQMLolouxW37U3wNTLMp+EBkAqe0cbiH6aFlJf8CtTVMut82RNHVtvcadyYzjCcIIZXGtz3qD69v0Whpay3FEeyKXgsuT2oQepmAHDCs=; 5:BsIx3y64OFi2JCFaUoL21gv3G/Smw2gt0UUXOkPtYD0Cp4zQa7KyAIzsb0kQVNL7TAFpIU4VniStYxjnN3+6zwxUTddVfe/p2tuEWcQphbxM2R6vEx9f2PzgRDobo8nVVZvjJ/P7ITniM8lnMDYHLw==; 24:EPE6egNFpWLPcI+mCg69K2jZY+UCVluFbMGv9/eGBsnlW6rPAZ/JeKgEvK4fstOZr8yROwO9+no/wYyID7Le4FXqlWOrPyckam560GtDglI=; 7:q5FKiZuFsByPW0xVT8CbPt3VmEVKVTd6Vdl2g+x56bdxBiMFqgqLk0uvntzub9dussYENok/UvIPkUzk1JWF6X/SKdFuIpf6BPIo1lxF4qN5izTmFKKuL3e1vyrHhGDnu5QfBJ7jt/WKytMFo39gxn7ZDrIWAa2c10wOT/neL24ouAxpY1rCzeb1M1SxFI3jRXXvYUFCVt/7dFxRbz6sZ9iNX9YN5Lr/+H0WpF9WAZZlvFL2aG4uqjjjVIfD+BHj x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB1216; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(85170053105377); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:DM2PR0301MB1216; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB1216; x-forefront-prvs: 000227DA0C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(24454002)(13464003)(199003)(189002)(377454003)(19273905006)(3280700002)(10400500002)(3660700001)(11100500001)(87936001)(2900100001)(33656002)(76176999)(54356999)(50986999)(101416001)(2950100001)(19300405004)(15975445007)(77096005)(122556002)(19580405001)(92566002)(86362001)(19580395003)(99286002)(106116001)(106356001)(105586002)(9686002)(81156014)(81166006)(305945005)(8676002)(7736002)(6116002)(5003600100003)(7696003)(3846002)(74316002)(4326007)(102836003)(97736004)(2906002)(586003)(68736007)(8936002)(7846002)(76576001)(66066001)(5001770100001)(189998001)(5002640100001)(562404015)(563064011); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR0301MB1216; H:DM2PR0301MB1213.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: sonusnet.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jul 2016 15:32:15.4280 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB1216 Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Declaring SIP 1.0 historic? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 15:32:21 -0000 SWYgeW91IGdvIG92ZXIgdGhlIGFyY2hpdmVzIG9mIDI1NDNiaXMgdGhpcyBnb3QgZGlzY3Vzc2Vk IGJhc2VkIG9uIHRoZSBTSVAgR3VydQ0KDQpodHRwOi8vd3d3LmNzLmNvbHVtYmlhLmVkdS9zaXAv dGFsa3MvaWV0ZjAwMDhfZHJhZnQwLnBkZg0KDQpUaGlzIGtlZXAgcG9wcGluZyB1cCBpbiB0aGUg bWFpbGluZyBsaXN0cy4gIFNlYXJjaGluZyB0aHJvdWdoIEkgY2FtZSBhY3Jvc3MgdGhpcyB3aGlj aCBwcmV0dHkgbXVjaCBwcm92aWRlcyByYXRpb25hbGUNCg0KaHR0cDovL3d3dy5pZXRmLm9yZy9t YWlsLWFyY2hpdmUvd2ViL3NpcC9jdXJyZW50L21zZzE4NDM2Lmh0bWwNCg0KSWYgeW91IHdhbnQg c29tZSBoaXN0b3J5LCByZmMyNTQzYmlzIGlzIGEgZ29vZCBwbGFjZSB0byBzdGFydC4NCg0KSGF2 aW5nIHNhaWQgdGhhdCwgaXQgbWFrZXMgc2Vuc2UgdG8gZGVwcmVjYXRlIGxlZ2FjeSBvciBicmVh a2luZyBmdW5jdGlvbmFsaXR5IHRoYXQgaGluZGVycyBlYXNlIG9mIGRlcGxveW1lbnRzLiAgVGlt ZSB0byBzdGFydCBhIElEIGFuZCBsaXN0IHRoaW5ncyB0aGF0IGFyZSBzY3J1YiB3b3J0aHk/DQoN ClRoYW5rcywNCk5lZWwuDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9t OiBzaXBjb3JlIFttYWlsdG86c2lwY29yZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg T2xsZSBFLg0KPiBKb2hhbnNzb24NCj4gU2VudDogV2VkbmVzZGF5LCBKdWx5IDEzLCAyMDE2IDk6 NTcgQU0NCj4gVG86IEJyZXR0IFRhdGUgPGJyZXR0QGJyb2Fkc29mdC5jb20+DQo+IENjOiBzaXBj b3JlQGlldGYub3JnOyBPbGxlIEUgSm9oYW5zc29uIDxvZWpAZWR2aW5hLm5ldD4NCj4gU3ViamVj dDogUmU6IFtzaXBjb3JlXSBEZWNsYXJpbmcgU0lQIDEuMCBoaXN0b3JpYz8NCj4gDQo+IA0KPiA+ IE9uIDEzIEp1bCAyMDE2LCBhdCAxNjoyOCwgQnJldHQgVGF0ZSA8YnJldHRAYnJvYWRzb2Z0LmNv bT4gd3JvdGU6DQo+ID4NCj4gPiBIaSwNCj4gPg0KPiA+IFJGQyAyNTQzIGlzIHZlcnNpb24gMi4w Lg0KPiBJIHN0YXJ0ZWQgZ29vZ2xpbmcgZm9yIHZlcnNpb24gMS4wIGFuZCBpdCBzZWVtcyBoYWxm IG9mIHRoZSBJbnRlcm5ldCBiZWxpZXZlcw0KPiB0aGF0IDI1NDMgaXMgdmVyc2lvbiAxLjAuDQo+ IA0KPiAiU2Vzc2lvbiBJbml0aWF0aW9uIFByb3RvY29sIHdhcyBmaXJzdCBpbnRyb2R1Y2VkIGlu IE1hcmNoIDE5OTkgYnkgSUVURiBSRkMNCj4gMjU0My4gVGhpcyBSRkMgKFJlcXVlc3QgZm9yIENv bW1lbnRzKSB3YXMgdGhlIG9yaWdpbmFsIGNvcmUgc3BlY2lmaWNhdGlvbg0KPiBhbmQgd2FzIG9i c29sZXRlIGJ5IElFVEYgUkZDIDMyNjEgaW4gSnVuZSAyMDAyLiBUaGVzZSBSRkPigJlzIGFyZSBt b3JlDQo+IGNvbW1vbmx5IGtub3duIGFzIFNJUCAxLjAgKDI1NDMpIGFuZCBTSVAgMi4wICgzMjYx KS4gVGhlcmUgYXJlIG1hbnkgcmVsYXRlZA0KPiBSRkNzIHRoYXQgYXJlIHN1bW1hcml6ZWQgYXQg dGhlIGVuZCBvZiB0aGlzIGRvY3VtZW50LuKAnQ0KPiANCj4gaHR0cDovL3d3dy53aGljaHZvaXAu Y29tL3ZvaXAvcHJvdG9jb2xzL3NpcC5odG0NCj4gDQo+IA0KPiDigJx0aGUgcHJvdG9jb2wgd2Fz IHN0YW5kYXJkaXplZCBhcyBSRkMgMjU0MyBpbiAxOTk5IChTSVAgMS4wKS4gSW4gTm92ZW1iZXIN Cj4gMjAwMCwgU0lQIHdhcyBhY2NlcHRlZCBhcyBhIDNHUFAgc2lnbmFsaW5nIHByb3RvY29sIGFu ZCBwZXJtYW5lbnQgZWxlbWVudA0KPiBvZiB0aGUgSVAgTXVsdGltZWRpYSBTdWJzeXN0ZW0gKElN UykgYXJjaGl0ZWN0dXJlIGZvciBJUC1iYXNlZCBzdHJlYW1pbmcNCj4gbXVsdGltZWRpYSBzZXJ2 aWNlcyBpbiBjZWxsdWxhciBzeXN0ZW1zLiBBcyBvZiAyMDE0LCB0aGUgbGF0ZXN0IHZlcnNpb24g KFNJUCAyLjApDQo+IG9mIHRoZSBzcGVjaWZpY2F0aW9uIGlzIFJGQyAzMjYxLCBwdWJsaXNoZWQg aW4gSnVuZSAyMDAyLFsyXSB3aXRoIGV4dGVuc2lvbnMNCj4gYW5kIGNsYXJpZmljYXRpb25zIHNp bmNlIHRoZW4uWzNd4oCdDQo+IA0KPiBodHRwczovL2VuLndpa2lwZWRpYS5vcmcvd2lraS9TZXNz aW9uX0luaXRpYXRpb25fUHJvdG9jb2wNCj4gDQo+IEFzIEJyZXR0IHNheXMsIFJGQyAyNTQzIGlz IGluZGVlZCB2ZXJzaW9uIDIuMDoNCj4gIjQuMy4xIFNJUCBWZXJzaW9uDQo+IA0KPiAgICBCb3Ro IHJlcXVlc3QgYW5kIHJlc3BvbnNlIG1lc3NhZ2VzIGluY2x1ZGUgdGhlIHZlcnNpb24gb2YgU0lQ IGluIHVzZSwNCj4gICAgYW5kIGZvbGxvdyBbSDMuMV0gKHdpdGggSFRUUCByZXBsYWNlZCBieSBT SVAsIGFuZCBIVFRQLzEuMSByZXBsYWNlZA0KPiAgICBieSBTSVAvMi4wKSByZWdhcmRpbmcgdmVy c2lvbiBvcmRlcmluZywgY29tcGxpYW5jZSByZXF1aXJlbWVudHMsIGFuZA0KPiAgICB1cGdyYWRp bmcgb2YgdmVyc2lvbiBudW1iZXJzLiBUbyBiZSBjb21wbGlhbnQgd2l0aCB0aGlzDQo+ICAgIHNw ZWNpZmljYXRpb24sIGFwcGxpY2F0aW9ucyBzZW5kaW5nIFNJUCBtZXNzYWdlcyBNVVNUIGluY2x1 ZGUgYSBTSVAtDQo+ICAgIFZlcnNpb24gb2YgIlNJUC8yLjDigJ0u4oCdDQo+IA0KPiBSZWFsaXNp bmcgSeKAmXZlIGJlZW4gZm9vbGVkIGJ5IGZvbGtsb3JlIEkgYW0gc3RpbGwgc2VhcmNoaW5nIGZv ciB2ZXJzaW9uIDEuMC4gQW55DQo+IHBvaW50ZXJzPw0KPiANCj4gSWYgd2UgaGF2ZSAyLjAgYWNj b3JkaW5nIHRvIDI1NDMgYW5kIDIuMCBhY2NvcmRpbmcgdG8gMzI2MSBpdOKAmXMgZ29pbmcgdG8g YmUNCj4gaGFyZCB0byBnZXQgcmlkIG9mIDI1NDMuDQo+IA0KPiBJIHdvdWxkIGhhdmUgbm8gcHJv YmxlbSBoZWFyaW5nIHRoYXQgc3RvcnkgLSB3aHkgZGlkIHdlIGtlZXAgdGhlIDIuMA0KPiB2ZXJz aW9uIGluIDMyNjEgLSB3aGlsZSBnZW50bHkgU0lQcGluZyBhIGdlcm1hbiBiZWVyIGluIEJlcmxp biBuZXh0IHdlZWsgOi0pDQo+IA0KPiAvTw0KPiANCj4gPg0KPiA+IEFyZSB5b3Ugd2FudGluZyB0 byBkZWNsYXJlIFJGQyAyNTQzIGFzIGhpc3RvcmljIG9yIHdoYXRldmVyIGRlZmluZWQNCj4gPiB2 ZXJzaW9uDQo+ID4gMS4wIGFzIGhpc3RvcmljPw0KPiA+DQo+ID4gV2hhdCB3b3VsZCBiZSB0aGUg YmVuZWZpdCBvZiBkZWNsYXJpbmcgUkZDIDI1NDMgKG9yIHZlcnNpb24gMS4wKSBhcw0KPiA+IGhp c3RvcmljPyAgRm9yIGluc3RhbmNlLCBhcmUgeW91IHdhbnRpbmcgdG8gcmVtb3ZlIHNvbWUgb2Yg dGhlDQo+ID4gYmFja3dhcmQgY29tcGF0aWJpbGl0eSByZWxhdGVkIG1hbmRhdGVzIGNvbnRhaW5l ZCB3aXRoaW4gUkZDIDMyNjE/DQo+ID4NCj4gPiBUaGFua3MsDQo+ID4gQnJldHQNCj4gPg0KPiA+ PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiBzaXBjb3JlIFttYWlsdG86 c2lwY29yZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgT2xsZSBFLg0KPiA+PiBKb2hh bnNzb24NCj4gPj4gU2VudDogV2VkbmVzZGF5LCBKdWx5IDEzLCAyMDE2IDEwOjE1IEFNDQo+ID4+ IFRvOiBzaXBjb3JlQGlldGYub3JnDQo+ID4+IENjOiBPbGxlIEUgSm9oYW5zc29uDQo+ID4+IFN1 YmplY3Q6IFtzaXBjb3JlXSBEZWNsYXJpbmcgU0lQIDEuMCBoaXN0b3JpYz8NCj4gPj4NCj4gPj4g RnJpZW5kcywNCj4gPj4NCj4gPj4gSXMgaXQgdGltZSB0byBkZWNsYXJlIFNJUCAxLjAgaGlzdG9y aWM/IEkgaGF2ZW7igJl0IG1ldCBhIFNJUCAxLjANCj4gPj4gaW1wbGVtZW50YXRpb24gaW4gdXNl IGZvciBtYW55LCBtYW55IHllYXJzLg0KPiA+Pg0KPiA+PiBodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvcmZjMjU0Mw0KPiA+Pg0KPiA+PiAvTw0KPiA+PiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+PiBzaXBjb3JlIG1haWxpbmcgbGlzdA0KPiA+ PiBzaXBjb3JlQGlldGYub3JnDQo+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vc2lwY29yZQ0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gc2lwY29yZSBtYWlsaW5nIGxpc3QNCj4gc2lwY29yZUBpZXRmLm9yZw0K PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUNCg== From nobody Wed Jul 13 08:36:12 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5351512D5A4 for ; Wed, 13 Jul 2016 08:36:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yznxAP768wOE for ; Wed, 13 Jul 2016 08:36:10 -0700 (PDT) Received: from mailbackend.panix.com (mailbackend.panix.com [166.84.1.89]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1B7E12D501 for ; Wed, 13 Jul 2016 08:36:09 -0700 (PDT) Received: from compute06.cs.columbia.edu (compute06.cs.columbia.edu [128.59.11.36]) by mailbackend.panix.com (Postfix) with ESMTPSA id 0F8321794D; Wed, 13 Jul 2016 11:36:08 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <22406.24552.369096.256493@compute06.cs.columbia.edu> Date: Wed, 13 Jul 2016 11:36:08 -0400 From: Jonathan Lennox To: "Olle E. Johansson" In-Reply-To: References: <1EE2D149-1E1A-49DA-ACB8-625FEC4E4508@edvina.net> <76f2fd5e65bfa393281d682d23e18f11@mail.gmail.com> X-Mailer: VM 8.1.2 under 24.3.1 (x86_64-pc-linux-gnu) Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] Declaring SIP 1.0 historic? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 15:36:11 -0000 On Wednesday, July 13 2016, "Olle E. Johansson" wrote to "Brett Tate, s= ipcore@ietf.org, Olle E Johansson" saying: > Realising I=E2=80=99ve been fooled by folklore I am still searching f= or version 1.0. Any pointers=3F There never was a SIP/1.0. The 2.0 number was chosen to make sure that= SIP wouldn't be confused with HTTP/1.x on the wire, and also in a vague (an= d it turned out, vain) hope that it'd be possible to run SIP through HTTP proxies. > If we have 2.0 according to 2543 and 2.0 according to 3261 it=E2=80=99= s going to be hard to get > rid of 2543. It'd be possible to deprecate the old 2543-compatible transaction match= ing and source routing. I don't know how much of a gain that is for implementors, though. =20 > I would have no problem hearing that story - why did we keep the 2.0 = version in 3261 - while gently > SIPping a german beer in Berlin next week :-) We kept it because SIP routing rules (notably forking) mean that there'= s no good way to try to send a request with a newer version, and then if it fails, fall back to an older version. This is why all backward compatibility in SIP has to be single-pass. --=20 Jonathan Lennox lennox@cs.columbia.edu From nobody Wed Jul 13 09:13:50 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98FB612B034 for ; Wed, 13 Jul 2016 09:13:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=broadsoft-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lSPlMRJm7MTj for ; Wed, 13 Jul 2016 09:13:47 -0700 (PDT) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E176312D0DC for ; Wed, 13 Jul 2016 09:13:46 -0700 (PDT) Received: by mail-qt0-x22a.google.com with SMTP id j35so28375952qtj.2 for ; Wed, 13 Jul 2016 09:13:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadsoft-com.20150623.gappssmtp.com; s=20150623; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to; bh=+QYUntSJOk4x3gHQpnLkgZw4+rF17Ayfq5pRAnMqrlg=; b=IWqzCkH3dC4b5Zhz7eIn8UTANBJ4Wxbf4f0TAB90xkR4gwAB5VtmqKBtWeVxM9WMjW IdkWGDyvYTbUmpQgil5IR2ZinqjpTLUt+3z0L/hhWGCVgTr2GxkaPDMExQkrE+ek/FwB EeZJpyeMQB9kVTtUgi++BP0iQUGjJJqa3uZ61J+yfnwv+znDypHC97Gugqxta/EkCpgi erv9Z1GuzpC2UgAmkZt9knsO383VRV37QlDc2qZz3p7sGrnhnNUWSlVS4s/3k2KdoYbF ayE1q8RRCUpGXmmrOQppy8hdGPo0s3pUnncr+RRlcrT0fBTlY+UZxC8nt4gGP4QSNJSI dgdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to; bh=+QYUntSJOk4x3gHQpnLkgZw4+rF17Ayfq5pRAnMqrlg=; b=WXmksVgMXskuEgSBj9OL/YW9seRpUl6qIUl3OOINysyT1G8LzTH4qRgOzWs55Hj8dB tKVemu8jtJFGqjZfQw9xBSy1B+SBIKZg5g0A/1XUIkjfKGlwLMkBwvLPJlBYggBaiFQl 8zB9rYLEK8TnzO0gdxVcUnoDS/yjN+ngQu/Jb69g/JZIMROO7IymVJkA6q5QYVdXdaps jxnr0dKIsJzIzOdZcufSaa7mjR6IUT0UWDYPLJOlx3C8yab4tY2eEJnhkuJGIcjGW6oZ v45G5Tra96WiAwa4wuycjSlNM97r/yUqOBAJr0Pf2h6N1pmXQun0/m2itMGr3vBm5ziQ M6XQ== X-Gm-Message-State: ALyK8tK2oGyoA+Y4KUg0w0kjmfgcpQhuulx9W+L8tIYmr184wJ6dgFk5dViN67CCSgv5KrqqG7Kae4EQaNVg/QQv X-Received: by 10.200.48.141 with SMTP id v13mr13370354qta.76.1468426426017; Wed, 13 Jul 2016 09:13:46 -0700 (PDT) From: Brett Tate References: <1EE2D149-1E1A-49DA-ACB8-625FEC4E4508@edvina.net> In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGhNHGVYLaedcNWJpc8nhZijnHPtwBc4yA5oHTW4RA= Date: Wed, 13 Jul 2016 12:13:45 -0400 Message-ID: <6bdea1e67cd504e8d376f8a5da45d22c@mail.gmail.com> To: Roman Shpount , sipcore@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [sipcore] Declaring SIP 1.0 historic? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 16:13:48 -0000 > Yes, please. I would be happy to remove the > RFC 2543 transaction matching. I find RFC 3261 section 17.2.3 transaction matching to be overly lenient when using the magic cookie. For instance, the matching rules don't even include Call-ID and CSeq. Thus if you follow RFC 3261 section 17.2.3, you have to allow requests containing different Call-ID and CSeq to match because of the magic cookie flexibility. From nobody Wed Jul 13 10:01:28 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DBBC12D0DC for ; Wed, 13 Jul 2016 10:01:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id awdU0S6fi-Wv for ; Wed, 13 Jul 2016 10:01:25 -0700 (PDT) Received: from resqmta-ch2-06v.sys.comcast.net (resqmta-ch2-06v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0D1212B012 for ; Wed, 13 Jul 2016 10:01:25 -0700 (PDT) Received: from resomta-ch2-18v.sys.comcast.net ([69.252.207.114]) by resqmta-ch2-06v.sys.comcast.net with SMTP id NNWDbYcET2NhqNNXIb5LNB; Wed, 13 Jul 2016 17:01:24 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by comcast with SMTP id NNXHb5G4rjzO0NNXHbZV1t; Wed, 13 Jul 2016 17:01:24 +0000 To: sipcore@ietf.org References: <1EE2D149-1E1A-49DA-ACB8-625FEC4E4508@edvina.net> <76f2fd5e65bfa393281d682d23e18f11@mail.gmail.com> From: Paul Kyzivat Message-ID: <9a315748-dd93-0731-72a4-41637989a561@alum.mit.edu> Date: Wed, 13 Jul 2016 13:01:23 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfKUiqql7W40pOqj8tZAXqs+OikTXfxOi/SMsacfMaLGZHPIVsGbKPXFbIEIB9euAyAwLZCXWcjAr3E/X4m0joiJMdlQc4L2QYQKEbygZqyPAFWe/XUWk aCyab1/Co41RFAigrS1we2w4/jphiaRBoXTl40VPHPZgJ1Z17odUXFixAlVJ2fs5a+LhQPjommT8ng== Archived-At: Subject: Re: [sipcore] Declaring SIP 1.0 historic? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 17:01:26 -0000 On 7/13/16 10:57 AM, Olle E. Johansson wrote: > Realising I’ve been fooled by folklore I am still searching for version 1.0. Any pointers? I don't know about documents for it. But I bet Henning was involved. So he is where I would start. > If we have 2.0 according to 2543 and 2.0 according to 3261 it’s going to be hard to get > rid of 2543. > > I would have no problem hearing that story - why did we keep the 2.0 version in 3261 - while gently > SIPping a german beer in Berlin next week :-) I became involved just a bit before 3261. I don't recall, but I expect that it was because there were deployments of 2543 and there is no good way to be agile wrt version number. Thanks, Paul From nobody Wed Jul 13 10:41:42 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00C2812D162 for ; Wed, 13 Jul 2016 10:41:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=broadsoft-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FrmW0mPz9DCJ for ; Wed, 13 Jul 2016 10:41:39 -0700 (PDT) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0720B12D0A5 for ; Wed, 13 Jul 2016 10:41:38 -0700 (PDT) Received: by mail-qt0-x234.google.com with SMTP id u25so29721905qtb.1 for ; Wed, 13 Jul 2016 10:41:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadsoft-com.20150623.gappssmtp.com; s=20150623; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:content-transfer-encoding; bh=5xBlWa0t7GI6bFjXQMrzkP7lVSpvqtylb8Y2sumJxTk=; b=T8E3LoPnskqfU6vxd0qZl3Cv4Tg0oJD9wlpogxWZdRxxX3MkcqahppC9xa2m/yAyKs iors+wrEJxbwFWgKwRkNETdZ2ZOKSvnYcggS93/jP6IjZqQnmjDcUZ/iXiPyXpChm2po BPtiDQIdrC5euQr6yDfJGGlEpWTVMX7BylbkRgVSwW2zz5Zw2hrF/yP/J0+OzcvtNHx6 A3YzBa4NorFvDSuFt2FRy+M8MPlWrRFlpjuX6ckNnkfFO5MEQ5/F80EbW0at3IASMhv8 t5tUmFb+fuTuVBH2UqnFNmaj6AMFQCTpZByRAC9MP6HQ9MpvqKvKjlmemkGbw8bmRSRL IQFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:content-transfer-encoding; bh=5xBlWa0t7GI6bFjXQMrzkP7lVSpvqtylb8Y2sumJxTk=; b=dPbfZsxvZEQtU8lB+NZ/cAfvqMEBsyjMC7b4nDKwWv/Skap2OzPJfdri82peE+XL8R sUBBMyfOrDSAlvuMzm2uMvZH85P4UYKm8sCz3NJwXQV3nDwFU1iqUiDhypzMCHOa0Qbj gfmrkiCm3B5t9b61NaJGfKlZb86VzlEdVH7Xgs+83mFm2l9YZ5ymLzb0lWeoRqdzqPY/ wBP0DWPNIbNyTnGLiR57wLttNKS6I4HTCjDqoI7rK5hIOAO3JjG4hyvRNhwzCVbsPsON oyMQp0+hh2OBD2keE+gf161kFm2kWcnT2lWiL7Et0dXSvOQrezC4YXCg/oGy1f6Uccwe o/nA== X-Gm-Message-State: ALyK8tJ0PQgYxuj1cgZ0M4T6gz0g82ASn0S0z3rBqc1PoWs9NL6RqOm60POkn3mTbJNa3p/IyWn9a/C8/GmfsKCP X-Received: by 10.237.47.228 with SMTP id m91mr13203796qtd.35.1468431698116; Wed, 13 Jul 2016 10:41:38 -0700 (PDT) From: Brett Tate References: <1EE2D149-1E1A-49DA-ACB8-625FEC4E4508@edvina.net> <76f2fd5e65bfa393281d682d23e18f11@mail.gmail.com> <22406.24552.369096.256493@compute06.cs.columbia.edu> In-Reply-To: <22406.24552.369096.256493@compute06.cs.columbia.edu> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGhNHGVYLaedcNWJpc8nhZijnHPtwEeGLtZAUgxRo4BneXeZqBXu6Rg Date: Wed, 13 Jul 2016 13:41:37 -0400 Message-ID: <2a1fbfd6bc303aa7420632403e4910c7@mail.gmail.com> To: Jonathan Lennox , sipcore@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [sipcore] Declaring SIP 1.0 historic? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 17:41:41 -0000 > > Realising I=E2=80=99ve been fooled by folklore I am still > > searching for version 1.0. Any pointers? > > There never was a SIP/1.0. The 2.0 number was chosen to > make sure that SIP wouldn't be confused with HTTP/1.x on > the wire, and also in a vague (and it turned out, vain) > hope that it'd be possible to run SIP through HTTP proxies. Thanks for the information. I had assumed that there was a version 1.0 somewhere (for instance maybe based upon a Henning Schulzrinne document or RFC 2543 section F's acknowledgement of [37,38]). > > If we have 2.0 according to 2543 and 2.0 according to > > 3261 it=E2=80=99s going to be hard to get rid of 2543. > > It'd be possible to deprecate the old 2543-compatible > transaction matching and source routing. I don't know > how much of a gain that is for implementors, though. I don't think there is much gain concerning transaction matching or strict routing. The desire to deprecate occasionally arises concerning To and Fro= m URI mandates. For instance, RFC 3261 section 12.2.1.1 indicates an expectation that the "mandatory reflection of the original To and From URI in mid-dialog request= s will be deprecated in a subsequent revision". I'm not sure why; however some vendors and operators want to allow the To/From URI to change without any restrictions (e.g. they don't want to be restricted by RFC 4916). From nobody Wed Jul 13 10:42:38 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CBFF12D188 for ; Wed, 13 Jul 2016 10:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y1Y3d5kFlK4q for ; Wed, 13 Jul 2016 10:42:36 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26B9B12D16C for ; Wed, 13 Jul 2016 10:42:36 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u6DHgGZ3020951 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 13 Jul 2016 12:42:17 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local To: Jonathan Lennox , "Olle E. Johansson" References: <1EE2D149-1E1A-49DA-ACB8-625FEC4E4508@edvina.net> <76f2fd5e65bfa393281d682d23e18f11@mail.gmail.com> <22406.24552.369096.256493@compute06.cs.columbia.edu> From: Adam Roach Message-ID: Date: Wed, 13 Jul 2016 12:42:16 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <22406.24552.369096.256493@compute06.cs.columbia.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] Declaring SIP 1.0 historic? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 17:42:37 -0000 On 7/13/16 10:36, Jonathan Lennox wrote: > On Wednesday, July 13 2016, "Olle E. Johansson" wrote to "Brett Tate, sipcore@ietf.org, Olle E Johansson" saying: > >> Realising I’ve been fooled by folklore I am still searching for version 1.0. Any pointers? > There never was a SIP/1.0. That doesn't quite match my memory. I beleive there were early implementations of Handly/Schooler's SIP/1.0 spec in one or both of the UCL/Caltech labs. This was subsequently merged with Schulzrinne's Simple Conference Invitation Protocol (SCIP/1.0) , and the merged version was dubbed SIP/2.0. Poking around, this paper's introduction matches my personal recollection of the history: http://www.jocm.us/uploadfile/2013/0416/20130416114634804.pdf /a From nobody Wed Jul 13 12:10:11 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01C5912D52F for ; Wed, 13 Jul 2016 12:10:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mfwOueBIJ5Ua for ; Wed, 13 Jul 2016 12:10:04 -0700 (PDT) Received: from resqmta-ch2-12v.sys.comcast.net (resqmta-ch2-12v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:44]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8500E12B05C for ; Wed, 13 Jul 2016 12:10:04 -0700 (PDT) Received: from resomta-ch2-05v.sys.comcast.net ([69.252.207.101]) by resqmta-ch2-12v.sys.comcast.net with SMTP id NPXSbhtDsxBKTNPXnbGyQY; Wed, 13 Jul 2016 19:10:03 +0000 Received: from hobgoblin.ariadne.com ([73.143.237.82]) by comcast with SMTP id NPXmbOyB61VEaNPXnbTE4D; Wed, 13 Jul 2016 19:10:03 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u6DJA1Sd025157; Wed, 13 Jul 2016 15:10:02 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u6DJA1g8025142; Wed, 13 Jul 2016 15:10:01 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Paul Kyzivat In-Reply-To: <6ffed47b-e7ab-88db-0026-7c9a6e1aa52f@alum.mit.edu> (pkyzivat@alum.mit.edu) Sender: worley@ariadne.com (Dale R. Worley) Date: Wed, 13 Jul 2016 15:10:01 -0400 Message-ID: <87twftxsl2.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfKdtaK0ezeOWVEdPYXWHiRU5hJ9fLdK9iFP+oTiHbl2YUpw0QylTXrni7eWzKAFI8OLARoVJ7w4qAet7JGB1rUFRbzsVSauHVaOL7PSYR07GAzkgc8vF StFnlkD1MiXz8qIIM5hQGFyVfmLQhl5rcPdW64HiJ052EGUI3HeH+7pUl5VGnpUgmt5utxrNli8EG9Sa41HPe8F5vYrGJZi2+9g= Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] Happy Eyeballs: Outbounde X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 19:10:10 -0000 Paul Kyzivat writes: > I just looked back at my private archive. The discussions took place in > May and July of 2010 on the sipcore list. (I haven't looked for these in > the archives. These days I can get a URL into the archives from my copy > of a message, but not with ones from that far back.) > > I have attached a couple of messages as hooks into those discussions The messages with subject "Revised draft-jones-sip-options-ping-02.txt" are (currently) indexed on https://www.ietf.org/mail-archive/web/sipcore/current/thrd9.html The messages with subjects "draft-jones-sip-options-ping-01" and "The predictive value of OPTIONS" are indexed on https://www.ietf.org/mail-archive/web/sipcore/current/thrd9.html https://www.ietf.org/mail-archive/web/sipcore/current/thrd10.html Dale From nobody Wed Jul 13 12:16:33 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8412A12D53B for ; Wed, 13 Jul 2016 12:16:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Q-hSB_YgJ61 for ; Wed, 13 Jul 2016 12:16:30 -0700 (PDT) Received: from resqmta-ch2-03v.sys.comcast.net (resqmta-ch2-03v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E96E12B043 for ; Wed, 13 Jul 2016 12:16:30 -0700 (PDT) Received: from resomta-ch2-12v.sys.comcast.net ([69.252.207.108]) by resqmta-ch2-03v.sys.comcast.net with SMTP id NPdubjMKX8GkCNPe1biSil; Wed, 13 Jul 2016 19:16:29 +0000 Received: from hobgoblin.ariadne.com ([73.143.237.82]) by comcast with SMTP id NPe0btNsHvO5ANPe0b11t4; Wed, 13 Jul 2016 19:16:29 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u6DJGRPj025780; Wed, 13 Jul 2016 15:16:27 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u6DJGR5I025777; Wed, 13 Jul 2016 15:16:27 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Brett Tate In-Reply-To: <22b6b93d15568d356c511ff18cf81e3a@mail.gmail.com> (brett@broadsoft.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Wed, 13 Jul 2016 15:16:27 -0400 Message-ID: <87r3axxsac.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfLLZayx8hNlsBiHowcL2bfaeHEf2K7d1RCNiReq6h0RdLfAA+0PtqD/BIvj5t/cgKsjZmSb2fRKHfdfP/SQP/S3WYRVBJf5zKnWUDKtANf2jn84etv0N EPYnI7sob8fF229JdkOHk/QMMDeopNIcXkWcjC/9IrPjP7kyfj6vp8LikDbsl+XGqGCNtsGP5Ae/I1QEKNm4NgYmkzrDtXHGjLz73D187cmatx29vD+/V073 KelhBETKtqYeqMbwUkWFcw== Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] Happy Eyeballs: Outbounde X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 19:16:31 -0000 Brett Tate writes: >> I don't think using OPTIONS/NOTIFY v.s. REGISTER >> would change anything on this front. Roman probably >> refers more to the overall processing cost. > > Because refreshing a registration typically involves updating persistent > information, performing authentication, et cetera, the impacts a REGISTER > can be significantly higher than that of OPTIONS. This is the reason why > some vendors prefer receiving OPTIONS instead of REGISTER when sent > frequently as a workaround for NAT involvement. Also, knowledge of the expirations of the registrations must be maintained accurately, while a keepalive only has to be sent frequently enough. For instance, consider if the maximum keepalive interval is 60 secs, and the proxy sends an OPTIONS every 30 secs. The proxy needs to keep a database of keepalive timers. But if it goes down, the standby proxy doesn't need to know when each keepalive expires, it needs to send an OPTIONS to every target within the next 30 secs. Dale From nobody Wed Jul 13 12:26:38 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E4A112D52F for ; Wed, 13 Jul 2016 12:26:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k4I4c4VRq3Wy for ; Wed, 13 Jul 2016 12:26:36 -0700 (PDT) Received: from resqmta-ch2-07v.sys.comcast.net (resqmta-ch2-07v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5982312B05C for ; Wed, 13 Jul 2016 12:26:36 -0700 (PDT) Received: from resomta-ch2-19v.sys.comcast.net ([69.252.207.115]) by resqmta-ch2-07v.sys.comcast.net with SMTP id NPmebaJxaff8qNPnnbpgci; Wed, 13 Jul 2016 19:26:35 +0000 Received: from hobgoblin.ariadne.com ([73.143.237.82]) by comcast with SMTP id NPnlbh0wtL0bqNPnlbLADZ; Wed, 13 Jul 2016 19:26:35 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u6DJQWjq026819; Wed, 13 Jul 2016 15:26:32 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u6DJQV3c026803; Wed, 13 Jul 2016 15:26:31 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: "Olle E. Johansson" In-Reply-To: (oej@edvina.net) Sender: worley@ariadne.com (Dale R. Worley) Date: Wed, 13 Jul 2016 15:26:31 -0400 Message-ID: <87mvllxrtk.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfGL066dlyHjDN3TKWhcAUMCHKgClP/OcYSOhyUIfw8VfTm8VtubgVs3KWx41a2MIUX4yRvlWDsvh0+aSYcig3k2OdWOpUS1BPn8OZy/z4m50wMDgJihq WZG7p29JpaAEWP8P4IYKnuevaI3YuMLc6yDO7mvE7MDolyKhU9hPQiK9wIVQWcD5BHKDpPgiIkh4h6ZlPbIlbiZC3TN9PmffzTI= Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] Very rough draft for remaining Happy Eyeballs work X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 19:26:37 -0000 Starting to work on this message: "Olle E. Johansson" writes: > I don't understand why you let devices break the order implied by RFC > 3263. The order is well defined there. Do you mean that for a given > HOST you may contact the targets in any order (or preferred: > simultaneously). The idea is not only to allow devices to contact the targets in a different order, but to give devices guidance on the best order to contact targets. This is useful in at least the case where a particular target is known to be non-responsive; you want to postpone that target until after you've tried targets that aren't know to be non-responsive. And ideal system would be to be able to contact all targets simultaneously, but there's no general way to prevent that from creating multiple dialogs. Dale From nobody Wed Jul 13 12:50:36 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BAC212D0A4 for ; Wed, 13 Jul 2016 12:50:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TdPAiPR1-OXX for ; Wed, 13 Jul 2016 12:50:32 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-01.alcatel-lucent.com [135.245.18.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C53212D592 for ; Wed, 13 Jul 2016 12:50:32 -0700 (PDT) Received: from us70uumx3.dmz.alcatel-lucent.com (unknown [135.245.18.15]) by Websense Email Security Gateway with ESMTPS id E4976B0D684F4; Wed, 13 Jul 2016 19:50:28 +0000 (GMT) Received: from us70uusmtp3.zam.alcatel-lucent.com (us70uusmtp3.zam.alcatel-lucent.com [135.5.2.65]) by us70uumx3.dmz.alcatel-lucent.com (GMO) with ESMTP id u6DJoUXe009309 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 13 Jul 2016 19:50:30 GMT Received: from umail.lucent.com (umail.ndc.lucent.com [135.3.40.61]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id u6DJoTZx023097 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Jul 2016 19:50:30 GMT Received: from [135.185.238.141] (shoonya.ih.lucent.com [135.185.238.141]) by umail.lucent.com (8.13.8/TPES) with ESMTP id u6DJoTCa025704; Wed, 13 Jul 2016 14:50:29 -0500 (CDT) To: "Olle E. Johansson" , Brett Tate References: <1EE2D149-1E1A-49DA-ACB8-625FEC4E4508@edvina.net> <76f2fd5e65bfa393281d682d23e18f11@mail.gmail.com> From: "Vijay K. Gurbani" Message-ID: Date: Wed, 13 Jul 2016 14:50:29 -0500 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] Declaring SIP 1.0 historic? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 19:50:34 -0000 On 07/13/2016 09:57 AM, Olle E. Johansson wrote: > I started googling for version 1.0 and it seems half of the Internet > believes that 2543 is version 1.0. A brief history of SIP (including 1.0) is provided in [1]. The PDF for this paper is available for free download (open access) at [2]. Have fun spelunking the origin of SIP. [1] Salman Abdul Baset, Vijay K. Gurbani, Alan B. Johnston, Hadriel Kaplan, Brian Rosen and Jonathan D. Rosenberg , "The Session Initiation Protocol (SIP): An evolutionary study", In Journal of Communications (JCM), pp. 89-105, Vol. 7., No. 2, February 2012 [2] http://ojs.academypublisher.com/index.php/jcm/article/download/jcm070289105/4295 Cheers, - vijay -- Vijay K. Gurbani, Bell Laboratories, Nokia Networks 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@bell-labs.com / vijay.gurbani@nokia-bell-labs.com Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq From nobody Wed Jul 13 12:55:25 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8377B12D592 for ; Wed, 13 Jul 2016 12:55:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8NCKuxApIG6o for ; Wed, 13 Jul 2016 12:55:21 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DE4E12D0A4 for ; Wed, 13 Jul 2016 12:55:20 -0700 (PDT) Received: from [192.168.40.18] (h87-96-134-129.cust.se.alltele.net [87.96.134.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id 25D4942E3; Wed, 13 Jul 2016 21:55:17 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Olle E. Johansson" In-Reply-To: Date: Wed, 13 Jul 2016 21:55:16 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2DD3CC79-6A5C-49B1-AAE5-C4949F4D6F5D@edvina.net> References: <1EE2D149-1E1A-49DA-ACB8-625FEC4E4508@edvina.net> <76f2fd5e65bfa393281d682d23e18f11@mail.gmail.com> To: "Vijay K. Gurbani" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: sipcore@ietf.org, Olle E Johansson Subject: Re: [sipcore] Declaring SIP 1.0 historic? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 19:55:23 -0000 > On 13 Jul 2016, at 21:50, Vijay K. Gurbani wrote: >=20 > On 07/13/2016 09:57 AM, Olle E. Johansson wrote: >> I started googling for version 1.0 and it seems half of the Internet >> believes that 2543 is version 1.0. >=20 > A brief history of SIP (including 1.0) is provided in [1]. The PDF = for > this paper is available for free download (open access) at [2]. >=20 > Have fun spelunking the origin of SIP. >=20 > [1] Salman Abdul Baset, Vijay K. Gurbani, Alan B. Johnston, > Hadriel Kaplan, Brian Rosen and Jonathan D. Rosenberg , "The Session > Initiation Protocol (SIP): An evolutionary study", In Journal of > Communications (JCM), pp. 89-105, Vol. 7., No. 2, February 2012 >=20 > [2] = http://ojs.academypublisher.com/index.php/jcm/article/download/jcm07028910= 5/4295 Thank you to everyone that have been responding to my spelunking! I will read up on this. (And update my training materials). Always great to learn. /O= From nobody Wed Jul 13 12:57:49 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5976612D159 for ; Wed, 13 Jul 2016 12:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I8EuuxbmayZ5 for ; Wed, 13 Jul 2016 12:57:46 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28F4F12D0A4 for ; Wed, 13 Jul 2016 12:57:45 -0700 (PDT) Received: from [192.168.40.18] (h87-96-134-129.cust.se.alltele.net [87.96.134.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id A81F642E3; Wed, 13 Jul 2016 21:57:42 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Olle E. Johansson" In-Reply-To: <87mvllxrtk.fsf@hobgoblin.ariadne.com> Date: Wed, 13 Jul 2016 21:57:42 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0F061913-E766-49D3-BA16-4EA8685952DC@edvina.net> References: <87mvllxrtk.fsf@hobgoblin.ariadne.com> To: "Dale R. Worley" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: sipcore@ietf.org, Olle E Johansson Subject: Re: [sipcore] Very rough draft for remaining Happy Eyeballs work X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 19:57:47 -0000 > On 13 Jul 2016, at 21:26, Dale R. Worley wrote: >=20 > Starting to work on this message: >=20 > "Olle E. Johansson" writes: >> I don't understand why you let devices break the order implied by RFC >> 3263. The order is well defined there. Do you mean that for a given >> HOST you may contact the targets in any order (or preferred: >> simultaneously). >=20 > The idea is not only to allow devices to contact the targets in a > different order, but to give devices guidance on the best order to > contact targets. This is useful in at least the case where a = particular > target is known to be non-responsive; you want to postpone that target > until after you've tried targets that aren't know to be = non-responsive. Hmm. That makes sense, but is that not allowed in the RFCs?=20 (need to re-read, as always) >=20 > And ideal system would be to be able to contact all targets > simultaneously, but there's no general way to prevent that from = creating > multiple dialogs. You have to be clear here. THere=E2=80=99s no way to preven that from creating multiple dialogs in UDP. In TCP you can of course prevent multiple dialogs by not sending anything once a connection is open, just close it without any SIP message. /O= From nobody Wed Jul 13 13:00:02 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36BB012D1AC for ; Wed, 13 Jul 2016 13:00:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QjBhbuOoNmUL for ; Wed, 13 Jul 2016 13:00:00 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E738912D0A4 for ; Wed, 13 Jul 2016 12:59:59 -0700 (PDT) Received: from [192.168.40.18] (h87-96-134-129.cust.se.alltele.net [87.96.134.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id 02FB9428B; Wed, 13 Jul 2016 21:59:56 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Olle E. Johansson" In-Reply-To: <2a1fbfd6bc303aa7420632403e4910c7@mail.gmail.com> Date: Wed, 13 Jul 2016 21:59:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2042D098-4A81-4188-B232-4C357115BB71@edvina.net> References: <1EE2D149-1E1A-49DA-ACB8-625FEC4E4508@edvina.net> <76f2fd5e65bfa393281d682d23e18f11@mail.gmail.com> <22406.24552.369096.256493@compute06.cs.columbia.edu> <2a1fbfd6bc303aa7420632403e4910c7@mail.gmail.com> To: Brett Tate X-Mailer: Apple Mail (2.3124) Archived-At: Cc: sipcore@ietf.org, Olle E Johansson Subject: Re: [sipcore] Declaring SIP 1.0 historic? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 20:00:01 -0000 > On 13 Jul 2016, at 19:41, Brett Tate wrote: >=20 >>> Realising I=E2=80=99ve been fooled by folklore I am still >>> searching for version 1.0. Any pointers? >>=20 >> There never was a SIP/1.0. The 2.0 number was chosen to >> make sure that SIP wouldn't be confused with HTTP/1.x on >> the wire, and also in a vague (and it turned out, vain) >> hope that it'd be possible to run SIP through HTTP proxies. >=20 > Thanks for the information. I had assumed that there was a version = 1.0 > somewhere (for instance maybe based upon a Henning Schulzrinne = document or > RFC 2543 section F's acknowledgement of [37,38]). >=20 >=20 >>> If we have 2.0 according to 2543 and 2.0 according to >>> 3261 it=E2=80=99s going to be hard to get rid of 2543. >>=20 >> It'd be possible to deprecate the old 2543-compatible >> transaction matching and source routing. I don't know >> how much of a gain that is for implementors, though. >=20 > I don't think there is much gain concerning transaction matching or = strict > routing. The desire to deprecate occasionally arises concerning To = and From > URI mandates. >=20 > For instance, RFC 3261 section 12.2.1.1 indicates an expectation that = the > "mandatory reflection of the original To and =46rom URI in mid-dialog = requests > will be deprecated in a subsequent revision". I'm not sure why; = however > some vendors and operators want to allow the To/=46rom URI to change = without > any restrictions (e.g. they don't want to be restricted by RFC 4916). There are many call transfer scenarios involving b2bua=E2=80=99s that = need to modify/update caller IDs and there are too many implementations pre-4916 out there. /O= From nobody Wed Jul 13 13:12:26 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF18A12D7B4 for ; Wed, 13 Jul 2016 13:12:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-hDwZEQvbVC for ; Wed, 13 Jul 2016 13:12:22 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-01.alcatel-lucent.com [135.245.18.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A19CA12D7B5 for ; Wed, 13 Jul 2016 13:12:22 -0700 (PDT) Received: from us70tumx1.dmz.alcatel-lucent.com (unknown [135.245.18.13]) by Websense Email Security Gateway with ESMTPS id 9CA6321B66805; Wed, 13 Jul 2016 20:12:14 +0000 (GMT) Received: from us70tusmtp1.zam.alcatel-lucent.com (us70tusmtp1.zam.alcatel-lucent.com [135.5.2.63]) by us70tumx1.dmz.alcatel-lucent.com (GMO) with ESMTP id u6DKCIEe015059 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 13 Jul 2016 20:12:18 GMT Received: from umail.lucent.com (umail.ndc.lucent.com [135.3.40.61]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id u6DKCHQk013137 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Jul 2016 20:12:17 GMT Received: from [135.185.238.141] (shoonya.ih.lucent.com [135.185.238.141]) by umail.lucent.com (8.13.8/TPES) with ESMTP id u6DKCF6H009212; Wed, 13 Jul 2016 15:12:15 -0500 (CDT) To: Jonathan Lennox , "Olle E. Johansson" References: <1EE2D149-1E1A-49DA-ACB8-625FEC4E4508@edvina.net> <76f2fd5e65bfa393281d682d23e18f11@mail.gmail.com> <22406.24552.369096.256493@compute06.cs.columbia.edu> From: "Vijay K. Gurbani" Message-ID: Date: Wed, 13 Jul 2016 15:12:15 -0500 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <22406.24552.369096.256493@compute06.cs.columbia.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] Declaring SIP 1.0 historic? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 20:12:25 -0000 On 07/13/2016 10:36 AM, Jonathan Lennox wrote: >> I would have no problem hearing that story - why did we keep the >> 2.0 version in 3261 - while gently SIPping a german beer in Berlin >> next week :-) > > We kept it because SIP routing rules (notably forking) mean that > there's no good way to try to send a request with a newer version, > and then if it fails, fall back to an older version. This is why all > backward compatibility in SIP has to be single-pass. Right, that matches my recollection as well. When we were designing what eventually became rfc3261, a prime directive was do no harm and be backwardly compatible. Because rfc2543 was deployed and being used, a forklift upgrade by changing the protocol version was not looked at kindly. Almost a decade ago, a brief email exchange surfaced to entertain the idea of a SIP/3.0 [1]. It was ignominiously short lived :-) [1] https://www.ietf.org/mail-archive/web/sip/current/thrd19.html#18421 Cheers, - vijay -- Vijay K. Gurbani, Bell Laboratories, Nokia Networks 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@bell-labs.com / vijay.gurbani@nokia-bell-labs.com Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq From nobody Wed Jul 13 13:28:13 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87D5F12D559 for ; Wed, 13 Jul 2016 13:28:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g0ZU0ms6HYNV for ; Wed, 13 Jul 2016 13:28:10 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EF8812D556 for ; Wed, 13 Jul 2016 13:28:09 -0700 (PDT) Received: from [192.168.40.18] (h87-96-134-129.cust.se.alltele.net [87.96.134.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id 32321428B; Wed, 13 Jul 2016 22:28:06 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Olle E. Johansson" In-Reply-To: Date: Wed, 13 Jul 2016 22:28:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7D55514D-4E15-4E2A-BEE1-4511B97E0665@edvina.net> References: <1EE2D149-1E1A-49DA-ACB8-625FEC4E4508@edvina.net> <76f2fd5e65bfa393281d682d23e18f11@mail.gmail.com> <22406.24552.369096.256493@compute06.cs.columbia.edu> To: "Vijay K. Gurbani" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: sipcore@ietf.org, Olle E Johansson Subject: Re: [sipcore] Declaring SIP 1.0 historic? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 20:28:12 -0000 > On 13 Jul 2016, at 22:12, Vijay K. Gurbani wrote: >=20 > On 07/13/2016 10:36 AM, Jonathan Lennox wrote: >>> I would have no problem hearing that story - why did we keep the >>> 2.0 version in 3261 - while gently SIPping a german beer in Berlin >>> next week :-) >>=20 >> We kept it because SIP routing rules (notably forking) mean that >> there's no good way to try to send a request with a newer version, >> and then if it fails, fall back to an older version. This is why all >> backward compatibility in SIP has to be single-pass. >=20 > Right, that matches my recollection as well. When we were designing > what eventually became rfc3261, a prime directive was do no harm and > be backwardly compatible. Because rfc2543 was deployed and being = used, > a forklift upgrade by changing the protocol version was not looked at > kindly. >=20 > Almost a decade ago, a brief email exchange surfaced to entertain the > idea of a SIP/3.0 [1]. It was ignominiously short lived :-) >=20 > [1] = https://www.ietf.org/mail-archive/web/sip/current/thrd19.html#18421 Just love this quote by Dale Worley: "SIP 3.0 is like fully participatory democracy, the ultimate form of communism, and the earthly Kingdom of God -- a thorough reform of what presently exists that will remove all of its flaws. Similar to those other three projects, there is no WG timeline yet for SIP 3.0 development.=E2=80=9D Let=E2=80=99s start SIP 4.0 :-) /O= From nobody Wed Jul 13 13:44:58 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E3F512B05F for ; Wed, 13 Jul 2016 13:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C2oeic1m_U-f for ; Wed, 13 Jul 2016 13:44:55 -0700 (PDT) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B78CB12B037 for ; Wed, 13 Jul 2016 13:44:54 -0700 (PDT) Received: by mail-it0-x22f.google.com with SMTP id h190so54780537ith.1 for ; Wed, 13 Jul 2016 13:44:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=unL9XIuxV+CZMuGdueyUZ4P8Gtx81aU28PXeMb7kTCo=; b=RreGiVyFAuMXAlSnH/4KxIxPzyfcSkaPpINqSjiLgF+yHpkIB8o350CmfB3d7hBFYh uQJsAdq79cqQfhFHnx6BYfv5ioYudRU88H4TrwVveOBNq4LYG7KCEVA9XKw798JLhq4l FS5+BNkoJuGmAdA+ple61Krz+w/3uYI3gxSScYrlwRn7AUcRKf7cqGcVc5Tk6egLEkNf FJVHp4zoql5mhiHbv+/mHJN1p/ZOJMVugN14haAp/1MrhXmY012CA+1vZvdyLVzphuS4 13UQIJ8i71VqpmR6I5oF0qrFYV92AE2hz2PBQmkKiEMyvX/EZhdMbtWBsC/Jvo9lvhn/ LiLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=unL9XIuxV+CZMuGdueyUZ4P8Gtx81aU28PXeMb7kTCo=; b=cFrzyK6lkPY9KbowdWdcMbelCg4cZoZZMBwf+pWfKqyjYBpvw4aGRuNWWP8eDviziA eZnVDjJlyWil0Ujkh5rU8HfqiPca226IQcN0qbM+98QwZ93Xy9p37cGnuY/DmUtF+Os7 ZSDB5f1wT5dNwYj+sK5Ywc1oiDxUSfrSv7xoPyXrjUews4VHcRZnzErRaqEk5iOM+ScL bl/dvz5QG8jfvUy82sKf4OkSr+8OLWuegbO55gWeJXbyhdzqOothpmdf1WSZLYCASdr8 0Es45huQBDSCAOzwYsVh8sDvstxxEUMPkbPRE4xsNpvblk/iaDML8EZHJ45WU4BvRHSJ MtXA== X-Gm-Message-State: ALyK8tLZJO+cD8hToGWAmtrEGYOZDkHyXnFqAL9pFfpAFXHt5vGQZk659+oO7ijeLlqSvg== X-Received: by 10.36.123.216 with SMTP id q207mr23046352itc.17.1468442693956; Wed, 13 Jul 2016 13:44:53 -0700 (PDT) Received: from mail-io0-f180.google.com (mail-io0-f180.google.com. [209.85.223.180]) by smtp.gmail.com with ESMTPSA id d189sm917551iod.3.2016.07.13.13.44.53 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Jul 2016 13:44:53 -0700 (PDT) Received: by mail-io0-f180.google.com with SMTP id 38so57665545iol.0 for ; Wed, 13 Jul 2016 13:44:53 -0700 (PDT) X-Received: by 10.107.130.31 with SMTP id e31mr10572518iod.66.1468442693190; Wed, 13 Jul 2016 13:44:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.62.139 with HTTP; Wed, 13 Jul 2016 13:44:52 -0700 (PDT) In-Reply-To: <8760sia0vv.fsf@hobgoblin.ariadne.com> References: <8760sia0vv.fsf@hobgoblin.ariadne.com> From: Roman Shpount Date: Wed, 13 Jul 2016 16:44:52 -0400 X-Gmail-Original-Message-ID: Message-ID: To: "Dale R. Worley" Content-Type: multipart/alternative; boundary=001a113ed0d019d8b405378a7589 Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] Happy Eyeballs: Outbounde X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 20:44:57 -0000 --001a113ed0d019d8b405378a7589 Content-Type: text/plain; charset=UTF-8 On Wed, Jul 6, 2016 at 5:54 PM, Dale R. Worley wrote: > Thanks for the information! I've added your discussion to the rough > draft. > > Roman Shpount writes: > > Few observations: > > [...] > > 3. For server, the most efficient way to keep the NAT hole open is to > send > > OPTIONS or NOTIFY requests to the client. This is much more efficient > then > > registrations with small timeouts. > > > > 4. Registration server which has an in-memory database for current > > registrations can be fairly efficient in reducing number of back-end DB > > updates due to registrations and subscriptions with small timeouts. It is > > not going to be stateless, but its state does not need to be replicated > and > > would automatically recover on the stand-by server on the next > registration > > or subscription request from the client. > > I think what you are saying here is that if the server sends > OPTIONS/NOTIFY for keepalive, rather than making the client send > frequent re-REGISTERS, then the server doesn't need to record the timers > for the keepalives in persistent storage -- if the stand-by server is > activated, it simply sends keepalives to all registrations that are > recorded as having keepalive service. In the long run, this requires no > more processing by the registration server and far less demand on the > persistent storage. > > Is that correct? > This is correct. Since OPTIONS/NOTIFY do not update the registration state they typically require less resources then forcing the client to re-register at the small interval. Registrations typically require authentication and cause the shared storage update for the expiration time. OPTIONS/NOTIFY sent from server require not of this. > > > 5. One of the big problems with encrypted SIP traffic is that it gets > > modified by ALG. For a lot of hosted PBX providers avoiding the need to > > troubleshoot customer routers is a bigger incentive to deploy TLS then > user > > privacy. > > If I understand you correctly, hosted PBX providers favor TLS to stop > routers from modifying SIP messages. But ALGs terminate TLS ... and > then modify the SIP messages. > > One of the big problems with deploying SIP on customer premises are SIP ALG implemented by the consumer routers. Such ALG are typically broken and cause SIP call setup failures or call drops. If client equipment is using SIP over TLS, SIP ALG in routers cannot affect the signaling and SIP message pass the router unmolested. Because of this, SIP calls over TLS are much more stable which results in big reduction of customer problems and associated support calls. This reduction in support burden is a much bigger incentive for service providers to deploy encryption for SIP then customer privacy (which, in practice, is almost never their concern). _____________ Roman Shpount --001a113ed0d019d8b405378a7589 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wed, Jul 6, 2016 at 5:54 PM,= Dale R. Worley <worley@ariadne.com> wrote:
=
roman@telurix.com> writes:
> Few observations:
> [...]
> 3. For server, the most efficient way to keep the NAT= hole open is to send
> OPTIONS or NOTIFY requests to the client. This is much more efficient = then
> registrations with small timeouts.
>
> 4. Registration server which has an in-memory database for current
> registrations can be fairly efficient in reducing number of back-end D= B
> updates due to registrations and subscriptions with small timeouts. It= is
> not going to be stateless, but its state does not need to be replicate= d and
> would automatically recover on the stand-by server on the next registr= ation
> or subscription request from the client.

I think what you are saying here is that if the server sends
OPTIONS/NOTIFY for keepalive, rather than making the client send
frequent re-REGISTERS, then the server doesn't need to record the timer= s
for the keepalives in persistent storage -- if the stand-by server is
activated, it simply sends keepalives to all registrations that are
recorded as having keepalive service.=C2=A0 In the long run, this requires = no
more processing by the registration server and far less demand on the
persistent storage.

Is that correct?

This is correct. Since= OPTIONS/NOTIFY do not update the registration state they typically require= less resources then forcing the client to re-register at the small interva= l. Registrations typically require authentication and cause the shared stor= age update for the expiration time. OPTIONS/NOTIFY sent from server require= not of this.

> 5. One of the big problems with encrypted SIP traffic is that it gets<= br> > modified by ALG. For a lot of hosted PBX providers avoiding the need t= o
> troubleshoot customer routers is a bigger incentive to deploy TLS then= user
> privacy.

If I understand you correctly, hosted PBX providers favor TLS to sto= p
routers from modifying SIP messages.=C2=A0 But ALGs terminate TLS ... and then modify the SIP messages.


One of the big problems with deploying SIP on customer pre= mises are SIP ALG implemented by the consumer routers. Such ALG are typical= ly broken and cause SIP call setup failures or call drops. If client equipm= ent is using SIP over TLS, SIP ALG in routers cannot affect the signaling a= nd SIP message pass the router unmolested. Because of this, SIP calls over = TLS are much more stable which results in big reduction of customer problem= s and associated support calls. This reduction in support burden is a much = bigger incentive for service providers to deploy encryption for SIP then cu= stomer privacy (which, in practice, is almost never their concern).=C2=A0
= _____________
Roman Shpount
=C2=A0
--001a113ed0d019d8b405378a7589-- From nobody Wed Jul 13 13:47:16 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A9EC12D834 for ; Wed, 13 Jul 2016 13:47:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Kb3FLe_hu6e for ; Wed, 13 Jul 2016 13:47:14 -0700 (PDT) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51B8E12D5F8 for ; Wed, 13 Jul 2016 13:47:14 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id f6so30954103ith.1 for ; Wed, 13 Jul 2016 13:47:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=h4x3MfO6TYA52zc8hs7f/031MitZqD/9IuCalSD+Ulg=; b=oXbSV/Sab1F4H7mNJLtMqd9CytVG+e9295HP/UVNBjx6l/PdO64dJQg5EfcT7UiuiJ ySYOhQIwEl8f3sX2Rf0UW83pF3EI9D+gehH6V5ubeHZRLzX4AHMJa8hzK9UVRtvu9JjV abrQ9MW5iMzBIgoBVm4EOBmNnwlVGQZguqwUfL05mbrX5u7ennsiqFYQHU8s3akzjHS3 1kXZIn+uRcagXuX43BQYGljUcTj3La4VuL5ubIvm3MhvH8WEb+hTS0amwBHs+xG5LIdB 9H2RjzZE6v4TX3isuGbIr3RHxZ00XFzHN8ZpMQ+33zNOECdkgdTR2y+J3Rf0ouWWvIRg gb3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=h4x3MfO6TYA52zc8hs7f/031MitZqD/9IuCalSD+Ulg=; b=X7EAbut1OFbo7rA+r+mCrgnaoxQMmQep8Qb97wWc2X6WOALy3widlzQ3RVFImFtKBq knN6tCTMzU0nEzya9gfmASe6NjeLqjU4X9Q2Hd3s5E9tTV+um8dmFiJznuLO4C5fxl4R Vz1Mhs0TTluxR8zNIgSybvVv7JO+TJ748KRrgF97goTHja1e0QXG+fGazX45CKpHyyeE 9DjFjJct0CxrdEIM1No0eGNuArT9VfI1ZkGoj13jVmu5QDqojzgYvbcCqTjJ12orfP8b 8rqmjPlkNPqZPV+CjjUkt33+n2aTdaaQsYV+GHwt3ENva137Z98QRzJaEZ5+H76RN+sl 9iDg== X-Gm-Message-State: ALyK8tJyv4OsmCnEtbSqKGoVEwaau4DlhzeegJBklu56xbRk8hof5rPbMAVhOMlvh6YyAQ== X-Received: by 10.36.16.197 with SMTP id 188mr11268488ity.88.1468442833640; Wed, 13 Jul 2016 13:47:13 -0700 (PDT) Received: from mail-io0-f179.google.com (mail-io0-f179.google.com. [209.85.223.179]) by smtp.gmail.com with ESMTPSA id y194sm3104225iod.17.2016.07.13.13.47.13 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Jul 2016 13:47:13 -0700 (PDT) Received: by mail-io0-f179.google.com with SMTP id 38so57719014iol.0 for ; Wed, 13 Jul 2016 13:47:13 -0700 (PDT) X-Received: by 10.107.12.34 with SMTP id w34mr8841147ioi.171.1468442832783; Wed, 13 Jul 2016 13:47:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.62.139 with HTTP; Wed, 13 Jul 2016 13:47:12 -0700 (PDT) In-Reply-To: References: <8760sia0vv.fsf@hobgoblin.ariadne.com> From: Roman Shpount Date: Wed, 13 Jul 2016 16:47:12 -0400 X-Gmail-Original-Message-ID: Message-ID: To: "Asveren, Tolga" Content-Type: multipart/alternative; boundary=001a113f7e1c6bcf9805378a7d27 Archived-At: Cc: "Dale R. Worley" , "sipcore@ietf.org" Subject: Re: [sipcore] Happy Eyeballs: Outbounde X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 20:47:15 -0000 --001a113f7e1c6bcf9805378a7d27 Content-Type: text/plain; charset=UTF-8 On Wed, Jul 6, 2016 at 6:01 PM, Asveren, Tolga wrote: > > then the server doesn't need to record the timers for the keepalives in > > persistent storage > I don't think using OPTIONS/NOTIFY v.s. REGISTER would change anything on > this front. Roman probably refers more to the overall processing cost. > > There is processing cost since OPTIONS/NOTIFY typically are not authenticated. There is state storage cost, since registration state typically needs to be stored in some sort of shared storage and recovered in case of proxy failure. OPTIONS/NOTIFY can be send and processed based on in-memory state and do not need to be recovered. Regards, _____________ Roman Shpount --001a113f7e1c6bcf9805378a7d27 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Jul 6, 2016 at 6:01 PM, Asv= eren, Tolga <tasveren@sonusnet.com> wrote:
> then the server doesn't need to record the ti= mers for the keepalives in
> persistent storage
I don't think using OPTIONS/NOTIFY v.s. REGISTER would change an= ything on this front. Roman probably refers more to the overall processing = cost.


There is processing cost sinc= e OPTIONS/NOTIFY typically are not authenticated. There is state storage co= st, since registration state typically needs to be stored in some sort of s= hared storage and recovered in case of proxy failure. OPTIONS/NOTIFY can be= send and processed based on in-memory state and do not need to be recovere= d.

Regards,
_____________
Roman Shpount
<= /div>
=C2=A0

--001a113f7e1c6bcf9805378a7d27-- From nobody Wed Jul 13 13:53:59 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D54B12D888 for ; Wed, 13 Jul 2016 13:53:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n-1aDkLlaiAQ for ; Wed, 13 Jul 2016 13:53:55 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3ABC812D885 for ; Wed, 13 Jul 2016 13:53:54 -0700 (PDT) X-AuditID: c1b4fb30-f79486d0000069d0-fb-5786aa607928 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 08.DE.27088.06AA6875; Wed, 13 Jul 2016 22:53:53 +0200 (CEST) Received: from ESESSMB208.ericsson.se ([169.254.8.19]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0294.000; Wed, 13 Jul 2016 22:53:52 +0200 From: Christer Holmberg To: Roman Shpount , "Asveren, Tolga" Thread-Topic: [sipcore] Happy Eyeballs: Outbounde Thread-Index: AQHR19FKDNW4SmEaHk2is1leOoM+uqAL0quAgArroQCAACJhgA== Date: Wed, 13 Jul 2016 20:53:52 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B476A7D69@ESESSMB208.ericsson.se> References: <8760sia0vv.fsf@hobgoblin.ariadne.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B476A7D69ESESSMB208erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrAIsWRmVeSWpSXmKPExsUyM2K7qG7iqrZwg3UNPBYzLkxltvj6YxOb xezO90wWL0+UObB4TN7/ldljyZKfTB6XPv9n97g1pSCAJYrLJiU1J7MstUjfLoEro+vjR6aC Oz4Vy37VNTCe8epi5OSQEDCR2LvyDQuELSZx4d56ti5GLg4hgSOMEguWf2SFcBYzSrT9/cXc xcjBwSZgIdH9TxvEFBEIlDj7qwikl1kgSKL58wpGEFtYwEBi2YRdYDNFBAwlrrcsZ4KwnSSu z14CZrMIqEpsv7mfDcTmFfCV6Du0gR1i1XQmiQ3NE9hBEpxA8+ceWgRWxAh03PdTa5gglolL 3HoynwniaAGJJXvOM0PYohIvH/9jhbCVJFZsv8QIUZ8vMXd9PyvEMkGJkzOfsExgFJ2FZNQs JGWzkJTNAnqTWUBTYv0ufYgSRYkp3Q/ZIWwNidY5c9mRxRcwsq9iFC1OLU7KTTcy0kstykwu Ls7P08tLLdnECIzHg1t+G+xgfPnc8RCjAAejEg/vgsa2cCHWxLLiytxDjBIczEoivGYrgUK8 KYmVValF+fFFpTmpxYcYpTlYlMR5/V8qhgsJpCeWpGanphakFsFkmTg4pRoYA49123O22rF0 Tc5geN32zlnjufiM7oV/Zqz9cPF222nRAH5Lw7pJf7Prrjt+mLBCtPm79uPyreZvdd4c1vxu uyrtpBxb/JHc9pyLjZXv/mbEMtVvFfqSabFy1RbmnTtnuAk3vCpZ8PS6hc5zReb6tG8x/k0W 816YyHw9azhhbsnR73Oa/k44qMRSnJFoqMVcVJwIANgqVyLDAgAA Archived-At: Cc: "Dale R. Worley" , "sipcore@ietf.org" Subject: Re: [sipcore] Happy Eyeballs: Outbounde X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 20:53:57 -0000 --_000_7594FB04B1934943A5C02806D1A2204B476A7D69ESESSMB208erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNClJFR0lTVEVSIHJlcXVlc3RzIHVzZWQgZm9yIGtlZXAtYWxpdmUgYXJlIG5vdCBhbHdh eXMgYXV0aGVudGljYXRlZCwgYmVjYXVzZSB0aGV5IGFyZSBub3QgYWx3YXlzIGZvcndhcmRlZCB0 byB0aGUgcmVnaXN0cmFyIHRvIGJlZ2luIHdpdGguIFRoZXkgYXJlIHRlcm1pbmF0ZWQgYnkgYW4g ZWRnZS9vdXRib3VuZCBwcm94eS4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQoNCkZyb206 IHNpcGNvcmUgW21haWx0bzpzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBS b21hbiBTaHBvdW50DQpTZW50OiAxMyBKdWx5IDIwMTYgMjM6NDcNClRvOiBBc3ZlcmVuLCBUb2xn YSA8dGFzdmVyZW5Ac29udXNuZXQuY29tPg0KQ2M6IERhbGUgUi4gV29ybGV5IDx3b3JsZXlAYXJp YWRuZS5jb20+OyBzaXBjb3JlQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3NpcGNvcmVdIEhhcHB5 IEV5ZWJhbGxzOiBPdXRib3VuZGUNCg0KT24gV2VkLCBKdWwgNiwgMjAxNiBhdCA2OjAxIFBNLCBB c3ZlcmVuLCBUb2xnYSA8dGFzdmVyZW5Ac29udXNuZXQuY29tPG1haWx0bzp0YXN2ZXJlbkBzb251 c25ldC5jb20+PiB3cm90ZToNCj4gdGhlbiB0aGUgc2VydmVyIGRvZXNuJ3QgbmVlZCB0byByZWNv cmQgdGhlIHRpbWVycyBmb3IgdGhlIGtlZXBhbGl2ZXMgaW4NCj4gcGVyc2lzdGVudCBzdG9yYWdl DQpJIGRvbid0IHRoaW5rIHVzaW5nIE9QVElPTlMvTk9USUZZIHYucy4gUkVHSVNURVIgd291bGQg Y2hhbmdlIGFueXRoaW5nIG9uIHRoaXMgZnJvbnQuIFJvbWFuIHByb2JhYmx5IHJlZmVycyBtb3Jl IHRvIHRoZSBvdmVyYWxsIHByb2Nlc3NpbmcgY29zdC4NCg0KVGhlcmUgaXMgcHJvY2Vzc2luZyBj b3N0IHNpbmNlIE9QVElPTlMvTk9USUZZIHR5cGljYWxseSBhcmUgbm90IGF1dGhlbnRpY2F0ZWQu IFRoZXJlIGlzIHN0YXRlIHN0b3JhZ2UgY29zdCwgc2luY2UgcmVnaXN0cmF0aW9uIHN0YXRlIHR5 cGljYWxseSBuZWVkcyB0byBiZSBzdG9yZWQgaW4gc29tZSBzb3J0IG9mIHNoYXJlZCBzdG9yYWdl IGFuZCByZWNvdmVyZWQgaW4gY2FzZSBvZiBwcm94eSBmYWlsdXJlLiBPUFRJT05TL05PVElGWSBj YW4gYmUgc2VuZCBhbmQgcHJvY2Vzc2VkIGJhc2VkIG9uIGluLW1lbW9yeSBzdGF0ZSBhbmQgZG8g bm90IG5lZWQgdG8gYmUgcmVjb3ZlcmVkLg0KDQpSZWdhcmRzLA0KX19fX19fX19fX19fXw0KUm9t YW4gU2hwb3VudA0KDQoNCg== --_000_7594FB04B1934943A5C02806D1A2204B476A7D69ESESSMB208erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0 IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj5SRUdJU1RFUiByZXF1ZXN0cyB1c2VkIGZvciBrZWVwLWFsaXZlIGFy ZSBub3QgYWx3YXlzIGF1dGhlbnRpY2F0ZWQsIGJlY2F1c2UgdGhleSBhcmUgbm90IGFsd2F5cyBm b3J3YXJkZWQgdG8gdGhlIHJlZ2lzdHJhciB0byBiZWdpbg0KIHdpdGguIFRoZXkgYXJlIHRlcm1p bmF0ZWQgYnkgYW4gZWRnZS9vdXRib3VuZCBwcm94eS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj5DaHJpc3RlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFt ZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206 PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gc2lwY29yZSBbbWFpbHRv OnNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+Um9tYW4gU2hw b3VudDxicj4NCjxiPlNlbnQ6PC9iPiAxMyBKdWx5IDIwMTYgMjM6NDc8YnI+DQo8Yj5Ubzo8L2I+ IEFzdmVyZW4sIFRvbGdhICZsdDt0YXN2ZXJlbkBzb251c25ldC5jb20mZ3Q7PGJyPg0KPGI+Q2M6 PC9iPiBEYWxlIFIuIFdvcmxleSAmbHQ7d29ybGV5QGFyaWFkbmUuY29tJmd0Ozsgc2lwY29yZUBp ZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3NpcGNvcmVdIEhhcHB5IEV5ZWJhbGxz OiBPdXRib3VuZGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5PbiBXZWQsIEp1bCA2LCAyMDE2IGF0IDY6MDEgUE0sIEFzdmVyZW4sIFRv bGdhICZsdDs8YSBocmVmPSJtYWlsdG86dGFzdmVyZW5Ac29udXNuZXQuY29tIiB0YXJnZXQ9Il9i bGFuayI+dGFzdmVyZW5Ac29udXNuZXQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPiZndDsgdGhlbiB0aGUgc2VydmVyIGRvZXNu J3QgbmVlZCB0byByZWNvcmQgdGhlIHRpbWVycyBmb3IgdGhlIGtlZXBhbGl2ZXMgaW48YnI+DQom Z3Q7IHBlcnNpc3RlbnQgc3RvcmFnZTxicj4NCkkgZG9uJ3QgdGhpbmsgdXNpbmcgT1BUSU9OUy9O T1RJRlkgdi5zLiBSRUdJU1RFUiB3b3VsZCBjaGFuZ2UgYW55dGhpbmcgb24gdGhpcyBmcm9udC4g Um9tYW4gcHJvYmFibHkgcmVmZXJzIG1vcmUgdG8gdGhlIG92ZXJhbGwgcHJvY2Vzc2luZyBjb3N0 LjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+VGhlcmUgaXMgcHJvY2Vzc2luZyBjb3N0IHNpbmNlIE9QVElPTlMvTk9USUZZIHR5cGlj YWxseSBhcmUgbm90IGF1dGhlbnRpY2F0ZWQuIFRoZXJlIGlzIHN0YXRlIHN0b3JhZ2UgY29zdCwg c2luY2UgcmVnaXN0cmF0aW9uIHN0YXRlIHR5cGljYWxseSBuZWVkcyB0byBiZSBzdG9yZWQgaW4g c29tZSBzb3J0IG9mIHNoYXJlZCBzdG9yYWdlIGFuZCByZWNvdmVyZWQgaW4gY2FzZSBvZiBwcm94 eSBmYWlsdXJlLiBPUFRJT05TL05PVElGWQ0KIGNhbiBiZSBzZW5kIGFuZCBwcm9jZXNzZWQgYmFz ZWQgb24gaW4tbWVtb3J5IHN0YXRlIGFuZCBkbyBub3QgbmVlZCB0byBiZSByZWNvdmVyZWQuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlZ2Fy ZHMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+X19fX19fX19fX19fXzxicj4NClJvbWFuIFNocG91bnQ8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7594FB04B1934943A5C02806D1A2204B476A7D69ESESSMB208erics_-- From nobody Wed Jul 13 14:00:41 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E34B12D626 for ; Wed, 13 Jul 2016 14:00:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V1K3voC1SH14 for ; Wed, 13 Jul 2016 14:00:39 -0700 (PDT) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13E9612D0FD for ; Wed, 13 Jul 2016 14:00:39 -0700 (PDT) Received: by mail-io0-x234.google.com with SMTP id q83so58197704iod.1 for ; Wed, 13 Jul 2016 14:00:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=J2bxNdU4opaILfomkDdYq1gl4BY5mMpSbqoNs8bduLk=; b=bMFlmjpaxnC/5TBcND1MmeLDwphyJdprZFFuZ2Yki1A8nD5ak5TvoJqTYEsMKqI3Yg dlkixrJp1EH2/yUJ/DywPqnDQxJTlD3cYs1Q3GJggYXB4tGEs5oC5fLfgmPF+YFdnCJN HK30gGsqCE2IQnmsqaFhJxR18IjRHeJ7u5BhmO0y2x5rX+2GXrADljF+9qQ6zp0e6s58 OphbEWbnAOLf+hDSaQz26M8PZaTrR/3lkpNhVt0lHVY03RaoVtBsNzXOSAtI73R5J9IZ a/Rp35wGQ3VMYIG0TqdogMMC0uuH2Vyu6niGFAwCNJuNdHcziTE/RRzaMVs8Nmlxao/A cKFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=J2bxNdU4opaILfomkDdYq1gl4BY5mMpSbqoNs8bduLk=; b=Wpd7jg54nrjFmkdZ0YjyzpfWzm3K9m3lae1xGGiPmo2k1LVTUiuDveTsdbV93cjQbB SAnAxJgSItAov2qgTKXKagbc/yf6r+FjsyDya7tSaTy4wTjzWaK117eyhaVNIR+awh/V DPiRfxRBkchlXS3Jz1okPzdVexyJ3DZQNJv99TNU8oY8ICBjODbfhoYEq/b3fzeIQmwT Xx1ciaExijZ2/nBwC0kQfiZzAIweiYdWtEcZrsdVNTiqM6n1WbXS08AZKuzbg/tCtrsy T0eHNv9hOFZWWqSd3ISsJIaCCqM+m7xMUx5qkx5tx3Ta5hNmPaBcrTo2lTcRLmNTlyhT VF5g== X-Gm-Message-State: ALyK8tLZXxqC0HICXXRuBNztejseiUOgMCiTJr/4EzNKTJ+QHOqOvoeNxD9kP9EIwD/isA== X-Received: by 10.107.8.140 with SMTP id h12mr11303863ioi.95.1468443638287; Wed, 13 Jul 2016 14:00:38 -0700 (PDT) Received: from mail-it0-f46.google.com (mail-it0-f46.google.com. [209.85.214.46]) by smtp.gmail.com with ESMTPSA id c71sm1348249itc.18.2016.07.13.14.00.37 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Jul 2016 14:00:37 -0700 (PDT) Received: by mail-it0-f46.google.com with SMTP id f6so31237440ith.1 for ; Wed, 13 Jul 2016 14:00:37 -0700 (PDT) X-Received: by 10.36.184.135 with SMTP id m129mr11388926ite.95.1468443637281; Wed, 13 Jul 2016 14:00:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.62.139 with HTTP; Wed, 13 Jul 2016 14:00:36 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B476A7D69@ESESSMB208.ericsson.se> References: <8760sia0vv.fsf@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B476A7D69@ESESSMB208.ericsson.se> From: Roman Shpount Date: Wed, 13 Jul 2016 17:00:36 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=94eb2c1144f85f80b305378aad1b Archived-At: Cc: "Dale R. Worley" , "sipcore@ietf.org" Subject: Re: [sipcore] Happy Eyeballs: Outbounde X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 21:00:40 -0000 --94eb2c1144f85f80b305378aad1b Content-Type: text/plain; charset=UTF-8 On Wed, Jul 13, 2016 at 4:53 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > > REGISTER requests used for keep-alive are not always authenticated, > because they are not always forwarded to the registrar to begin with. They > are terminated by an edge/outbound proxy. > > > When we implemented keep-alive using REGISTER we used an in memory DB in the edge proxy to store registration and authentication information. We used this DB to aggregate frequent REGISTER requests on the edge proxy into a much less frequent requests to the Registration proxy. So, this is implementable but a lot more work. _____________ Roman Shpount --94eb2c1144f85f80b305378aad1b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Jul 13, 2016 at 4:53 PM, Ch= rister Holmberg <christer.holmberg@ericsson.com> wrote:


REGISTER requests used for keep-alive are no= t always authenticated, because they are not always forwarded to the regist= rar to begin with. They are terminated by an edge/outbound proxy.<= /p>



When we implemented keep-alive using REGISTER we used an in memory DB in t= he edge proxy to store registration and authentication information. We used= this DB to aggregate frequent REGISTER requests on the edge proxy into a m= uch less frequent requests to the Registration proxy. So, this is implement= able but a lot more work.
_____________
Roman Shpount
= =C2=A0
--94eb2c1144f85f80b305378aad1b-- From nobody Wed Jul 13 14:05:10 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A32412D63A for ; Wed, 13 Jul 2016 14:05:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iwi3vb4PlaJL for ; Wed, 13 Jul 2016 14:05:07 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C41512D88B for ; Wed, 13 Jul 2016 14:05:06 -0700 (PDT) X-AuditID: c1b4fb30-f79486d0000069d0-e5-5786ad0185fd Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 45.EF.27088.10DA6875; Wed, 13 Jul 2016 23:05:05 +0200 (CEST) Received: from ESESSMB208.ericsson.se ([169.254.8.19]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0294.000; Wed, 13 Jul 2016 23:05:05 +0200 From: Christer Holmberg To: Roman Shpount Thread-Topic: [sipcore] Happy Eyeballs: Outbounde Thread-Index: AQHR19FKDNW4SmEaHk2is1leOoM+uqAL0quAgArroQCAACJhgP//4V0AgAAiZBA= Date: Wed, 13 Jul 2016 21:05:04 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B476A7E46@ESESSMB208.ericsson.se> References: <8760sia0vv.fsf@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B476A7D69@ESESSMB208.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBIsWRmVeSWpSXmKPExsUyM2K7oi7j2rZwg8kLZSxmXJjKbPH1xyY2 i9md75ksXp4oc2DxmLz/K7PHkiU/mTwuff7P7nFrSkEASxSXTUpqTmZZapG+XQJXxqO+X0wF v1gq3l65x9jA+IKli5GTQ0LAROLGmR1QtpjEhXvr2boYuTiEBI4wShz79o4dwlnMKNF+YiZj FyMHB5uAhUT3P22QBhEBVYm/3yczgYSZBWokvq2KBwkLCxhILJuwiwWixFDiestyJgjbT2Lm ldeMIDYLUOvBc7NZQWxeAV+JPRdnQe1dxCzx8P1TNpAEp0CgxKuGTWCDGIGO+35qDdggZgFx iVtP5jNBHC0gsWTPeWYIW1Ti5eN/rBC2ksSK7ZcYIW7TlFi/Sx+iVVFiSvdDdoi9ghInZz5h mcAoNgvJ1FkIHbOQdMxC0rGAkWUVo2hxanFSbrqRkV5qUWZycXF+nl5easkmRmB8Hdzy22AH 48vnjocYBTgYlXh4FzS2hQuxJpYVV+YeYpTgYFYS4X2yGijEm5JYWZValB9fVJqTWnyIUZqD RUmc1/+lYriQQHpiSWp2ampBahFMlomDU6qBsbtTe/f3NB+16BexFl/4Em9oL9J3kvkqkcno FeC0pOe6CdvV3XZ63tbbN5Xf/nZ+477YCvPn2z4vDT03l/1IYDpD43anpybd9zZ7su9+u7rc KuRbwLlN27tuTKtmvbT7xgt+9uBL5S/0K9zP2Zx6zTJha6GGQ6rtGt41kqF3e+dxR06WW+T9 WomlOCPRUIu5qDgRAJzY33mrAgAA Archived-At: Cc: "Dale R. Worley" , "sipcore@ietf.org" Subject: Re: [sipcore] Happy Eyeballs: Outbounde X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 21:05:09 -0000 SGksDQoNCj4gV2hlbiB3ZSBpbXBsZW1lbnRlZCBrZWVwLWFsaXZlIHVzaW5nIFJFR0lTVEVSIHdl IHVzZWQgYW4gaW4gbWVtb3J5IERCIGluIHRoZSBlZGdlIHByb3h5IHRvIHN0b3JlIHJlZ2lzdHJh dGlvbiBhbmQgYXV0aGVudGljYXRpb24NCj4gaW5mb3JtYXRpb24uIFdlIHVzZWQgdGhpcyBEQiB0 byBhZ2dyZWdhdGUgZnJlcXVlbnQgUkVHSVNURVIgcmVxdWVzdHMgb24gdGhlIGVkZ2UgcHJveHkg aW50byBhIG11Y2ggbGVzcyBmcmVxdWVudCByZXF1ZXN0cyB0byB0aGUgUmVnaXN0cmF0aW9uIHBy b3h5Lg0KDQpDb3JyZWN0Lg0KDQo+IFNvLCB0aGlzIGlzIGltcGxlbWVudGFibGUgYnV0IGEgbG90 IG1vcmUgd29yay4NCg0KU3VyZSwgYW5kIHRoYXQncyB3aHkgd2Ugc2hvdWxkIGhvcGUgdGhhdCBV QXMgaW1wbGVtZW50IFNUVU4gZm9yIGtlZXAtYWxpdmUgOikNCg0KUmVnYXJkcywNCg0KQ2hyaXN0 ZXINCg0K From nobody Wed Jul 13 14:44:51 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97FA712D68B for ; Wed, 13 Jul 2016 14:44:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8RI9sWDkEuwE for ; Wed, 13 Jul 2016 14:44:49 -0700 (PDT) Received: from resqmta-ch2-06v.sys.comcast.net (resqmta-ch2-06v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C284B12D685 for ; Wed, 13 Jul 2016 14:44:49 -0700 (PDT) Received: from resomta-ch2-20v.sys.comcast.net ([69.252.207.116]) by resqmta-ch2-06v.sys.comcast.net with SMTP id NRwgbZ1Fm2NhqNRxZb6I6s; Wed, 13 Jul 2016 21:44:49 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by comcast with SMTP id NRxYb3KkPn5jaNRxYb2npS; Wed, 13 Jul 2016 21:44:48 +0000 To: sipcore@ietf.org References: <8760sia0vv.fsf@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B476A7D69@ESESSMB208.ericsson.se> From: Paul Kyzivat Message-ID: Date: Wed, 13 Jul 2016 17:44:46 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B476A7D69@ESESSMB208.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfG3m7+qtzOiL/P6XiwnLsgNL62Nm8C0dxliCCzbYfMUCISTemHPWsjZ9hf9qSPd/cMVmtl//6N9wH/ZGCGRFxMVZiE7U+WCXAoIAD5pS7NOuUiAwNCzu lMk6f9se0aPZH1wy5U75Ptn4WSgxGGDIUXaTC0TvWW91CvOv2R6gHxL0C+xT7EKx+mA2IT+SFY+Xtw== Archived-At: Subject: Re: [sipcore] Happy Eyeballs: Outbounde - "optimized" REGISTER X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 21:44:50 -0000 On 7/13/16 4:53 PM, Christer Holmberg wrote: > Hi, > > REGISTER requests used for keep-alive are not always authenticated, > because they are not always forwarded to the registrar to begin with. > They are terminated by an edge/outbound proxy. I know this is done, but I have always thought it to be broken. The response to REGISTER is supposed to include *all* contacts that have been registered, not just those that were offered in *this* REGISTER. Also, the expiration time is supposed to reflect what the registrar thinks it is. If the request is short-circuited in a proxy, even a stateful proxy, the response likely won't have that property. Thanks, Paul From nobody Wed Jul 13 15:31:11 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A799312D94E for ; Wed, 13 Jul 2016 15:31:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I9X3w2L_kJJR for ; Wed, 13 Jul 2016 15:31:09 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C6D212D943 for ; Wed, 13 Jul 2016 15:31:09 -0700 (PDT) X-AuditID: c1b4fb25-f79f26d00000327e-45-5786c12b8e4b Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 54.B7.12926.B21C6875; Thu, 14 Jul 2016 00:31:07 +0200 (CEST) Received: from ESESSMB208.ericsson.se ([169.254.8.19]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0294.000; Thu, 14 Jul 2016 00:31:07 +0200 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] Happy Eyeballs: Outbounde - "optimized" REGISTER Thread-Index: AQHR3U/N7OQmxFr0BEKExfR7pp9+YqAW8CJA Date: Wed, 13 Jul 2016 22:31:06 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B476A8FE6@ESESSMB208.ericsson.se> References: <8760sia0vv.fsf@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B476A7D69@ESESSMB208.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsUyM2K7oq72wbZwg57r2hYrNhxgtfj6YxOb A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJVx8T9/wRyOiu+vJzM1MB5n62Lk5JAQMJE4 93QlI4QtJnHh3nqgOBeHkMARRomHjz+DJYQEFjNK/F6V28XIwcEmYCHR/U8bJCwiEChxdckE ZhBbWMBdYu76LlaQEhEBD4n3kwIgSowkzj7Zyw5iswioSmx9s4MJxOYV8JU41PqIHWLVRGaJ Fc9fg83hFHCQaDu5AcxmBLrn+6k1YA3MAuISt57MZ4K4U0BiyZ7zzBC2qMTLx/9YIWwlibWH t7NA1OtILNj9iQ3C1pZYthBiPq+AoMTJmU9YJjCKzkIydhaSlllIWmYhaVnAyLKKUbQ4tTgp N93IWC+1KDO5uDg/Ty8vtWQTIzBGDm75rbqD8fIbx0OMAhyMSjy8CxrbwoVYE8uKK3MPMUpw MCuJ8H7eBxTiTUmsrEotyo8vKs1JLT7EKM3BoiTO6/9SMVxIID2xJDU7NbUgtQgmy8TBKdXA aPLiwNyrc3ZeWZsoVxXAfshMXX6zTWH3YaMim9SuI2cM8mfLcWj1W/1/VCp47lKdj7inw0Sp /5Eup2Jyz79u2h88d+ocwycCMol3Zy4+l73i3XPrA5n+P+JktL98fsD8TsGmq7knVGtbAnfq VyfbZ3rhX4NcLq3SvTj9wtKKXV46Mg86DrZaKbEUZyQaajEXFScCAOYpug6NAgAA Archived-At: Subject: Re: [sipcore] Happy Eyeballs: Outbounde - "optimized" REGISTER X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 22:31:11 -0000 Hi, >> REGISTER requests used for keep-alive are not always authenticated,=20 >> because they are not always forwarded to the registrar to begin with. >> They are terminated by an edge/outbound proxy. > > I know this is done, but I have always thought it to be broken. > > The response to REGISTER is supposed to include *all* contacts that have = been registered, not just those that were offered in *this* REGISTER.=20 The edge proxy can store that information from the previous REGISTER respon= se it received from the registrar, and include it in the REGISTER responses= it triggers itself. It anyway needs to keep track of the registration, to = make sure some REGISTER requests *are* forwarded towards the registrar (in = order for the registration to not expire).=20 > Also, the expiration time is supposed to reflect what the registrar think= s it is. > > If the request is short-circuited in a proxy, even a stateful proxy, the = response likely won't have that property. But it works :) Regards, Christer From nobody Wed Jul 13 16:09:24 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70C3B12D9B6 for ; Wed, 13 Jul 2016 16:09:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DXXYWoEwZohV for ; Wed, 13 Jul 2016 16:09:22 -0700 (PDT) Received: from resqmta-ch2-07v.sys.comcast.net (resqmta-ch2-07v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A615B12D9B1 for ; Wed, 13 Jul 2016 16:09:22 -0700 (PDT) Received: from resomta-ch2-09v.sys.comcast.net ([69.252.207.105]) by resqmta-ch2-07v.sys.comcast.net with SMTP id NTGGbaceyff8qNTHNbqObF; Wed, 13 Jul 2016 23:09:21 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by comcast with SMTP id NTHMbubnddgcdNTHNb02da; Wed, 13 Jul 2016 23:09:21 +0000 To: Christer Holmberg , "sipcore@ietf.org" References: <8760sia0vv.fsf@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B476A7D69@ESESSMB208.ericsson.se> <7594FB04B1934943A5C02806D1A2204B476A8FE6@ESESSMB208.ericsson.se> From: Paul Kyzivat Message-ID: <96b0c04f-bc63-fc32-d460-14eaeaae4568@alum.mit.edu> Date: Wed, 13 Jul 2016 19:09:20 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B476A8FE6@ESESSMB208.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfOW0710XvjZnNoeJeKA5hHqOc0Lujg7SLOSwuXexqPjgV79ZTY/sKFLKvOsYbMjRQhtfHt99NHesdMOy6T70dOxO8PTB6Vz/2xZG7ZRJeJ+/e9tCZwN/ BTU92ft0+MZsuC7soq4lrrHbosXsoqtmcGA12+T3TkEDRp7gCbG86ckpkEFOJj/8+6myBzgHKglN7KGB0FkLdYIOKfhSKowVfSssQ7JW6pCVXy0wyjSIYpcZ Archived-At: Subject: Re: [sipcore] Happy Eyeballs: Outbounde - "optimized" REGISTER X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 23:09:23 -0000 On 7/13/16 6:31 PM, Christer Holmberg wrote: > Hi, > >>> REGISTER requests used for keep-alive are not always authenticated, >>> because they are not always forwarded to the registrar to begin with. >>> They are terminated by an edge/outbound proxy. >> >> I know this is done, but I have always thought it to be broken. >> >> The response to REGISTER is supposed to include *all* contacts that have been registered, not just those that were offered in *this* REGISTER. > > The edge proxy can store that information from the previous REGISTER response it received from the registrar, and include it in the REGISTER responses it triggers itself. It anyway needs to keep track of the registration, to make sure some REGISTER requests *are* forwarded towards the registrar (in order for the registration to not expire). That only works if the proxy is in the path for *all* REGISTER requests for that AoR. Otherwise there can be another contact, added by a UA through a different proxy. And then *this* UA won't get that info until the proxy decides to pass a request on to the registrar. >> Also, the expiration time is supposed to reflect what the registrar thinks it is. >> >> If the request is short-circuited in a proxy, even a stateful proxy, the response likely won't have that property. > > But it works :) For *some* definitions of "works". There are some things that won't work. You may judge that those don't matter, but somebody else may not. Thanks, Paul From nobody Wed Jul 13 18:00:22 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26F4812D9F1 for ; Wed, 13 Jul 2016 18:00:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hiVCI2sozfmd for ; Wed, 13 Jul 2016 18:00:17 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 493B612D65F for ; Wed, 13 Jul 2016 18:00:17 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id CF054E915A6BE; Thu, 14 Jul 2016 01:00:10 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u6E10EHH021381 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 14 Jul 2016 01:00:14 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u6E10C1A017882 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Jul 2016 03:00:14 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.147]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Thu, 14 Jul 2016 03:00:12 +0200 From: "Drage, Keith (Nokia - GB)" To: "Olle E. Johansson" , "Gurbani, Vijay (Nokia - US)" Thread-Topic: [sipcore] Declaring SIP 1.0 historic? Thread-Index: AQHR3REM/IKkKit+yk+r16Eoyg8+saAWSgSAgAAIB4CAAArYAIAATSWAgAAEbYCAAFcOsA== Date: Thu, 14 Jul 2016 01:00:11 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADF27FA6@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <1EE2D149-1E1A-49DA-ACB8-625FEC4E4508@edvina.net> <76f2fd5e65bfa393281d682d23e18f11@mail.gmail.com> <22406.24552.369096.256493@compute06.cs.columbia.edu> <7D55514D-4E15-4E2A-BEE1-4511B97E0665@edvina.net> In-Reply-To: <7D55514D-4E15-4E2A-BEE1-4511B97E0665@edvina.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Declaring SIP 1.0 historic? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2016 01:00:20 -0000 U28gY2FuIHlvdSBiZSBjbGVhciBvbiB3aGVyZSB5b3UgYXJlIHRyeWluZyB0byBnZXQgdG8uDQoN CjEpCWRlcHJlY2F0ZSBTSVAgMS4wIC0tPiBidXQgaXQgbmV2ZXIgZXhpc3RlZC4NCg0KMikJZGVw cmVjYXRlIFJGQyAyNTQzIC0tPiBidXQgdGhpcyBSRkMgaXMgaGlzdG9yaWMgYW5kIHRoZXJlZm9y ZSBpcyBvZiB0aGF0IHN0YXR1cy4NCg0KMykJZGVwcmVjYXRlIG1lY2hhbmlzbXMgZm9yIGludGVy b3BlcmFiaWxpdHkgb2YgUkZDIDMyNjEgd2l0aCBSRkMgMjU0Mz8NCg0KUmVnYXJkcw0KDQpLZWl0 aCBEcmFnZQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogc2lwY29yZSBbbWFp bHRvOnNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE9sbGUgRS4gSm9oYW5z c29uDQpTZW50OiAxMyBKdWx5IDIwMTYgMjE6MjgNClRvOiBHdXJiYW5pLCBWaWpheSAoTm9raWEg LSBVUykNCkNjOiBzaXBjb3JlQGlldGYub3JnOyBPbGxlIEUgSm9oYW5zc29uDQpTdWJqZWN0OiBS ZTogW3NpcGNvcmVdIERlY2xhcmluZyBTSVAgMS4wIGhpc3RvcmljPw0KDQoNCj4gT24gMTMgSnVs IDIwMTYsIGF0IDIyOjEyLCBWaWpheSBLLiBHdXJiYW5pIDx2a2dAYmVsbC1sYWJzLmNvbT4gd3Jv dGU6DQo+IA0KPiBPbiAwNy8xMy8yMDE2IDEwOjM2IEFNLCBKb25hdGhhbiBMZW5ub3ggd3JvdGU6 DQo+Pj4gSSB3b3VsZCBoYXZlIG5vIHByb2JsZW0gaGVhcmluZyB0aGF0IHN0b3J5IC0gd2h5IGRp ZCB3ZSBrZWVwIHRoZQ0KPj4+IDIuMCB2ZXJzaW9uIGluIDMyNjEgLSB3aGlsZSBnZW50bHkgU0lQ cGluZyBhIGdlcm1hbiBiZWVyIGluIEJlcmxpbiANCj4+PiBuZXh0IHdlZWsgOi0pDQo+PiANCj4+ IFdlIGtlcHQgaXQgYmVjYXVzZSBTSVAgcm91dGluZyBydWxlcyAobm90YWJseSBmb3JraW5nKSBt ZWFuIHRoYXQgDQo+PiB0aGVyZSdzIG5vIGdvb2Qgd2F5IHRvIHRyeSB0byBzZW5kIGEgcmVxdWVz dCB3aXRoIGEgbmV3ZXIgdmVyc2lvbiwgDQo+PiBhbmQgdGhlbiBpZiBpdCBmYWlscywgZmFsbCBi YWNrIHRvIGFuIG9sZGVyIHZlcnNpb24uICBUaGlzIGlzIHdoeSBhbGwgDQo+PiBiYWNrd2FyZCBj b21wYXRpYmlsaXR5IGluIFNJUCBoYXMgdG8gYmUgc2luZ2xlLXBhc3MuDQo+IA0KPiBSaWdodCwg dGhhdCBtYXRjaGVzIG15IHJlY29sbGVjdGlvbiBhcyB3ZWxsLiAgV2hlbiB3ZSB3ZXJlIGRlc2ln bmluZyANCj4gd2hhdCBldmVudHVhbGx5IGJlY2FtZSByZmMzMjYxLCBhIHByaW1lIGRpcmVjdGl2 ZSB3YXMgZG8gbm8gaGFybSBhbmQgDQo+IGJlIGJhY2t3YXJkbHkgY29tcGF0aWJsZS4gIEJlY2F1 c2UgcmZjMjU0MyB3YXMgZGVwbG95ZWQgYW5kIGJlaW5nIA0KPiB1c2VkLCBhIGZvcmtsaWZ0IHVw Z3JhZGUgYnkgY2hhbmdpbmcgdGhlIHByb3RvY29sIHZlcnNpb24gd2FzIG5vdCANCj4gbG9va2Vk IGF0IGtpbmRseS4NCj4gDQo+IEFsbW9zdCBhIGRlY2FkZSBhZ28sIGEgYnJpZWYgZW1haWwgZXhj aGFuZ2Ugc3VyZmFjZWQgdG8gZW50ZXJ0YWluIHRoZSANCj4gaWRlYSBvZiBhIFNJUC8zLjAgWzFd LiAgSXQgd2FzIGlnbm9taW5pb3VzbHkgc2hvcnQgbGl2ZWQgOi0pDQo+IA0KPiBbMV0gDQo+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvc2lwL2N1cnJlbnQvdGhyZDE5Lmh0 bWwjMTg0MjENCg0KSnVzdCBsb3ZlIHRoaXMgcXVvdGUgYnkgRGFsZSBXb3JsZXk6DQoNCiJTSVAg My4wIGlzIGxpa2UgZnVsbHkgcGFydGljaXBhdG9yeSBkZW1vY3JhY3ksIHRoZSB1bHRpbWF0ZSBm b3JtIG9mIGNvbW11bmlzbSwgYW5kIHRoZSBlYXJ0aGx5IEtpbmdkb20gb2YgR29kIC0tIGEgdGhv cm91Z2ggcmVmb3JtIG9mIHdoYXQgcHJlc2VudGx5IGV4aXN0cyB0aGF0IHdpbGwgcmVtb3ZlIGFs bCBvZiBpdHMgZmxhd3MuDQoNClNpbWlsYXIgdG8gdGhvc2Ugb3RoZXIgdGhyZWUgcHJvamVjdHMs IHRoZXJlIGlzIG5vIFdHIHRpbWVsaW5lIHlldCBmb3IgU0lQIDMuMCBkZXZlbG9wbWVudC7igJ0N Cg0KTGV04oCZcyBzdGFydCBTSVAgNC4wIDotKQ0KDQovTw0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCnNpcGNvcmUgbWFpbGluZyBsaXN0DQpzaXBjb3Jl QGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUN Cg== From nobody Wed Jul 13 23:44:36 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 241B712DAC2 for ; Wed, 13 Jul 2016 23:44:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bGozM-caVTGL for ; Wed, 13 Jul 2016 23:44:32 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8908B12DABB for ; Wed, 13 Jul 2016 23:44:31 -0700 (PDT) Received: from [192.168.40.18] (h87-96-134-129.cust.se.alltele.net [87.96.134.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id 59FB442E3; Thu, 14 Jul 2016 08:44:28 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Olle E. Johansson" In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BADF27FA6@FR712WXCHMBA11.zeu.alcatel-lucent.com> Date: Thu, 14 Jul 2016 08:44:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <57544CAE-0B2E-4F06-AF2E-15FFC7363376@edvina.net> References: <1EE2D149-1E1A-49DA-ACB8-625FEC4E4508@edvina.net> <76f2fd5e65bfa393281d682d23e18f11@mail.gmail.com> <22406.24552.369096.256493@compute06.cs.columbia.edu> <7D55514D-4E15-4E2A-BEE1-4511B97E0665@edvina.net> <949EF20990823C4C85C18D59AA11AD8BADF27FA6@FR712WXCHMBA11.zeu.alcatel-lucent.com> To: "Drage, Keith (Nokia - GB)" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "Gurbani, Vijay \(Nokia - US\)" , "sipcore@ietf.org" , Olle E Johansson Subject: Re: [sipcore] Declaring SIP 1.0 historic? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2016 06:44:35 -0000 > On 14 Jul 2016, at 03:00, Drage, Keith (Nokia - GB) = wrote: >=20 > So can you be clear on where you are trying to get to. >=20 > 1) deprecate SIP 1.0 --> but it never existed. >=20 > 2) deprecate RFC 2543 --> but this RFC is historic and therefore is = of that status. Where can I see that status? I only see =E2=80=9Cstandard track=E2=80=9D = and =E2=80=9Cproposed standard=E2=80=9D. https://www.rfc-editor.org/search/rfc_search_detail.php I don=E2=80=99t agree with you here. It=E2=80=99s obsoleted by never = declared historic as far as I understand. What would happen if we did? >=20 > 3) deprecate mechanisms for interoperability of RFC 3261 with RFC = 2543? Maybe that would be the effect. Can we try to figure out what would = happen? One clear benefit highlighted seems to be to get rid of the restrictions = on=20 changes of the from/to headers. Now, how would that work with STIR? /O >=20 > Regards >=20 > Keith Drage >=20 > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Olle E. = Johansson > Sent: 13 July 2016 21:28 > To: Gurbani, Vijay (Nokia - US) > Cc: sipcore@ietf.org; Olle E Johansson > Subject: Re: [sipcore] Declaring SIP 1.0 historic? >=20 >=20 >> On 13 Jul 2016, at 22:12, Vijay K. Gurbani wrote: >>=20 >> On 07/13/2016 10:36 AM, Jonathan Lennox wrote: >>>> I would have no problem hearing that story - why did we keep the >>>> 2.0 version in 3261 - while gently SIPping a german beer in Berlin=20= >>>> next week :-) >>>=20 >>> We kept it because SIP routing rules (notably forking) mean that=20 >>> there's no good way to try to send a request with a newer version,=20= >>> and then if it fails, fall back to an older version. This is why = all=20 >>> backward compatibility in SIP has to be single-pass. >>=20 >> Right, that matches my recollection as well. When we were designing=20= >> what eventually became rfc3261, a prime directive was do no harm and=20= >> be backwardly compatible. Because rfc2543 was deployed and being=20 >> used, a forklift upgrade by changing the protocol version was not=20 >> looked at kindly. >>=20 >> Almost a decade ago, a brief email exchange surfaced to entertain the=20= >> idea of a SIP/3.0 [1]. It was ignominiously short lived :-) >>=20 >> [1]=20 >> https://www.ietf.org/mail-archive/web/sip/current/thrd19.html#18421 >=20 > Just love this quote by Dale Worley: >=20 > "SIP 3.0 is like fully participatory democracy, the ultimate form of = communism, and the earthly Kingdom of God -- a thorough reform of what = presently exists that will remove all of its flaws. >=20 > Similar to those other three projects, there is no WG timeline yet for = SIP 3.0 development.=E2=80=9D >=20 > Let=E2=80=99s start SIP 4.0 :-) >=20 > /O > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Thu Jul 14 00:27:31 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14EDC12B063 for ; Thu, 14 Jul 2016 00:27:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id twZvaReQAAiS for ; Thu, 14 Jul 2016 00:27:28 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A2E012B050 for ; Thu, 14 Jul 2016 00:27:28 -0700 (PDT) X-AuditID: c1b4fb30-f79486d0000069d0-d1-57873ebc1500 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id DE.E2.27088.CBE37875; Thu, 14 Jul 2016 09:26:52 +0200 (CEST) Received: from ESESSMB208.ericsson.se ([169.254.8.19]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0294.000; Thu, 14 Jul 2016 09:26:51 +0200 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] Happy Eyeballs: Outbounde - "optimized" REGISTER Thread-Index: AQHR3U/N7OQmxFr0BEKExfR7pp9+YqAW8CJA///q4wCAAL5+AA== Date: Thu, 14 Jul 2016 07:26:52 +0000 Message-ID: References: <8760sia0vv.fsf@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B476A7D69@ESESSMB208.ericsson.se> <7594FB04B1934943A5C02806D1A2204B476A8FE6@ESESSMB208.ericsson.se> <96b0c04f-bc63-fc32-d460-14eaeaae4568@alum.mit.edu> In-Reply-To: <96b0c04f-bc63-fc32-d460-14eaeaae4568@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <81AACED0D9ADF34BA8F93A014E71042E@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrAIsWRmVeSWpSXmKPExsUyM2J7oO5du/Zwg8+dHBYrNhxgtfj6YxOb A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJXxZdJ61oKDvBUvd19jb2B8wdXFyMkhIWAi cXX9T1YIW0ziwr31bF2MXBxCAkcYJY7uWsUE4SxmlLj35iBzFyMHB5uAhUT3P22QBhGBQImr SyYwg9jCAu4SM7s+MYGUiAh4SLyfFABR4iRx+2I7O4jNIqAq8WzvcyYQm1fASuJa+1Go8d0s EnO+v2YBSXAKOEhcvHASrIER6KDvp9aANTALiEvcejKfCeJQAYkle84zQ9iiEi8f/wN7QFRA T+L719lQcSWJHxsusUD06kncmDqFDcK2lug79J8RwtaWWLbwNTPEQYISJ2c+YZnAKD4LybpZ SNpnIWmfhaR9FpL2BYysqxhFi1OLk3LTjYz0Uosyk4uL8/P08lJLNjEC4+3glt8GOxhfPnc8 xCjAwajEw7ugsS1ciDWxrLgy9xCjBAezkgivlVV7uBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXFe /5eK4UIC6YklqdmpqQWpRTBZJg5OqQZGp+1Lwz/MCOxv/h17sHsaO6vysx/G6p8cDpw/dvA3 +5adrxk+XZ30aNI0a2WDVobVj9SNNCQry6bWzDiYIn5migFjY06O6M6OW+suH1q9be93JzuH DQtNMs9slZlc3Ln9nl3qpMwDJ31T7x2J+Fnl9cOtYcOFR49WNfp/aX8mt/Lm/wV2kT4LFimx FGckGmoxFxUnAgDxRDRMswIAAA== Archived-At: Subject: Re: [sipcore] Happy Eyeballs: Outbounde - "optimized" REGISTER X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2016 07:27:30 -0000 Hi, >>>>REGISTER requests used for keep-alive are not always authenticated, >>>> because they are not always forwarded to the registrar to begin with. >>>> They are terminated by an edge/outbound proxy. >>> >>> I know this is done, but I have always thought it to be broken. >>> >>> The response to REGISTER is supposed to include *all* contacts that >>>have been registered, not just those that were offered in *this* >>>REGISTER. >> >> The edge proxy can store that information from the previous REGISTER >>response it received from the registrar, and include it in the REGISTER >>responses it triggers itself. It anyway needs to keep track of the >>registration, to make sure some REGISTER requests *are* forwarded >>towards the registrar (in order for the registration to not expire). > >That only works if the proxy is in the path for *all* REGISTER requests >for that AoR. Otherwise there can be another contact, added by a UA >through a different proxy. And then *this* UA won't get that info until >the proxy decides to pass a request on to the registrar. Sure, but that is the case even if REGISTERs aren't used for keep-alives. >>> Also, the expiration time is supposed to reflect what the registrar >>>thinks it is. >>> >>> If the request is short-circuited in a proxy, even a stateful proxy, >>>the response likely won't have that property. >> >> But it works :) > >For *some* definitions of "works". There are some things that won't >work. You may judge that those don't matter, but somebody else may not. Sure. And, I didn=B9t mean to say this is the best way of doing things - I was only explaining how many do use REGISTER for keep-olives. Regards, Christer From nobody Thu Jul 14 00:30:58 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A58612B071 for ; Thu, 14 Jul 2016 00:30:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2I90Q9db80xE for ; Thu, 14 Jul 2016 00:30:56 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8499F12B050 for ; Thu, 14 Jul 2016 00:30:55 -0700 (PDT) X-AuditID: c1b4fb2d-f79936d0000030e4-13-57873f9ad5b1 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 5C.72.12516.A9F37875; Thu, 14 Jul 2016 09:30:34 +0200 (CEST) Received: from ESESSMB208.ericsson.se ([169.254.8.19]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0294.000; Thu, 14 Jul 2016 09:30:33 +0200 From: Christer Holmberg To: Christer Holmberg , Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] Happy Eyeballs: Outbounde - "optimized" REGISTER Thread-Index: AQHR3U/N7OQmxFr0BEKExfR7pp9+YqAW8CJA///q4wCAAL5+AIAAAQkA Date: Thu, 14 Jul 2016 07:30:33 +0000 Message-ID: References: <8760sia0vv.fsf@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B476A7D69@ESESSMB208.ericsson.se> <7594FB04B1934943A5C02806D1A2204B476A8FE6@ESESSMB208.ericsson.se> <96b0c04f-bc63-fc32-d460-14eaeaae4568@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="euc-kr" Content-ID: <05A77FF1CC381147B7DB8A6D86E76A92@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrAIsWRmVeSWpSXmKPExsUyM2K7t+4a+/Zwgx8TFSxWbDjAavH1xyY2 ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSvj2axvzAWrxCq+3/3H0sD4QLSLkZNDQsBE 4vKf+SwQtpjEhXvr2boYuTiEBI4wSkzZvogFwlnMKHF800HWLkYODjYBC4nuf9ogcRGBVkaJ LRvuMoJ0Cwu4S8zs+sQEUiMi4CHxflIASFhEwE3i2bFTrCA2i4CqxJf9jWDLeAWsJI793MoK MX8Pi8T778sZQXo5BawlVk+2BqlhBDro+6k1TCA2s4C4xK0n85kgDhWQWLLnPDOELSrx8vE/ sPmiAnoS37/OhoorSlydvhyqV0viy499bBC2tcSLuyeh4ooSU7ofskPcIyhxcuYTlgmM4rOQ rJuFpH0WkvZZSNpnIWlfwMi6ilG0OLW4ODfdyFgvtSgzubg4P08vL7VkEyMw3g5u+a27g3H1 a8dDjAIcjEo8vAsa28KFWBPLiitzDzFKcDArifBa2LWHC/GmJFZWpRblxxeV5qQWH2KU5mBR Euf1f6kYLiSQnliSmp2aWpBaBJNl4uCUamBUysz+7Vz15oRH38rn/5ctqnXdoxX3dvs6tkka MvfXsLu0qLn9iA4vmFbGY7dn1fqp0+7PZZikVRraWDRD+LeXyNNbScoSa34dkj3y8NANMUGX gBVvSqN3S8+1ead4d+vF9JyY5p+JAUfPh9xrmBYruMtvilPcGakzh8Um7maIvMttpSPxNNdQ iaU4I9FQi7moOBEAz4p1HrMCAAA= Archived-At: Subject: Re: [sipcore] Happy Eyeballs: Outbounde - "optimized" REGISTER X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2016 07:30:57 -0000 a2VlcC1hbGl2ZXMsIHRoYXQgaXMgOikNCg0KT24gMTQvMDcvMTYgMTA6MjYsICJzaXBjb3JlIG9u IGJlaGFsZiBvZiBDaHJpc3RlciBIb2xtYmVyZyINCjxzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmcg b24gYmVoYWxmIG9mIGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4NCndyb3RlOg0KDQo+ SGksDQo+DQo+Pj4+PlJFR0lTVEVSIHJlcXVlc3RzIHVzZWQgZm9yIGtlZXAtYWxpdmUgYXJlIG5v dCBhbHdheXMgYXV0aGVudGljYXRlZCwNCj4+Pj4+IGJlY2F1c2UgdGhleSBhcmUgbm90IGFsd2F5 cyBmb3J3YXJkZWQgdG8gdGhlIHJlZ2lzdHJhciB0byBiZWdpbiB3aXRoLg0KPj4+Pj4gVGhleSBh cmUgdGVybWluYXRlZCBieSBhbiBlZGdlL291dGJvdW5kIHByb3h5Lg0KPj4+Pg0KPj4+PiBJIGtu b3cgdGhpcyBpcyBkb25lLCBidXQgSSBoYXZlIGFsd2F5cyB0aG91Z2h0IGl0IHRvIGJlIGJyb2tl bi4NCj4+Pj4NCj4+Pj4gVGhlIHJlc3BvbnNlIHRvIFJFR0lTVEVSIGlzIHN1cHBvc2VkIHRvIGlu Y2x1ZGUgKmFsbCogY29udGFjdHMgdGhhdA0KPj4+PmhhdmUgYmVlbiByZWdpc3RlcmVkLCBub3Qg anVzdCB0aG9zZSB0aGF0IHdlcmUgb2ZmZXJlZCBpbiAqdGhpcyoNCj4+Pj5SRUdJU1RFUi4NCj4+ Pg0KPj4+IFRoZSBlZGdlIHByb3h5IGNhbiBzdG9yZSB0aGF0IGluZm9ybWF0aW9uIGZyb20gdGhl IHByZXZpb3VzIFJFR0lTVEVSDQo+Pj5yZXNwb25zZSBpdCByZWNlaXZlZCBmcm9tIHRoZSByZWdp c3RyYXIsIGFuZCBpbmNsdWRlIGl0IGluIHRoZSBSRUdJU1RFUg0KPj4+cmVzcG9uc2VzIGl0IHRy aWdnZXJzIGl0c2VsZi4gSXQgYW55d2F5IG5lZWRzIHRvIGtlZXAgdHJhY2sgb2YgdGhlDQo+Pj5y ZWdpc3RyYXRpb24sIHRvIG1ha2Ugc3VyZSBzb21lIFJFR0lTVEVSIHJlcXVlc3RzICphcmUqIGZv cndhcmRlZA0KPj4+dG93YXJkcyB0aGUgcmVnaXN0cmFyIChpbiBvcmRlciBmb3IgdGhlIHJlZ2lz dHJhdGlvbiB0byBub3QgZXhwaXJlKS4NCj4+DQo+PlRoYXQgb25seSB3b3JrcyBpZiB0aGUgcHJv eHkgaXMgaW4gdGhlIHBhdGggZm9yICphbGwqIFJFR0lTVEVSIHJlcXVlc3RzDQo+PmZvciB0aGF0 IEFvUi4gT3RoZXJ3aXNlIHRoZXJlIGNhbiBiZSBhbm90aGVyIGNvbnRhY3QsIGFkZGVkIGJ5IGEg VUENCj4+dGhyb3VnaCBhIGRpZmZlcmVudCBwcm94eS4gQW5kIHRoZW4gKnRoaXMqIFVBIHdvbid0 IGdldCB0aGF0IGluZm8gdW50aWwNCj4+dGhlIHByb3h5IGRlY2lkZXMgdG8gcGFzcyBhIHJlcXVl c3Qgb24gdG8gdGhlIHJlZ2lzdHJhci4NCj4NCj5TdXJlLCBidXQgdGhhdCBpcyB0aGUgY2FzZSBl dmVuIGlmIFJFR0lTVEVScyBhcmVuJ3QgdXNlZCBmb3Iga2VlcC1hbGl2ZXMuDQo+DQo+Pj4+IEFs c28sIHRoZSBleHBpcmF0aW9uIHRpbWUgaXMgc3VwcG9zZWQgdG8gcmVmbGVjdCB3aGF0IHRoZSBy ZWdpc3RyYXINCj4+Pj50aGlua3MgaXQgaXMuDQo+Pj4+DQo+Pj4+IElmIHRoZSByZXF1ZXN0IGlz IHNob3J0LWNpcmN1aXRlZCBpbiBhIHByb3h5LCBldmVuIGEgc3RhdGVmdWwgcHJveHksDQo+Pj4+ dGhlIHJlc3BvbnNlIGxpa2VseSB3b24ndCBoYXZlIHRoYXQgcHJvcGVydHkuDQo+Pj4NCj4+PiBC dXQgaXQgd29ya3MgOikNCj4+DQo+PkZvciAqc29tZSogZGVmaW5pdGlvbnMgb2YgIndvcmtzIi4g VGhlcmUgYXJlIHNvbWUgdGhpbmdzIHRoYXQgd29uJ3QNCj4+d29yay4gWW91IG1heSBqdWRnZSB0 aGF0IHRob3NlIGRvbid0IG1hdHRlciwgYnV0IHNvbWVib2R5IGVsc2UgbWF5IG5vdC4NCj4NCj4N Cj5TdXJlLg0KPg0KPkFuZCwgSSBkaWRuqfZ0IG1lYW4gdG8gc2F5IHRoaXMgaXMgdGhlIGJlc3Qg d2F5IG9mIGRvaW5nIHRoaW5ncyAtIEkgd2FzDQo+b25seSBleHBsYWluaW5nIGhvdyBtYW55IGRv IHVzZSBSRUdJU1RFUiBmb3Iga2VlcC1vbGl2ZXMuDQo+DQo+UmVnYXJkcywNCj4NCj5DaHJpc3Rl cg0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ c2lwY29yZSBtYWlsaW5nIGxpc3QNCj5zaXBjb3JlQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlDQoNCg== From nobody Thu Jul 14 00:34:22 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E6F012DAE5 for ; Thu, 14 Jul 2016 00:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wm-uiWjk8KBW for ; Thu, 14 Jul 2016 00:34:19 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B78AA12DAE1 for ; Thu, 14 Jul 2016 00:34:19 -0700 (PDT) Received: from [192.168.40.18] (h87-96-134-129.cust.se.alltele.net [87.96.134.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id 5FA2C42E3; Thu, 14 Jul 2016 09:34:16 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Olle E. Johansson" In-Reply-To: Date: Thu, 14 Jul 2016 09:34:17 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <28524A52-0665-4472-9A32-4328E45CD62E@edvina.net> References: <8760sia0vv.fsf@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B476A7D69@ESESSMB208.ericsson.se> <7594FB04B1934943A5C02806D1A2204B476A8FE6@ESESSMB208.ericsson.se> <96b0c04f-bc63-fc32-d460-14eaeaae4568@alum.mit.edu> To: Christer Holmberg , sipcore@ietf.org X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Olle E Johansson Subject: Re: [sipcore] Happy Eyeballs: Outbounde - "optimized" REGISTER X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2016 07:34:21 -0000 Even using OPTIONs for keepalives may generate problems considering a = SIP implementation that use OPTIONs for discovery. In the case of Asterisk OPTIONs are answered blindly. But INVITEs are = authenticated and generated depending upon whether we have a configuration for that = particular user. This means that OPTIONs and INVITEs have different responses. If the UA = use the OPTIONs answer (including SDP) for discovery, the result is all wrong=E2=80= =A6 For keepalives - I would use what=E2=80=99s describe in section 4.4 of = RFC 5626, regardless of if I follow outbound or not. CRLF or STUN. /O= From nobody Thu Jul 14 00:43:31 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33B4912DADA for ; Thu, 14 Jul 2016 00:43:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DPeUzVkpCxEy for ; Thu, 14 Jul 2016 00:43:28 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF50912B063 for ; Thu, 14 Jul 2016 00:43:27 -0700 (PDT) X-AuditID: c1b4fb2d-f79936d0000030e4-5b-5787429d5ec2 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id AA.55.12516.D9247875; Thu, 14 Jul 2016 09:43:25 +0200 (CEST) Received: from ESESSMB208.ericsson.se ([169.254.8.19]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0294.000; Thu, 14 Jul 2016 09:43:05 +0200 From: Christer Holmberg To: "Olle E. Johansson" , "sipcore@ietf.org" Thread-Topic: [sipcore] Happy Eyeballs: Outbounde - "optimized" REGISTER Thread-Index: AQHR3U/N7OQmxFr0BEKExfR7pp9+YqAW8CJA///q4wCAAL5+AP//zpeAgAA18YA= Date: Thu, 14 Jul 2016 07:43:04 +0000 Message-ID: References: <8760sia0vv.fsf@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B476A7D69@ESESSMB208.ericsson.se> <7594FB04B1934943A5C02806D1A2204B476A8FE6@ESESSMB208.ericsson.se> <96b0c04f-bc63-fc32-d460-14eaeaae4568@alum.mit.edu> <28524A52-0665-4472-9A32-4328E45CD62E@edvina.net> In-Reply-To: <28524A52-0665-4472-9A32-4328E45CD62E@edvina.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <22BA6395D60FA945A1E2130191A71ADF@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprPIsWRmVeSWpSXmKPExsUyM2K7q+5cp/Zwg2+LTC1erj7EbPH1xyY2 ByaPaWtXsnosWfKTKYApissmJTUnsyy1SN8ugSvj/MY9zAUbmCoe7V7H3sD4lrGLkZNDQsBE 4kLXcSYIW0ziwr31bF2MXBxCAkcYJV48XMIM4SxmlDj/7jVLFyMHB5uAhUT3P20QU0QgUGLC akmQXmEBd4mZXZ+YIMIeEu8nBYCERQT8JKZeWgO2ikVAVWLt6ftsIDavgJXE5dMbWSCmf2CR eHTkBliCU8BOYlbvdbAGRqB7vp9aA3Ybs4C4xK0n86HuFJBYsuc8M4QtKvHy8T9WEFtUQE/i +9fZUHEliR8bLrFA9OpJ3Jg6hQ3Ctpb41t/KDmFrSyxb+JoZ4iBBiZMzn7BMYBSfhWTdLCTt s5C0z0LSPgtJ+wJG1lWMosWpxcW56UbGeqlFmcnFxfl5enmpJZsYgdF2cMtv3R2Mq187HmIU 4GBU4uFd0NgWLsSaWFZcmXuIUYKDWUmE18KuPVyINyWxsiq1KD++qDQntfgQozQHi5I4r/9L xXAhgfTEktTs1NSC1CKYLBMHp1QDY+nVDS1TQ7IVZV2r9t+tZ9/401cu0//91RvXd2WFSDv0 vN4SyJk7ybBF+43R+YSCvWcn7tzB3GCg83jTkQMdzzg6itY9vWCnZS5m43pGdtZlSde3hbO+ 7217s/dexcb9Hxinrsm8zn7W7mqXl/vOvK0PeNv4Lu5ctnbCu4jzxndPHCyLuCy85p8SS3FG oqEWc1FxIgCdE11ssgIAAA== Archived-At: Subject: Re: [sipcore] Happy Eyeballs: Outbounde - "optimized" REGISTER X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2016 07:43:30 -0000 >... > > >For keepalives - I would use what=B9s describe in section 4.4 of RFC 5626, >regardless of >if I follow outbound or not. CRLF or STUN. The negotiation and usage of those, without outbound, is described in RFC 6223. https://tools.ietf.org/rfc/rfc6223.txt Regards, Christer From nobody Thu Jul 14 00:49:58 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3922F12DADA for ; Thu, 14 Jul 2016 00:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jc0ahhHP-CyD for ; Thu, 14 Jul 2016 00:49:54 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02D7512DA93 for ; Thu, 14 Jul 2016 00:49:53 -0700 (PDT) Received: from [192.168.40.18] (h87-96-134-129.cust.se.alltele.net [87.96.134.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id F3B1942E3; Thu, 14 Jul 2016 09:49:50 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Olle E. Johansson" In-Reply-To: Date: Thu, 14 Jul 2016 09:49:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8760sia0vv.fsf@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B476A7D69@ESESSMB208.ericsson.se> <7594FB04B1934943A5C02806D1A2204B476A8FE6@ESESSMB208.ericsson.se> <96b0c04f-bc63-fc32-d460-14eaeaae4568@alum.mit.edu> <28524A52-0665-4472-9A32-4328E45CD62E@edvina.net> To: Christer Holmberg X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "sipcore@ietf.org" , Olle E Johansson Subject: Re: [sipcore] Happy Eyeballs: Outbounde - "optimized" REGISTER X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2016 07:49:56 -0000 > On 14 Jul 2016, at 09:43, Christer Holmberg = wrote: >=20 >> ... >>=20 >>=20 >> For keepalives - I would use what=C4=85s describe in section 4.4 of = RFC 5626, >> regardless of >> if I follow outbound or not. CRLF or STUN. >=20 > The negotiation and usage of those, without outbound, is described in = RFC > 6223. >=20 > https://tools.ietf.org/rfc/rfc6223.txt >=20 >=20 Thank you for that reference, I forgot about that. We do need to update The Hitchhiker=E2=80=99s guide to SIP. The extended = version :-) /O From nobody Thu Jul 14 08:03:32 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 314D312D80B for ; Thu, 14 Jul 2016 08:03:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2nfq6ioHfy4T for ; Thu, 14 Jul 2016 08:03:28 -0700 (PDT) Received: from resqmta-po-08v.sys.comcast.net (resqmta-po-08v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:167]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F2BC12D7DA for ; Thu, 14 Jul 2016 08:03:28 -0700 (PDT) Received: from resomta-po-18v.sys.comcast.net ([96.114.154.242]) by resqmta-po-08v.sys.comcast.net with SMTP id NiAIbxyWe2dNjNiAhbrf3L; Thu, 14 Jul 2016 15:03:27 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by comcast with SMTP id NiAgbLxscaQBwNiAhb9MET; Thu, 14 Jul 2016 15:03:27 +0000 To: Christer Holmberg , "sipcore@ietf.org" References: <8760sia0vv.fsf@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B476A7D69@ESESSMB208.ericsson.se> <7594FB04B1934943A5C02806D1A2204B476A8FE6@ESESSMB208.ericsson.se> <96b0c04f-bc63-fc32-d460-14eaeaae4568@alum.mit.edu> From: Paul Kyzivat Message-ID: <9f26276c-2b1f-3ca4-47bb-e30e2c6edfa0@alum.mit.edu> Date: Thu, 14 Jul 2016 11:03:26 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=euc-kr; format=flowed Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfJROivhFafs+a6pE/Htpa7QnLD9/UmuaX0H6CFNDJ2lbVIb3ITKl7AnJKhf5PPV3v2nXASMuBo4Tull7e6Hsv6+NShP5haGhcDCxHYeoc6xBWgmd1yg/ iVh+O9fUgVR6iKN+oZzpTzZEnHwmd7yfVS/5SJOhkwKFuiPSQC4LVh/7qfGh9srtxoZ0PTiSAUZQ+7BHjzzu8ILglon/tJ2uErXJKfdUcJosNxFUJijpmTe0 Archived-At: Subject: Re: [sipcore] Happy Eyeballs: Outbounde - "optimized" REGISTER X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2016 15:03:31 -0000 On 7/14/16 3:30 AM, Christer Holmberg wrote: > keep-alives, that is :) I think I prefer keep-olives :-) > On 14/07/16 10:26, "sipcore on behalf of Christer Holmberg" > > wrote: > >> Hi, >> >>>>>> REGISTER requests used for keep-alive are not always authenticated, >>>>>> because they are not always forwarded to the registrar to begin with. >>>>>> They are terminated by an edge/outbound proxy. >>>>> >>>>> I know this is done, but I have always thought it to be broken. >>>>> >>>>> The response to REGISTER is supposed to include *all* contacts that >>>>> have been registered, not just those that were offered in *this* >>>>> REGISTER. >>>> >>>> The edge proxy can store that information from the previous REGISTER >>>> response it received from the registrar, and include it in the REGISTER >>>> responses it triggers itself. It anyway needs to keep track of the >>>> registration, to make sure some REGISTER requests *are* forwarded >>>> towards the registrar (in order for the registration to not expire). >>> >>> That only works if the proxy is in the path for *all* REGISTER requests >>> for that AoR. Otherwise there can be another contact, added by a UA >>> through a different proxy. And then *this* UA won't get that info until >>> the proxy decides to pass a request on to the registrar. >> >> Sure, but that is the case even if REGISTERs aren't used for keep-alives. >> >>>>> Also, the expiration time is supposed to reflect what the registrar >>>>> thinks it is. >>>>> >>>>> If the request is short-circuited in a proxy, even a stateful proxy, >>>>> the response likely won't have that property. >>>> >>>> But it works :) >>> >>> For *some* definitions of "works". There are some things that won't >>> work. You may judge that those don't matter, but somebody else may not. >> >> >> Sure. >> >> And, I didn©öt mean to say this is the best way of doing things - I was >> only explaining how many do use REGISTER for keep-olives. >> >> Regards, >> >> Christer >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore > From nobody Thu Jul 14 10:23:58 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90B1712D0AA for ; Thu, 14 Jul 2016 10:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fQHOd3T7vcbl for ; Thu, 14 Jul 2016 10:23:47 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E7B812D113 for ; Thu, 14 Jul 2016 10:23:47 -0700 (PDT) Received: from mutabilis-2.local ([173.57.161.14]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u6EHNjCh053407 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 14 Jul 2016 12:23:46 -0500 (CDT) (envelope-from mahoney@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [173.57.161.14] claimed to be mutabilis-2.local To: sipcore@ietf.org References: <1EE2D149-1E1A-49DA-ACB8-625FEC4E4508@edvina.net> <76f2fd5e65bfa393281d682d23e18f11@mail.gmail.com> <22406.24552.369096.256493@compute06.cs.columbia.edu> <7D55514D-4E15-4E2A-BEE1-4511B97E0665@edvina.net> <949EF20990823C4C85C18D59AA11AD8BADF27FA6@FR712WXCHMBA11.zeu.alcatel-lucent.com> <57544CAE-0B2E-4F06-AF2E-15FFC7363376@edvina.net> From: "A. Jean Mahoney" Message-ID: <10ae4e29-4c66-e389-144f-b607dfd53bac@nostrum.com> Date: Thu, 14 Jul 2016 12:23:44 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <57544CAE-0B2E-4F06-AF2E-15FFC7363376@edvina.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sipcore] Declaring SIP 1.0 historic? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2016 17:23:56 -0000 On 7/14/16 1:44 AM, Olle E. Johansson wrote: > >> On 14 Jul 2016, at 03:00, Drage, Keith (Nokia - GB) wrote: >> >> So can you be clear on where you are trying to get to. >> >> 1) deprecate SIP 1.0 --> but it never existed. >> >> 2) deprecate RFC 2543 --> but this RFC is historic and therefore is of that status. > Where can I see that status? I only see “standard track†and “proposed standardâ€. > https://www.rfc-editor.org/search/rfc_search_detail.php > > I don’t agree with you here. It’s obsoleted by never declared historic as far as I > understand. What would happen if we did? The IESG has a statement on moving RFCs to Historic: https://www.ietf.org/iesg/statement/designating-rfcs-as-historic Basically - If the technology has been "retired", then its RFC can be given an "Historic" designation. If the tech is still in use, but has been updated by a replacement version, then the RFC is "Obsolete". RFC 2543 is correctly classified as "Obsoleted by RFC 3265, RFC 3264, RFC 3261, RFC 3262, RFC 3263". Jean >> >> 3) deprecate mechanisms for interoperability of RFC 3261 with RFC 2543? > Maybe that would be the effect. Can we try to figure out what would happen? > One clear benefit highlighted seems to be to get rid of the restrictions on > changes of the from/to headers. Now, how would that work with STIR? > > /O >> >> Regards >> >> Keith Drage >> >> -----Original Message----- >> From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Olle E. Johansson >> Sent: 13 July 2016 21:28 >> To: Gurbani, Vijay (Nokia - US) >> Cc: sipcore@ietf.org; Olle E Johansson >> Subject: Re: [sipcore] Declaring SIP 1.0 historic? >> >> >>> On 13 Jul 2016, at 22:12, Vijay K. Gurbani wrote: >>> >>> On 07/13/2016 10:36 AM, Jonathan Lennox wrote: >>>>> I would have no problem hearing that story - why did we keep the >>>>> 2.0 version in 3261 - while gently SIPping a german beer in Berlin >>>>> next week :-) >>>> >>>> We kept it because SIP routing rules (notably forking) mean that >>>> there's no good way to try to send a request with a newer version, >>>> and then if it fails, fall back to an older version. This is why all >>>> backward compatibility in SIP has to be single-pass. >>> >>> Right, that matches my recollection as well. When we were designing >>> what eventually became rfc3261, a prime directive was do no harm and >>> be backwardly compatible. Because rfc2543 was deployed and being >>> used, a forklift upgrade by changing the protocol version was not >>> looked at kindly. >>> >>> Almost a decade ago, a brief email exchange surfaced to entertain the >>> idea of a SIP/3.0 [1]. It was ignominiously short lived :-) >>> >>> [1] >>> https://www.ietf.org/mail-archive/web/sip/current/thrd19.html#18421 >> >> Just love this quote by Dale Worley: >> >> "SIP 3.0 is like fully participatory democracy, the ultimate form of communism, and the earthly Kingdom of God -- a thorough reform of what presently exists that will remove all of its flaws. >> >> Similar to those other three projects, there is no WG timeline yet for SIP 3.0 development.†>> >> Let’s start SIP 4.0 :-) >> >> /O >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Thu Jul 14 11:04:43 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1B0812D1B8 for ; Thu, 14 Jul 2016 11:04:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=broadsoft-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M4ks4B0-lclP for ; Thu, 14 Jul 2016 11:04:37 -0700 (PDT) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F85F12D185 for ; Thu, 14 Jul 2016 11:04:37 -0700 (PDT) Received: by mail-qt0-x22f.google.com with SMTP id u25so46763045qtb.1 for ; Thu, 14 Jul 2016 11:04:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadsoft-com.20150623.gappssmtp.com; s=20150623; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:content-transfer-encoding; bh=hqztpbSK7lZd9G462/YyAnQlmPrLz7O3aZPwhvk/B3g=; b=zTdxUum+Ws9Uo86a+yuLXNZ65VnMokuA9Nfs7lDo/p3QO3NHdKvMPXKMMrGiEfKMq3 KIZlE/YOa4R/JrCOVIvQy63H7w7/w3TVvXCr6nkmrLKIBVIzsmfQPkk1zQpybb5kLKUH lGwAqxAQidaX/clMGujbeWC3eL8AN5Sw6lo0beACRKmUWet0fu96syt1Y0Ll99iktfDA 8U8rdNKQJ8JWflr5MTC1zkMmrYe3ztjFzgeOvAs0Wk6zyKzTJ01yJOFv+GyOiYAfJgVJ UVZGMKOWVF0YbJV8O1J7CaKePv5Fih4wgVE7zPGQn6X/m1Pj2kpr7CZatQFPNgcG2BFh v8jQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:content-transfer-encoding; bh=hqztpbSK7lZd9G462/YyAnQlmPrLz7O3aZPwhvk/B3g=; b=Ag/Vt00S+j39TVYSynU6gSMsUC0BTfR7yw0iaJ+o7A1sPEZC97n1Dkny7yVb4SmExl zJ7CpTjTH1KZpFWblyOjsrGNZvY9tK/8Cl4Juvl+snSBcGOWdMBsRMlYbK604QHykCC7 wmIr/kJZhvLkW66eA1Qxs8L8LnSVxXtSYXcW2O+vknOlvT6ieWGPTF64vR8pO6darEPM NheLeU2iIK+WRb80PHWO+VW/1DvUJSCSkff5Me9VP9QvZVmCT4y7uIOmQoAo96MN4s4q mKjt3lX0TkVkh4Vud6pY6raxefqkB5MirD5oG5Z6Gd3zCGqVAgs+jvJboavdVGJUinTI RUAw== X-Gm-Message-State: ALyK8tLo9ykxFK2YmjakzGADfF9AMTeo2cIJ15KlvuB12fwi6t4k+vtEIDAhyGW/i3c4wZo9WPQs/wVaElBnQWG9 X-Received: by 10.237.47.228 with SMTP id m91mr21646289qtd.35.1468519476573; Thu, 14 Jul 2016 11:04:36 -0700 (PDT) From: Brett Tate References: <1EE2D149-1E1A-49DA-ACB8-625FEC4E4508@edvina.net> <76f2fd5e65bfa393281d682d23e18f11@mail.gmail.com> <22406.24552.369096.256493@compute06.cs.columbia.edu> <2a1fbfd6bc303aa7420632403e4910c7@mail.gmail.com> <2042D098-4A81-4188-B232-4C357115BB71@edvina.net> In-Reply-To: <2042D098-4A81-4188-B232-4C357115BB71@edvina.net> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGhNHGVYLaedcNWJpc8nhZijnHPtwEeGLtZAUgxRo4BneXeZgD+PyNBAqYW8oqgPDTKcA== Date: Thu, 14 Jul 2016 14:04:35 -0400 Message-ID: <0a0fcc1acc1b58fb928f2334df153097@mail.gmail.com> To: "Olle E. Johansson" , sipcore@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [sipcore] Declaring SIP 1.0 historic? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2016 18:04:40 -0000 > > For instance, RFC 3261 section 12.2.1.1 indicates > > an expectation that the "mandatory reflection of > > the original To and From URI in mid-dialog requests > > will be deprecated in a subsequent revision". I'm > > not sure why; however some vendors and operators want > > to allow the To/From URI to change without any > > restrictions (e.g. they don't want to be restricted > > by RFC 4916). > > There are many call transfer scenarios involving b2bua=E2=80=99s > that need to modify/update caller IDs and there are too > many implementations pre-4916 out there. Yes; support for RFC 3325 and RFC 5876 appears to be more common. Updating RFC 3261 isn't necessarily going to increase support of RFC 4916 o= r allow To/From URI changes in a non-controlled fashion. As far as I know, RFC 4916 was the solution to allow To/From URI changes; however I guess tha= t another one can be defined. From nobody Thu Jul 14 11:23:30 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8952D12D176 for ; Thu, 14 Jul 2016 11:23:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fqw-M6HGVYDT for ; Thu, 14 Jul 2016 11:23:28 -0700 (PDT) Received: from resqmta-po-09v.sys.comcast.net (resqmta-po-09v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:168]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8711412D0A5 for ; Thu, 14 Jul 2016 11:23:28 -0700 (PDT) Received: from resomta-po-06v.sys.comcast.net ([96.114.154.230]) by resqmta-po-09v.sys.comcast.net with SMTP id NlHcbqbY3S0FENlIGb4KKh; Thu, 14 Jul 2016 18:23:28 +0000 Received: from hobgoblin.ariadne.com ([73.143.237.82]) by comcast with SMTP id NlIEbcPMCcZjANlIFbkOlw; Thu, 14 Jul 2016 18:23:28 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u6EINPNT004762; Thu, 14 Jul 2016 14:23:25 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u6EINPJY004758; Thu, 14 Jul 2016 14:23:25 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: "Vijay K. Gurbani" In-Reply-To: (vkg@bell-labs.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Thu, 14 Jul 2016 14:23:25 -0400 Message-ID: <878tx4w02q.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfGAoDjlgrwSA1Sre9Qjd8qKM12WwzSvS+nQ/1FBE0Zj6ZmKBJ/NocPAzHEq/p5AWv2vEfjw3KJfD5KHtbl1Ie3XsamjyVgP7h3kEnmy6IVfgThPlathm ulFFOZevvcDLq98me2I29QexqZpbo/8BzuffrnsxCDkp8tGps7z0qtxzjWc1R4iLnf9y2huBl2xl5pU6VBcZ2o6LSER5VuBkj1M= Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] Declaring SIP 1.0 historic? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2016 18:23:29 -0000 "Vijay K. Gurbani" writes: > Almost a decade ago, a brief email exchange surfaced to entertain the > idea of a SIP/3.0 [1]. It was ignominiously short lived :-) > > [1] https://www.ietf.org/mail-archive/web/sip/current/thrd19.html#18421 What ever happened to the proposal for "peer-to-peer-to-peer-to-peer" SIP? My vague memory is that it was "SIP/4.0" and was an April fool's RFC, but its not in the Wikipedia list of same. Dale From nobody Thu Jul 14 12:08:34 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B908A12D548 for ; Thu, 14 Jul 2016 12:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HGCXOXuszne2 for ; Thu, 14 Jul 2016 12:08:29 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4310412D1E3 for ; Thu, 14 Jul 2016 12:08:28 -0700 (PDT) Received: from [192.168.40.18] (h87-96-134-129.cust.se.alltele.net [87.96.134.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id 10BA342E3; Thu, 14 Jul 2016 21:08:23 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Olle E. Johansson" In-Reply-To: <10ae4e29-4c66-e389-144f-b607dfd53bac@nostrum.com> Date: Thu, 14 Jul 2016 21:08:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <21BF1FC8-DC3F-4823-A23E-616DEF347712@edvina.net> References: <1EE2D149-1E1A-49DA-ACB8-625FEC4E4508@edvina.net> <76f2fd5e65bfa393281d682d23e18f11@mail.gmail.com> <22406.24552.369096.256493@compute06.cs.columbia.edu> <7D55514D-4E15-4E2A-BEE1-4511B97E0665@edvina.net> <949EF20990823C4C85C18D59AA11AD8BADF27FA6@FR712WXCHMBA11.zeu.alcatel-lucent.com> <57544CAE-0B2E-4F06-AF2E-15FFC7363376@edvina.net> <10ae4e29-4c66-e389-144f-b607dfd53bac@nostrum.com> To: "A. Jean Mahoney" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: sipcore@ietf.org, Olle E Johansson Subject: Re: [sipcore] Declaring SIP 1.0 historic? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2016 19:08:33 -0000 > On 14 Jul 2016, at 19:23, A. Jean Mahoney wrote: >=20 >=20 >=20 > On 7/14/16 1:44 AM, Olle E. Johansson wrote: >>=20 >>> On 14 Jul 2016, at 03:00, Drage, Keith (Nokia - GB) = wrote: >>>=20 >>> So can you be clear on where you are trying to get to. >>>=20 >>> 1) deprecate SIP 1.0 --> but it never existed. >>>=20 >>> 2) deprecate RFC 2543 --> but this RFC is historic and therefore is = of that status. >> Where can I see that status? I only see =E2=80=9Cstandard track=E2=80=9D= and =E2=80=9Cproposed standard=E2=80=9D. >> https://www.rfc-editor.org/search/rfc_search_detail.php >>=20 >> I don=E2=80=99t agree with you here. It=E2=80=99s obsoleted by never = declared historic as far as I >> understand. What would happen if we did? >=20 > The IESG has a statement on moving RFCs to Historic: >=20 > https://www.ietf.org/iesg/statement/designating-rfcs-as-historic >=20 > Basically - If the technology has been "retired", then its RFC can be = given an "Historic" designation. If the tech is still in use, but has = been updated by a replacement version, then the RFC is "Obsolete". >=20 > RFC 2543 is correctly classified as "Obsoleted by RFC 3265, RFC 3264, = RFC 3261, RFC 3262, RFC 3263=E2=80=9D. THank you for the explanation Jean! /Olle >=20 > Jean >=20 >>>=20 >>> 3) deprecate mechanisms for interoperability of RFC 3261 with RFC = 2543? >> Maybe that would be the effect. Can we try to figure out what would = happen? >> One clear benefit highlighted seems to be to get rid of the = restrictions on >> changes of the from/to headers. Now, how would that work with STIR? >>=20 >> /O >>>=20 >>> Regards >>>=20 >>> Keith Drage >>>=20 >>> -----Original Message----- >>> From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Olle E. = Johansson >>> Sent: 13 July 2016 21:28 >>> To: Gurbani, Vijay (Nokia - US) >>> Cc: sipcore@ietf.org; Olle E Johansson >>> Subject: Re: [sipcore] Declaring SIP 1.0 historic? >>>=20 >>>=20 >>>> On 13 Jul 2016, at 22:12, Vijay K. Gurbani = wrote: >>>>=20 >>>> On 07/13/2016 10:36 AM, Jonathan Lennox wrote: >>>>>> I would have no problem hearing that story - why did we keep the >>>>>> 2.0 version in 3261 - while gently SIPping a german beer in = Berlin >>>>>> next week :-) >>>>>=20 >>>>> We kept it because SIP routing rules (notably forking) mean that >>>>> there's no good way to try to send a request with a newer version, >>>>> and then if it fails, fall back to an older version. This is why = all >>>>> backward compatibility in SIP has to be single-pass. >>>>=20 >>>> Right, that matches my recollection as well. When we were = designing >>>> what eventually became rfc3261, a prime directive was do no harm = and >>>> be backwardly compatible. Because rfc2543 was deployed and being >>>> used, a forklift upgrade by changing the protocol version was not >>>> looked at kindly. >>>>=20 >>>> Almost a decade ago, a brief email exchange surfaced to entertain = the >>>> idea of a SIP/3.0 [1]. It was ignominiously short lived :-) >>>>=20 >>>> [1] >>>> https://www.ietf.org/mail-archive/web/sip/current/thrd19.html#18421 >>>=20 >>> Just love this quote by Dale Worley: >>>=20 >>> "SIP 3.0 is like fully participatory democracy, the ultimate form of = communism, and the earthly Kingdom of God -- a thorough reform of what = presently exists that will remove all of its flaws. >>>=20 >>> Similar to those other three projects, there is no WG timeline yet = for SIP 3.0 development.=E2=80=9D >>>=20 >>> Let=E2=80=99s start SIP 4.0 :-) >>>=20 >>> /O >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>=20 >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >>=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Thu Jul 14 14:35:26 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8622812B037 for ; Thu, 14 Jul 2016 14:35:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u2_lfFkZrSp5 for ; Thu, 14 Jul 2016 14:35:22 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C22512D633 for ; Thu, 14 Jul 2016 14:35:21 -0700 (PDT) Received: from pps.filterd (m0078664.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u6ELXV4u016056; Thu, 14 Jul 2016 17:35:20 -0400 Received: from stntexhc12.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 242uwtsp5j-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Thu, 14 Jul 2016 17:35:20 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.94]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.03.0279.002; Thu, 14 Jul 2016 17:35:17 -0400 From: "Peterson, Jon" To: "sipcore@ietf.org" Thread-Topic: [sipcore] SIP AuthNZ Problem Statement - v3 Thread-Index: AQHRqS0TDyFOI6cZKUWBz4pHTe07DJ+vbNaAgAFjyQCAA2UIgIACvqkAgANXvoCABITogIAH9hmAgAMlg4CAF/VngIAF7xoAgAGiQYD//8wQAIAB3CEA///zYgCAAYUpAIAIFXSAgAFN74CAAC7vAIABf0UAgAFhuICABilFgIADX4uAgAZXpQCAA2w+AIADCHsAgAlOFIA= Date: Thu, 14 Jul 2016 21:35:17 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B37F97548@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-originating-ip: [10.96.12.50] Content-Type: multipart/alternative; boundary="_000_D3A5256C1A51FFjonpetersonneustarbiz_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-07-14_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1607140229 Archived-At: Cc: Rifaat Shekh-Yusef Subject: Re: [sipcore] SIP AuthNZ Problem Statement - v3 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2016 21:35:24 -0000 --_000_D3A5256C1A51FFjonpetersonneustarbiz_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think at this point, if you want to propose your way of setting conferenc= e policy with SIP as a problem space, feel free - I don't happen to think t= here's much of a gap there, given the existence of means other than RFC4579= ad hoc INVITEs to set up conferences when you have more complicated securi= ty needs than an ad hoc conference ordinarily would. If the group agrees th= at there is 1) a need to convey conference policy in SIP, and 2) a need for= attribute-based authorization tokens issued by IdPs to support that confer= ence policy, Again, I am not suggesting to use SIP to set the policy (1); SIP will only = be used to carry the authorization (2). At its core, this is our disagreement in a nutshell. If SIP is not the prot= ocol that is setting the conference policy, then it makes no sense to me th= at SIP should convey the authorization for conference policy. Setting confe= rence policy is a task that is much more aligned with the semantics and fea= tures available in HTTP, and that's why HTTP is what the conferencing frame= work recommends for this. Surely the protocol that needs to carry the autho= rization for the conference policy is the protocol that carries the confere= nce policy. Conveniently, HTTP already supports OAuth. Jon Peterson Neustar, Inc. Regards, Rifaat --_000_D3A5256C1A51FFjonpetersonneustarbiz_ Content-Type: text/html; charset="us-ascii" Content-ID: <2E6A7C6BBFA0634795926109C2FEEF60@neustar.biz> Content-Transfer-Encoding: quoted-printable


I think at this point, if you want to propose your way of setting conf= erence policy with SIP as a problem space, feel free - I don't happen to th= ink there's much of a gap there, given the existence of means other than RF= C4579 ad hoc INVITEs to set up conferences when you have more complicated security needs than an ad hoc conference or= dinarily would. If the group agrees that there is 1) a need to convey confe= rence policy in SIP, and 2) a need for attribute-based authorization tokens= issued by IdPs to support that conference policy,

Again, I am not suggesting to use SIP to set the policy (1); SI= P will only be used to carry the authorization (2).

At its core, this is our disagreement in a nutshell. If SIP is not the= protocol that is setting the conference policy, then it makes no sense to = me that SIP should convey the authorization for conference policy. Setting = conference policy is a task that is much more aligned with the semantics and features available in HTTP, an= d that's why HTTP is what the conferencing framework recommends for this. S= urely the protocol that needs to carry the authorization for the conference= policy is the protocol that carries the conference policy. Conveniently, HTTP already supports OAuth.

Jon Peterson
Neustar, Inc.


Regards,
 Rifaat


 --_000_D3A5256C1A51FFjonpetersonneustarbiz_-- From nobody Thu Jul 14 17:08:49 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AA7412D90F for ; Thu, 14 Jul 2016 17:08:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EaH3KlS739sL for ; Thu, 14 Jul 2016 17:08:45 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8689A12D910 for ; Thu, 14 Jul 2016 17:08:45 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 781F9BCFF53EC; Fri, 15 Jul 2016 00:08:39 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u6F08hCQ013578 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 15 Jul 2016 00:08:43 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u6F074I8000594 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 15 Jul 2016 02:08:38 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.147]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Fri, 15 Jul 2016 02:05:38 +0200 From: "Drage, Keith (Nokia - GB)" To: "Olle E. Johansson" Thread-Topic: [sipcore] Declaring SIP 1.0 historic? Thread-Index: AQHR3REM/IKkKit+yk+r16Eoyg8+saAWSgSAgAAIB4CAAArYAIAATSWAgAAEbYCAAFcOsIAAVSkAgADukwA= Date: Fri, 15 Jul 2016 00:05:38 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADF28CD0@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <1EE2D149-1E1A-49DA-ACB8-625FEC4E4508@edvina.net> <76f2fd5e65bfa393281d682d23e18f11@mail.gmail.com> <22406.24552.369096.256493@compute06.cs.columbia.edu> <7D55514D-4E15-4E2A-BEE1-4511B97E0665@edvina.net> <949EF20990823C4C85C18D59AA11AD8BADF27FA6@FR712WXCHMBA11.zeu.alcatel-lucent.com> <57544CAE-0B2E-4F06-AF2E-15FFC7363376@edvina.net> In-Reply-To: <57544CAE-0B2E-4F06-AF2E-15FFC7363376@edvina.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "Gurbani, Vijay \(Nokia - US\)" , "sipcore@ietf.org" Subject: Re: [sipcore] Declaring SIP 1.0 historic? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 00:08:48 -0000 UkZDIDIwMjYgc2VjdGlvbiA0LjIuNDoNCg0KNC4yLjQgIEhpc3RvcmljDQoNCiAgIEEgc3BlY2lm aWNhdGlvbiB0aGF0IGhhcyBiZWVuIHN1cGVyc2VkZWQgYnkgYSBtb3JlIHJlY2VudA0KICAgc3Bl Y2lmaWNhdGlvbiBvciBpcyBmb3IgYW55IG90aGVyIHJlYXNvbiBjb25zaWRlcmVkIHRvIGJlIG9i c29sZXRlIGlzDQogICBhc3NpZ25lZCB0byB0aGUgIkhpc3RvcmljIiBsZXZlbC4NCg0KRGF0YXRy YWNrZXIgcGFnZSBmb3IgUkZDIDI1NDM6DQoNCkRvY3VtZW50IAlUeXBlIAkJUkZDIC0gUHJvcG9z ZWQgU3RhbmRhcmQgKE1hcmNoIDE5OTk7IE5vIGVycmF0YSkNCk9ic29sZXRlZCBieSBSRkMgMzI2 NSwgUkZDIDMyNjQsIFJGQyAzMjYxLCBSRkMgMzI2MiwgUkZDIDMyNjMNCldhcyBkcmFmdC1pZXRm LW1tdXNpYy1zaXAgKG1tdXNpYyBXRykNCg0KDQpSZWdhcmRzDQoNCktlaXRoDQoNCi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBPbGxlIEUuIEpvaGFuc3NvbiBbbWFpbHRvOm9lakBl ZHZpbmEubmV0XSANClNlbnQ6IDE0IEp1bHkgMjAxNiAwNzo0NA0KVG86IERyYWdlLCBLZWl0aCAo Tm9raWEgLSBHQikNCkNjOiBPbGxlIEUgSm9oYW5zc29uOyBHdXJiYW5pLCBWaWpheSAoTm9raWEg LSBVUyk7IHNpcGNvcmVAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbc2lwY29yZV0gRGVjbGFyaW5n IFNJUCAxLjAgaGlzdG9yaWM/DQoNCg0KPiBPbiAxNCBKdWwgMjAxNiwgYXQgMDM6MDAsIERyYWdl LCBLZWl0aCAoTm9raWEgLSBHQikgPGtlaXRoLmRyYWdlQG5va2lhLmNvbT4gd3JvdGU6DQo+IA0K PiBTbyBjYW4geW91IGJlIGNsZWFyIG9uIHdoZXJlIHlvdSBhcmUgdHJ5aW5nIHRvIGdldCB0by4N Cj4gDQo+IDEpCWRlcHJlY2F0ZSBTSVAgMS4wIC0tPiBidXQgaXQgbmV2ZXIgZXhpc3RlZC4NCj4g DQo+IDIpCWRlcHJlY2F0ZSBSRkMgMjU0MyAtLT4gYnV0IHRoaXMgUkZDIGlzIGhpc3RvcmljIGFu ZCB0aGVyZWZvcmUgaXMgb2YgdGhhdCBzdGF0dXMuDQpXaGVyZSBjYW4gSSBzZWUgdGhhdCBzdGF0 dXM/IEkgb25seSBzZWUg4oCcc3RhbmRhcmQgdHJhY2vigJ0gYW5kIOKAnHByb3Bvc2VkIHN0YW5k YXJk4oCdLg0KaHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvc2VhcmNoL3JmY19zZWFyY2hfZGV0 YWlsLnBocA0KDQpJIGRvbuKAmXQgYWdyZWUgd2l0aCB5b3UgaGVyZS4gSXTigJlzIG9ic29sZXRl ZCBieSBuZXZlciBkZWNsYXJlZCBoaXN0b3JpYyBhcyBmYXIgYXMgSSB1bmRlcnN0YW5kLiBXaGF0 IHdvdWxkIGhhcHBlbiBpZiB3ZSBkaWQ/DQo+IA0KPiAzKQlkZXByZWNhdGUgbWVjaGFuaXNtcyBm b3IgaW50ZXJvcGVyYWJpbGl0eSBvZiBSRkMgMzI2MSB3aXRoIFJGQyAyNTQzPw0KTWF5YmUgdGhh dCB3b3VsZCBiZSB0aGUgZWZmZWN0LiBDYW4gd2UgdHJ5IHRvIGZpZ3VyZSBvdXQgd2hhdCB3b3Vs ZCBoYXBwZW4/DQpPbmUgY2xlYXIgYmVuZWZpdCBoaWdobGlnaHRlZCBzZWVtcyB0byBiZSB0byBn ZXQgcmlkIG9mIHRoZSByZXN0cmljdGlvbnMgb24gY2hhbmdlcyBvZiB0aGUgZnJvbS90byBoZWFk ZXJzLiBOb3csIGhvdyB3b3VsZCB0aGF0IHdvcmsgd2l0aCBTVElSPw0KDQovTw0KPiANCj4gUmVn YXJkcw0KPiANCj4gS2VpdGggRHJhZ2UNCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+IEZyb206IHNpcGNvcmUgW21haWx0bzpzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBPbGxlIEUuIA0KPiBKb2hhbnNzb24NCj4gU2VudDogMTMgSnVseSAyMDE2IDIxOjI4 DQo+IFRvOiBHdXJiYW5pLCBWaWpheSAoTm9raWEgLSBVUykNCj4gQ2M6IHNpcGNvcmVAaWV0Zi5v cmc7IE9sbGUgRSBKb2hhbnNzb24NCj4gU3ViamVjdDogUmU6IFtzaXBjb3JlXSBEZWNsYXJpbmcg U0lQIDEuMCBoaXN0b3JpYz8NCj4gDQo+IA0KPj4gT24gMTMgSnVsIDIwMTYsIGF0IDIyOjEyLCBW aWpheSBLLiBHdXJiYW5pIDx2a2dAYmVsbC1sYWJzLmNvbT4gd3JvdGU6DQo+PiANCj4+IE9uIDA3 LzEzLzIwMTYgMTA6MzYgQU0sIEpvbmF0aGFuIExlbm5veCB3cm90ZToNCj4+Pj4gSSB3b3VsZCBo YXZlIG5vIHByb2JsZW0gaGVhcmluZyB0aGF0IHN0b3J5IC0gd2h5IGRpZCB3ZSBrZWVwIHRoZQ0K Pj4+PiAyLjAgdmVyc2lvbiBpbiAzMjYxIC0gd2hpbGUgZ2VudGx5IFNJUHBpbmcgYSBnZXJtYW4g YmVlciBpbiBCZXJsaW4gDQo+Pj4+IG5leHQgd2VlayA6LSkNCj4+PiANCj4+PiBXZSBrZXB0IGl0 IGJlY2F1c2UgU0lQIHJvdXRpbmcgcnVsZXMgKG5vdGFibHkgZm9ya2luZykgbWVhbiB0aGF0IA0K Pj4+IHRoZXJlJ3Mgbm8gZ29vZCB3YXkgdG8gdHJ5IHRvIHNlbmQgYSByZXF1ZXN0IHdpdGggYSBu ZXdlciB2ZXJzaW9uLCANCj4+PiBhbmQgdGhlbiBpZiBpdCBmYWlscywgZmFsbCBiYWNrIHRvIGFu IG9sZGVyIHZlcnNpb24uICBUaGlzIGlzIHdoeSANCj4+PiBhbGwgYmFja3dhcmQgY29tcGF0aWJp bGl0eSBpbiBTSVAgaGFzIHRvIGJlIHNpbmdsZS1wYXNzLg0KPj4gDQo+PiBSaWdodCwgdGhhdCBt YXRjaGVzIG15IHJlY29sbGVjdGlvbiBhcyB3ZWxsLiAgV2hlbiB3ZSB3ZXJlIGRlc2lnbmluZyAN Cj4+IHdoYXQgZXZlbnR1YWxseSBiZWNhbWUgcmZjMzI2MSwgYSBwcmltZSBkaXJlY3RpdmUgd2Fz IGRvIG5vIGhhcm0gYW5kIA0KPj4gYmUgYmFja3dhcmRseSBjb21wYXRpYmxlLiAgQmVjYXVzZSBy ZmMyNTQzIHdhcyBkZXBsb3llZCBhbmQgYmVpbmcgDQo+PiB1c2VkLCBhIGZvcmtsaWZ0IHVwZ3Jh ZGUgYnkgY2hhbmdpbmcgdGhlIHByb3RvY29sIHZlcnNpb24gd2FzIG5vdCANCj4+IGxvb2tlZCBh dCBraW5kbHkuDQo+PiANCj4+IEFsbW9zdCBhIGRlY2FkZSBhZ28sIGEgYnJpZWYgZW1haWwgZXhj aGFuZ2Ugc3VyZmFjZWQgdG8gZW50ZXJ0YWluIHRoZSANCj4+IGlkZWEgb2YgYSBTSVAvMy4wIFsx XS4gIEl0IHdhcyBpZ25vbWluaW91c2x5IHNob3J0IGxpdmVkIDotKQ0KPj4gDQo+PiBbMV0NCj4+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvc2lwL2N1cnJlbnQvdGhyZDE5 Lmh0bWwjMTg0MjENCj4gDQo+IEp1c3QgbG92ZSB0aGlzIHF1b3RlIGJ5IERhbGUgV29ybGV5Og0K PiANCj4gIlNJUCAzLjAgaXMgbGlrZSBmdWxseSBwYXJ0aWNpcGF0b3J5IGRlbW9jcmFjeSwgdGhl IHVsdGltYXRlIGZvcm0gb2YgY29tbXVuaXNtLCBhbmQgdGhlIGVhcnRobHkgS2luZ2RvbSBvZiBH b2QgLS0gYSB0aG9yb3VnaCByZWZvcm0gb2Ygd2hhdCBwcmVzZW50bHkgZXhpc3RzIHRoYXQgd2ls bCByZW1vdmUgYWxsIG9mIGl0cyBmbGF3cy4NCj4gDQo+IFNpbWlsYXIgdG8gdGhvc2Ugb3RoZXIg dGhyZWUgcHJvamVjdHMsIHRoZXJlIGlzIG5vIFdHIHRpbWVsaW5lIHlldCBmb3IgU0lQIDMuMCBk ZXZlbG9wbWVudC7igJ0NCj4gDQo+IExldOKAmXMgc3RhcnQgU0lQIDQuMCA6LSkNCj4gDQo+IC9P DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHNp cGNvcmUgbWFpbGluZyBsaXN0DQo+IHNpcGNvcmVAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlDQo+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+IHNpcGNvcmUgbWFpbGluZyBsaXN0DQo+IHNpcGNv cmVAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBj b3JlDQoNCg== From nobody Fri Jul 15 03:54:35 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A22712DD14 for ; Fri, 15 Jul 2016 03:54:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=broadsoft-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZAWV02-oQaf for ; Fri, 15 Jul 2016 03:54:31 -0700 (PDT) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1484012DD21 for ; Fri, 15 Jul 2016 03:54:30 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id u25so57177452qtb.1 for ; Fri, 15 Jul 2016 03:54:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadsoft-com.20150623.gappssmtp.com; s=20150623; h=from:mime-version:thread-index:date:message-id:subject:to; bh=CnZBQExK4jGT+PILdAOIz8daFs3kiRa5DmVKmMDClvI=; b=d1QnQZeFevQtRDRyAmY+bLvZyrzYN9gg3MmLH1ljENQz8Ss+I1Tsp3UJjkJRW6utDn aUXaVW6zEoNn6QJNGdS/C53XUwCh06yyAIXtglGparctIKQXcUMprQb+Ik7bepuOmxos REQ8ojRXs/iBDFlGCoMG5inyEQlsZbAU00pG8eVcjoYK0HqHwqlXe5CqpC+IM38SYFec xTpZ6B/WVTEU65qJxujqBBBN8lzZYw2hLSBRHekSzACEGPTI2WgOuyTm3mCyYtQ2/vk1 MLS8jmu1tJaxaCBQsx4kPCgfwbvnjVvr+QO9FQFAVQLqjW56roAVfMf6bIj4pJcCNqyn Nn7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:thread-index:date:message-id :subject:to; bh=CnZBQExK4jGT+PILdAOIz8daFs3kiRa5DmVKmMDClvI=; b=K7XL58DCo6dv0oIkNBCVynbRThotvzrMXJ/eTDJTkGE4bxnvitm5qFHorWyIKQ1pNj k7uhSXid+PLZSjdWujB7pw/uvAgJTihwJq/CfiM2uWEeY1fgApqrUEU0WpDXdOcWkmj8 1/SSi5U9SiTh9OItTvrVR1Z8NrdbT+odXp6WdgHcafP58hk1cWJ7XBk+ZIY1xP7yJHnZ Yyk+Pj5JWes8XdI9rr8ftoE3I8j+jrKYe5z7qm4hd/x3+yiCH53YRYJ4tlnHYAwufUGo tRi0UKDy6YEsncgvkv6YI3QOfflUXFnf2kQfgwuHnzi3uxrSs/NOMfiBbWPCepZt+eTE 0Y1Q== X-Gm-Message-State: ALyK8tIlx2BMPlguC+Nn5QfVgRi+lkv1AMYCzqSfnoFCOHZRJ0/72zPTHyFea69xZ9HeMtDwqo25T9i7Rspaj5+4 X-Received: by 10.237.35.146 with SMTP id j18mr2499530qtc.35.1468580070170; Fri, 15 Jul 2016 03:54:30 -0700 (PDT) From: Brett Tate MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdHehzhupHn+ieoXQdqfpXLG7b+F1A== Date: Fri, 15 Jul 2016 06:54:29 -0400 Message-ID: <57e9561c4e6df6a6219c25e05f688739@mail.gmail.com> To: "Dale R. Worley" , sipcore@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [sipcore] Declaring SIP 1.0 historic? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 10:54:33 -0000 Although I thought it was an excellent draft, draft-kaplan-sip-four-oh-00 never became an RFC. https://tools.ietf.org/id/draft-kaplan-sip-four-oh-00.txt > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Dale R. Worley > Sent: Thursday, July 14, 2016 2:23 PM > To: Vijay K. Gurbani > Cc: sipcore@ietf.org > Subject: Re: [sipcore] Declaring SIP 1.0 historic? > > "Vijay K. Gurbani" writes: > > Almost a decade ago, a brief email exchange surfaced to entertain the > > idea of a SIP/3.0 [1]. It was ignominiously short lived :-) > > > > [1] > > https://www.ietf.org/mail-archive/web/sip/current/thrd19.html#18421 > > What ever happened to the proposal for "peer-to-peer-to-peer-to-peer" > SIP? My vague memory is that it was "SIP/4.0" and was an April fool's RFC, > but its not in the Wikipedia list of same. > > Dale > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Fri Jul 15 12:26:09 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7D7612D188 for ; Fri, 15 Jul 2016 12:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7oqKDa3CLuAs for ; Fri, 15 Jul 2016 12:26:06 -0700 (PDT) Received: from resqmta-po-10v.sys.comcast.net (resqmta-po-10v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:169]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6543912D18D for ; Fri, 15 Jul 2016 12:26:06 -0700 (PDT) Received: from resomta-po-15v.sys.comcast.net ([96.114.154.239]) by resqmta-po-10v.sys.comcast.net with SMTP id O8k5btsESHqolO8kPbxzLj; Fri, 15 Jul 2016 19:26:05 +0000 Received: from hobgoblin.ariadne.com ([73.100.16.189]) by comcast with SMTP id O8kMbibHWjdCGO8kObLytj; Fri, 15 Jul 2016 19:26:04 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u6FJQ1lL026993; Fri, 15 Jul 2016 15:26:01 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u6FJQ10T026990; Fri, 15 Jul 2016 15:26:01 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Brett Tate In-Reply-To: <57e9561c4e6df6a6219c25e05f688739@mail.gmail.com> (brett@broadsoft.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Fri, 15 Jul 2016 15:26:01 -0400 Message-ID: <87poqeu2ie.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfJIe8LquwDLn1W4Z6fHDbJroCujpWVrYayhwyHLZsAbdaGu1Z3HZx330GQhGAxnJ9uAmXfRNoKjlwhE60Oylm/8vmHKQQ0vTVTuli/qy0QezC3EAvM2z ZzJHSMQCDiJnCVARzMCNlcJg6NepF5J3zczfUHhybACSLweni1vWNRz57KAGA73i2JgH3Diaa5kXVXa9fugNAj/s7mC6GXN/3oI= Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] Declaring SIP 1.0 historic? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 19:26:08 -0000 Brett Tate writes: > Although I thought it was an excellent draft, draft-kaplan-sip-four-oh-00 > never became an RFC. > > https://tools.ietf.org/id/draft-kaplan-sip-four-oh-00.txt Ah, yes: "P2P2PSIP addresses the following issues in SIPv2: ... 9. Only Alice and Bob can make phone calls". Dale From nobody Sun Jul 17 18:10:55 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13FFB12D0A4 for ; Sun, 17 Jul 2016 18:10:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CTtJd78k58nJ for ; Sun, 17 Jul 2016 18:10:51 -0700 (PDT) Received: from resqmta-po-12v.sys.comcast.net (resqmta-po-12v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:171]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E64E912D10B for ; Sun, 17 Jul 2016 18:10:50 -0700 (PDT) Received: from resomta-po-17v.sys.comcast.net ([96.114.154.241]) by resqmta-po-12v.sys.comcast.net with SMTP id Ox4ybyLC0lHMYOx57buBx3; Mon, 18 Jul 2016 01:10:49 +0000 Received: from hobgoblin.ariadne.com ([73.100.16.189]) by comcast with SMTP id Ox55b3LCEVYJ8Ox56bljNR; Mon, 18 Jul 2016 01:10:48 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u6I1AmRO024996; Sun, 17 Jul 2016 21:10:48 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u6I1AmmJ024993; Sun, 17 Jul 2016 21:10:48 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Christer Holmberg In-Reply-To: <7594FB04B1934943A5C02806D1A2204B476A8FE6@ESESSMB208.ericsson.se> (christer.holmberg@ericsson.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Sun, 17 Jul 2016 21:10:47 -0400 Message-ID: <878twzpx7s.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfCzqtCTjW14CI5drEjUkWI3FR3BOsgmvJ6f4sZPsr6f3ZoNvsM89ZE864rgrGA4VQXDG0IewHdRmUa7AdLqqcvhtQ93d0o+fbDiXgdPXzkt598yMvEh3 XKomTpij1tpXaVAd5+9nr3BsRWsPYN9pnh+6gSa+mRM+yPyE1Ic3pPOVRIAsvm84W4uqjD/mBX5E9k2hcsGjAscZWwjBaRiuSIdMAEJsKdyLSm6WSI9ou/Wj tOVvzUSMDxbAOQjLcTE8yQ== Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] Happy Eyeballs: Outbounde - "optimized" REGISTER X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2016 01:10:53 -0000 Christer Holmberg writes: >>> REGISTER requests used for keep-alive are not always authenticated, >>> because they are not always forwarded to the registrar to begin with. >>> They are terminated by an edge/outbound proxy. >> >> I know this is done, but I have always thought it to be broken. >> >> The response to REGISTER is supposed to include *all* contacts that >> have been registered, not just those that were offered in *this* >> REGISTER. > > The edge proxy can store that information from the previous REGISTER > response it received from the registrar, and include it in the > REGISTER responses it triggers itself. It anyway needs to keep track > of the registration, to make sure some REGISTER requests *are* > forwarded towards the registrar (in order for the registration to not > expire). If the edge proxy has the information to provide correct responses to the REGISTER request, then there's no problem. Of course, that requires that the edge proxy arranges to be updated by the registrar with whatever changes it needs to know. I do wonder whether it would be possible for the UA to send a REGISTER with Max-Forwards: 0 as a keep-alive. The edge proxy could then reply with a 483 without needing to know any registration information, and would be totally correct. Dale From nobody Sun Jul 17 18:20:25 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEC7112D10B for ; Sun, 17 Jul 2016 18:20:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5_VsqjSm-PXB for ; Sun, 17 Jul 2016 18:20:23 -0700 (PDT) Received: from resqmta-ch2-04v.sys.comcast.net (resqmta-ch2-04v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57D9812D0A4 for ; Sun, 17 Jul 2016 18:20:23 -0700 (PDT) Received: from resomta-ch2-17v.sys.comcast.net ([69.252.207.113]) by resqmta-ch2-04v.sys.comcast.net with SMTP id OxE9bGivL8PeaOxEMbNZKd; Mon, 18 Jul 2016 01:20:22 +0000 Received: from hobgoblin.ariadne.com ([73.100.16.189]) by comcast with SMTP id OxEKbgz7HTXV7OxEKbFqXM; Mon, 18 Jul 2016 01:20:22 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u6I1KKSB025817; Sun, 17 Jul 2016 21:20:20 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u6I1KJ9E025814; Sun, 17 Jul 2016 21:20:19 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: "Olle E. Johansson" In-Reply-To: <28524A52-0665-4472-9A32-4328E45CD62E@edvina.net> (oej@edvina.net) Sender: worley@ariadne.com (Dale R. Worley) Date: Sun, 17 Jul 2016 21:20:19 -0400 Message-ID: <874m7npwrw.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfPRiPpVqJIP3wBAs/TZ1D01RYVYZO+NYl4AydlhKnTCEe+4SoGMWptPYQD/V1r2lAOX7nUnF717KaOJBDcLqkcyY9a/7ZFZlUDZgsnV/h6urIl6a6Tuy JP60YsL9ccYKDl56CfMTJ8NBouyKdCe5AHEYX85UM+W6IzNIFqdKPO++otzwX8k6IZwJ57IadtA3udZo0Aj5VQUTYqkEjF+v6KerLrD0RcvdqiRgKjbFDDL0 SHTERPfqj53WR7hF1cuwkg== Archived-At: Cc: sipcore@ietf.org, oej@edvina.net Subject: Re: [sipcore] Happy Eyeballs: Outbounde - "optimized" REGISTER X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2016 01:20:24 -0000 "Olle E. Johansson" writes: > Even using OPTIONs for keepalives may generate problems considering a > SIP implementation that use OPTIONs for discovery. > > In the case of Asterisk OPTIONs are answered blindly. But INVITEs are > authenticated and generated depending upon whether we have a > configuration for that particular user. > > This means that OPTIONs and INVITEs have different responses. If the > UA use the OPTIONs answer (including SDP) for discovery, the result is > all wrong... If OPTIONS (don't forget the S!) has Max-Forwards: 0, then an edge proxy will give a 483 response, which is completely correct. I think you're talking about the case where OPTIONS reaches a central proxy, but that proxy would reject an INVITE from the same UA. RFC 3261 section 11.2 seems to be aware that a proxy cannot handle OPTIONS in exactly the same way as an INVITE: This use of OPTIONS has limitations due to the differences in proxy handling of OPTIONS and INVITE requests. While a forked INVITE can result in multiple 200 (OK) responses being returned, a forked OPTIONS will only result in a single 200 (OK) response, since it is treated by proxies using the non-INVITE handling. See Section 16.7 for the normative details. If the response to an OPTIONS is generated by a proxy server, the proxy returns a 200 (OK), listing the capabilities of the server. The response does not contain a message body. Allow, Accept, Accept-Encoding, Accept-Language, and Supported header fields SHOULD be present in a 200 (OK) response to an OPTIONS request. If the response is generated by a proxy, the Allow header field SHOULD be omitted as it is ambiguous since a proxy is method agnostic. Contact header fields MAY be present in a 200 (OK) response and have the same semantics as in a 3xx response. That is, they may list a set of alternative names and methods of reaching the user. A Warning header field MAY be present. Other than connectivity, in what way can an OPTIONS to a proxy be used for discovery? Christer Holmberg wrote: > >For keepalives - I would use what's describe in section 4.4 of RFC > >5626, regardless of if I follow outbound or not. CRLF or STUN. > > The negotiation and usage of those, without outbound, is described in RFC > 6223. > > https://tools.ietf.org/rfc/rfc6223.txt Thanks for mentioning that! I wasn't aware of it. Dale From nobody Sun Jul 17 18:37:41 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 423A812D144 for ; Sun, 17 Jul 2016 18:37:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eG9rdM7dSY1F for ; Sun, 17 Jul 2016 18:37:39 -0700 (PDT) Received: from resqmta-ch2-11v.sys.comcast.net (resqmta-ch2-11v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 027F912D0A4 for ; Sun, 17 Jul 2016 18:37:38 -0700 (PDT) Received: from resomta-ch2-07v.sys.comcast.net ([69.252.207.103]) by resqmta-ch2-11v.sys.comcast.net with SMTP id OxUrb4WX7lSxsOxV4bTlw6; Mon, 18 Jul 2016 01:37:38 +0000 Received: from hobgoblin.ariadne.com ([73.100.16.189]) by comcast with SMTP id OxV3bpt745DmeOxV3boqFC; Mon, 18 Jul 2016 01:37:38 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u6I1bbCr027374; Sun, 17 Jul 2016 21:37:37 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u6I1bbsc027371; Sun, 17 Jul 2016 21:37:37 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Roman Shpount In-Reply-To: (roman@telurix.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Sun, 17 Jul 2016 21:37:37 -0400 Message-ID: <871t2rpvz2.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfJynF72muoP2kkGWFZ7lYGFUQOuERfUkU+M57H5RxbC6Qu62VjtFL6lt4ao92K5I63vpJ5/Ah0bGizfvD3gqzepDZq6C8sEG7odSOGhlycVFj022mn+P 6rAq6ASAt3Tp+GQb+Y1PwxHuTbIQKr6snGN+nwmgK0gv1YlVuvhejzrx2pvjO7XJE7dODb2wugPWmxQOUBfeEf5yOuPepLl8PpA= Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] Happy Eyeballs: Outbounde X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2016 01:37:40 -0000 Roman Shpount writes: >> > 5. One of the big problems with encrypted SIP traffic is that it >> > gets modified by ALG. For a lot of hosted PBX providers avoiding >> > the need to troubleshoot customer routers is a bigger incentive to >> > deploy TLS [than] user privacy. >> >> If I understand you correctly, hosted PBX providers favor TLS to stop >> routers from modifying SIP messages. But ALGs terminate TLS ... and >> then modify the SIP messages. >> > One of the big problems with deploying SIP on customer premises are SIP ALG > implemented by the consumer routers. Such ALG are typically broken and > cause SIP call setup failures or call drops. If client equipment is using > SIP over TLS, SIP ALG in routers cannot affect the signaling and SIP > message pass the router unmolested. Because of this, SIP calls over TLS are > much more stable which results in big reduction of customer problems and > associated support calls. This reduction in support burden is a much bigger > incentive for service providers to deploy encryption for SIP then customer > privacy (which, in practice, is almost never their concern). We'll have to remember this as a design point. However this does mean that the UAs need to know the edge proxy's certificate, so the ALG can't terminate TLS. Dale From nobody Sun Jul 17 19:21:57 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 964DB12D0C5 for ; Sun, 17 Jul 2016 19:21:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f5wbCfgv_Svw for ; Sun, 17 Jul 2016 19:21:53 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8061112B076 for ; Sun, 17 Jul 2016 19:21:53 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id f6so58486004ith.1 for ; Sun, 17 Jul 2016 19:21:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/hL8DN3vYwve5N+qGFL7MofJwWajRm6++FqAb7W9208=; b=RjoRgjnYHn0Rtv8i1ZiCr1Up6iPfMsIpijdEqvuRvTxoToPM4KDEtCA01wkFQJOjz/ aL7Ki2cgg3l6tV3hl9f2acXUyENXnGGS2SFPV2sqRNPo017BRjM9DflBNZUCvTlgMgyy 1PtNqdWuUgvJyhDQq7N4HT3EdYxE653v3sTGM6FGzH7aUVs7cG5bKVa/sx6wsZMvciaL S3wIOba26Ywn/xFS5BjKZoA5YauoM8KsHdmEVhwD5aX5qc0kPaX47IvvKDwieyrRV4v1 16xhW9ZEjFTWHGJAVZuE4j+EcMZLfuSO6H838nYzNejjBm0XNCowFKdApqa28nGZTiM2 zVnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/hL8DN3vYwve5N+qGFL7MofJwWajRm6++FqAb7W9208=; b=LYIg20cCxKjUlAWqDJHJnHcEbnZLcZJpNcSCIRFK1DknYExS4c4ihPs+f0GLFYB77o GXMPfCej+BqhMHP3o8+IXEapOwDzH5idj66pw7vM1qE1DJPxZGfpbLWu2OKLIg+dJWsb nIhE0bjzv1ndR03QTg5jKNQhXP41F+pfEds7KYmRIw4/W2HUpJXqv2vz25XAGAPFaS4W c4mrtC167SFmuFr1EJfu6R6EWojBxFEHFDGPqCEFzGbwrdGsqpb4k2kPKe3IJk/A2GYx qepXn4Wq/92d9zXvTwGiivLl3/o3kQwTHG5rqPW+cW/h8tAe/KRRZtDh/zJsOgBj3GcJ 5ADA== X-Gm-Message-State: ALyK8tKMBxDLXNS2JIAkjlWhamr7SNIEgzaXj31BZl1ugYhP6PVSF+IFXTWklSyyEmrn7Q== X-Received: by 10.36.207.214 with SMTP id y205mr48589047itf.37.1468808512661; Sun, 17 Jul 2016 19:21:52 -0700 (PDT) Received: from mail-io0-f172.google.com (mail-io0-f172.google.com. [209.85.223.172]) by smtp.gmail.com with ESMTPSA id e63sm3891181ith.0.2016.07.17.19.21.51 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 17 Jul 2016 19:21:51 -0700 (PDT) Received: by mail-io0-f172.google.com with SMTP id 38so148559163iol.0 for ; Sun, 17 Jul 2016 19:21:51 -0700 (PDT) X-Received: by 10.107.130.39 with SMTP id e39mr15723772iod.66.1468808511272; Sun, 17 Jul 2016 19:21:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.62.139 with HTTP; Sun, 17 Jul 2016 19:21:50 -0700 (PDT) In-Reply-To: <871t2rpvz2.fsf@hobgoblin.ariadne.com> References: <871t2rpvz2.fsf@hobgoblin.ariadne.com> From: Roman Shpount Date: Sun, 17 Jul 2016 22:21:50 -0400 X-Gmail-Original-Message-ID: Message-ID: To: "Dale R. Worley" Content-Type: multipart/alternative; boundary=001a113ec7ec8ec0b60537dfa125 Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] Happy Eyeballs: Outbounde X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2016 02:21:55 -0000 --001a113ec7ec8ec0b60537dfa125 Content-Type: text/plain; charset=UTF-8 On Sun, Jul 17, 2016 at 9:37 PM, Dale R. Worley wrote: > Roman Shpount writes: > >> > 5. One of the big problems with encrypted SIP traffic is that it > >> > gets modified by ALG. For a lot of hosted PBX providers avoiding > >> > the need to troubleshoot customer routers is a bigger incentive to > >> > deploy TLS [than] user privacy. > >> > >> If I understand you correctly, hosted PBX providers favor TLS to stop > >> routers from modifying SIP messages. But ALGs terminate TLS ... and > >> then modify the SIP messages. > >> > > One of the big problems with deploying SIP on customer premises are SIP > ALG > > implemented by the consumer routers. Such ALG are typically broken and > > cause SIP call setup failures or call drops. If client equipment is using > > SIP over TLS, SIP ALG in routers cannot affect the signaling and SIP > > message pass the router unmolested. Because of this, SIP calls over TLS > are > > much more stable which results in big reduction of customer problems and > > associated support calls. This reduction in support burden is a much > bigger > > incentive for service providers to deploy encryption for SIP then > customer > > privacy (which, in practice, is almost never their concern). > > We'll have to remember this as a design point. > > However this does mean that the UAs need to know the edge proxy's > certificate, so the ALG can't terminate TLS. > UA do not need to know the edge proxy's certificate. This certificate can be verified against the well known certificate authorities, similar to how HTTPS web site certificates are verified. This works unless end user specifically added ALG's certificate to the list of CAs on the UA, which is typically not done. _____________ Roman Shpount --001a113ec7ec8ec0b60537dfa125 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sun, Jul 17, 2016 at 9:37 PM, Da= le R. Worley <worley@ariadne.com> wrote:
<= span class=3D"">Roman Shpount <roma= n@telurix.com> writes:
>> > 5. One of the big problems with encrypted SIP traffic is that= it
>> > gets modified by ALG. For a lot of hosted PBX providers avoid= ing
>> > the need to troubleshoot customer routers is a bigger incenti= ve to
>> > deploy TLS [than] user privacy.
>>
>> If I understand you correctly, hosted PBX providers favor TLS to s= top
>> routers from modifying SIP messages.=C2=A0 But ALGs terminate TLS = ... and
>> then modify the SIP messages.
>>
> One of the big problems with deploying SIP on customer premises are SI= P ALG
> implemented by the consumer routers. Such ALG are typically broken and=
> cause SIP call setup failures or call drops. If client equipment is us= ing
> SIP over TLS, SIP ALG in routers cannot affect the signaling and SIP > message pass the router unmolested. Because of this, SIP calls over TL= S are
> much more stable which results in big reduction of customer problems a= nd
> associated support calls. This reduction in support burden is a much b= igger
> incentive for service providers to deploy encryption for SIP then cust= omer
> privacy (which, in practice, is almost never their concern).

We'll have to remember this as a design point.

However this does mean that the UAs need to know the edge proxy's
certificate, so the ALG can't terminate TLS.

<= /div>
UA do not need to know the edge proxy's certificate. This cer= tificate can be verified against the well known certificate authorities, si= milar to how HTTPS web site certificates are verified. This works unless en= d user specifically added ALG's certificate to the list of CAs on the U= A, which is typically not done.=C2=A0
_____________
Roman Shpount
=
=C2=A0
--001a113ec7ec8ec0b60537dfa125-- From nobody Mon Jul 18 17:33:15 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BE2D12DB3C for ; Mon, 18 Jul 2016 17:33:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.288 X-Spam-Level: X-Spam-Status: No, score=-3.288 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jhcloos.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fASZTkV1QvR0 for ; Mon, 18 Jul 2016 17:33:10 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [IPv6:2604:2880::b24d:a297]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC87512DAF5 for ; Mon, 18 Jul 2016 17:33:10 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id C61691DF35; Tue, 19 Jul 2016 00:33:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1468888388; bh=QV0xOrvIaSRy/RcW3SAoR4O792tST2qERoON0NOk3YQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=Tz39ZtA6JBDj3IQeh7Wp8qavGMJWb77+2SNz6CVaZ01Sy98ZdmYSY3hMtA4XeEY+v u5Bat45Nh8OZ+pCuFnilbX+j3XVLThOnCR0kkk6olK+0HQAa3Bb+l6mcxFOPU1FdYd R6oBtJNAjJ/NZR9R/8tNXsWZloE1dcxvW6erFvnw= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 31EB9107B7BE1; Tue, 19 Jul 2016 00:32:08 +0000 (UTC) From: James Cloos To: Roman Shpount In-Reply-To: (Roman Shpount's message of "Sun, 17 Jul 2016 22:21:50 -0400") References: <871t2rpvz2.fsf@hobgoblin.ariadne.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2016 James Cloos OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Mon, 18 Jul 2016 20:32:08 -0400 Message-ID: Lines: 18 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:28:160719:roman@telurix.com::N9YFlhwhIo6Cr0aQ:0000000000000000000000000000000000000000000DrQWi X-Hashcash: 1:28:160719:worley@ariadne.com::ul21Of2X9HJy12Tt:0000000000000000000000000000000000000000004HimY X-Hashcash: 1:28:160719:sipcore@ietf.org::8n9VU/C82Mkg9jQ/:36PuT Archived-At: Cc: "Dale R. Worley" , sipcore@ietf.org Subject: Re: [sipcore] Happy Eyeballs: Outbounde X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 00:33:14 -0000 >>>>> "RS" == Roman Shpount writes: RS> UA do not need to know the edge proxy's certificate. This certificate can RS> be verified against the well known certificate authorities, similar to how RS> HTTPS web site certificates are verified. Most sip software I've looked at also supports not verifying the certs at all. If the only reason for using tls is to avoid mangling by the edge routers, then at least in the short term (next few years, before the edge router manufactures catch on) tls w/o auth would get the job done. Of course w/ auth is nicer, and letsencrypt makes that essentially free (just the labor cost of setting it up). -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Mon Jul 18 21:07:21 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C54712DC4A for ; Mon, 18 Jul 2016 21:07:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NxjOk6-IALzE for ; Mon, 18 Jul 2016 21:07:17 -0700 (PDT) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D14212DC3B for ; Mon, 18 Jul 2016 21:07:17 -0700 (PDT) Received: by mail-oi0-x22c.google.com with SMTP id w18so9094379oiw.3 for ; Mon, 18 Jul 2016 21:07:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IHUYoillKB8zhjoADILOhlmEwQExGxwt1GZp65o0p/o=; b=M3kPGaVMVrucI2SDHrUxiQp5pB+20e+WidwuHEO6/IwJoV6cThiGBsAGFFV7lA6304 6aWgUS6GSWWWTHQJ/O8AoasfmaT6S8tXQYnTr6qe+T4gQC5CDqDTzEADJo1KqYfvL9V3 MDwk+SS3RnX/KF3bX/Quyl1tBeFajuF/p8qCs6IePZ/kok1FYx8WIfIXFP5IwW3CFR+S CAeof5gyLCOrfFOkEKpALgh3u/nw1anScaPdpGAtTj7lVBIc6ylVGEoBMwJno0mHBiPD N2RDGDbLd+1563jZ9tcLvEr4w1bWi0xUQMAfjV3CbW8qzDNRM6XoXEimJX2QYXukBc5J X23w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IHUYoillKB8zhjoADILOhlmEwQExGxwt1GZp65o0p/o=; b=KXmATHDpEd1eWVeWYUlGBkp4NK6pwLkeiYjkTq0Feh1/txzc1fq/8uRxkxWSRkY6jq l36n84gB6Q5DZrwdlntiI6+9Uj7kaIHJdO020lQ21P2FSWgVVOezzRgDNUmH8olEmnyV bt+K/VCtt8Sq+o0H+/jXowV4J7OzHAmIEgnx+S87t1UvSrN5u7tkW0NH2vfCcirLLfdv 39UefNI46vRjXGn2RjHDldZriZho6Y4280hzOJjDJpBKq5gOPTtXPcMaHAY4Xq1noLfz j+HZEncHNs5+V1cVBpnhCxRgEEAO71f1iGtiDLZ1920ZfoBQTKaSGPZLLu2+afPkciXr NLNQ== X-Gm-Message-State: ALyK8tKNjKEyrKsf1Th7tcXAxIG1JdM1FvA8zpggKox5pfCn4s58pAyfDPxLvN7BW7Gbb/hFAv9M1NEZ9r05iQ== X-Received: by 10.157.1.214 with SMTP id e80mr23232529ote.141.1468901236640; Mon, 18 Jul 2016 21:07:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.13.52 with HTTP; Mon, 18 Jul 2016 21:07:15 -0700 (PDT) In-Reply-To: References: <8760sia0vv.fsf@hobgoblin.ariadne.com> From: Muthu Arul Mozhi Perumal Date: Tue, 19 Jul 2016 06:07:15 +0200 Message-ID: To: Roman Shpount Content-Type: multipart/alternative; boundary=94eb2c03ba046b93090537f538d3 Archived-At: Cc: "Dale R. Worley" , sipcore@ietf.org Subject: Re: [sipcore] Happy Eyeballs: Outbounde X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 04:07:19 -0000 --94eb2c03ba046b93090537f538d3 Content-Type: text/plain; charset=UTF-8 Consumer routers deploy SIP ALG to mainly fix the address/port in SDP to enable media to traverse consumer the NAT, right? Are we saying consumer endpoints are already doing ICE, so making those ALGs non-functional as a result of doing SIP over TLS wouldn't be an issue? thanks, Muthu On Wed, Jul 13, 2016 at 10:44 PM, Roman Shpount wrote: > > On Wed, Jul 6, 2016 at 5:54 PM, Dale R. Worley wrote: > >> Thanks for the information! I've added your discussion to the rough >> draft. >> >> Roman Shpount writes: >> > Few observations: >> > [...] >> > 3. For server, the most efficient way to keep the NAT hole open is to >> send >> > OPTIONS or NOTIFY requests to the client. This is much more efficient >> then >> > registrations with small timeouts. >> > >> > 4. Registration server which has an in-memory database for current >> > registrations can be fairly efficient in reducing number of back-end DB >> > updates due to registrations and subscriptions with small timeouts. It >> is >> > not going to be stateless, but its state does not need to be replicated >> and >> > would automatically recover on the stand-by server on the next >> registration >> > or subscription request from the client. >> >> I think what you are saying here is that if the server sends >> OPTIONS/NOTIFY for keepalive, rather than making the client send >> frequent re-REGISTERS, then the server doesn't need to record the timers >> for the keepalives in persistent storage -- if the stand-by server is >> activated, it simply sends keepalives to all registrations that are >> recorded as having keepalive service. In the long run, this requires no >> more processing by the registration server and far less demand on the >> persistent storage. >> >> Is that correct? >> > > This is correct. Since OPTIONS/NOTIFY do not update the registration state > they typically require less resources then forcing the client to > re-register at the small interval. Registrations typically require > authentication and cause the shared storage update for the expiration time. > OPTIONS/NOTIFY sent from server require not of this. > >> >> > 5. One of the big problems with encrypted SIP traffic is that it gets >> > modified by ALG. For a lot of hosted PBX providers avoiding the need to >> > troubleshoot customer routers is a bigger incentive to deploy TLS then >> user >> > privacy. >> >> If I understand you correctly, hosted PBX providers favor TLS to stop >> routers from modifying SIP messages. But ALGs terminate TLS ... and >> then modify the SIP messages. >> >> > One of the big problems with deploying SIP on customer premises are SIP > ALG implemented by the consumer routers. Such ALG are typically broken and > cause SIP call setup failures or call drops. If client equipment is using > SIP over TLS, SIP ALG in routers cannot affect the signaling and SIP > message pass the router unmolested. Because of this, SIP calls over TLS are > much more stable which results in big reduction of customer problems and > associated support calls. This reduction in support burden is a much bigger > incentive for service providers to deploy encryption for SIP then customer > privacy (which, in practice, is almost never their concern). > _____________ > Roman Shpount > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > --94eb2c03ba046b93090537f538d3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Consumer routers deploy SIP ALG to main= ly fix the address/port in SDP to enable media to traverse consumer the NAT= , right? Are we saying consumer endpoints are already doing ICE, so making = those ALGs non-functional as a result of doing SIP over TLS wouldn't be= an issue?

thanks,
Muthu

On Wed, Jul 13, 2016 at 10:44 PM, Roman Shpount <roman@t= elurix.com> wrote:

On Wed, Jul 6, 2016 at 5:54 PM, Dale R. Worley <= span dir=3D"ltr"><worley@ariadne.com> wrote:
Thanks for the information!=C2=A0 I've added your discussion= to the rough
draft.

Roman Shpount <ro= man@telurix.com> writes:
> Few observations:
> [...]
> 3. For server, the most efficient way to keep the NAT hole open = is to send
> OPTIONS or NOTIFY requests to the client. This is much more efficient = then
> registrations with small timeouts.
>
> 4. Registration server which has an in-memory database for current
> registrations can be fairly efficient in reducing number of back-end D= B
> updates due to registrations and subscriptions with small timeouts. It= is
> not going to be stateless, but its state does not need to be replicate= d and
> would automatically recover on the stand-by server on the next registr= ation
> or subscription request from the client.

I think what you are saying here is that if the server sends
OPTIONS/NOTIFY for keepalive, rather than making the client send
frequent re-REGISTERS, then the server doesn't need to record the timer= s
for the keepalives in persistent storage -- if the stand-by server is
activated, it simply sends keepalives to all registrations that are
recorded as having keepalive service.=C2=A0 In the long run, this requires = no
more processing by the registration server and far less demand on the
persistent storage.

Is that correct?

This is correct= . Since OPTIONS/NOTIFY do not update the registration state they typically = require less resources then forcing the client to re-register at the small = interval. Registrations typically require authentication and cause the shar= ed storage update for the expiration time. OPTIONS/NOTIFY sent from server = require not of this.

> 5. One of the big problems with encrypted SIP traffic is that it gets<= br> > modified by ALG. For a lot of hosted PBX providers avoiding the need t= o
> troubleshoot customer routers is a bigger incentive to deploy TLS then= user
> privacy.

If I understand you correctly, hosted PBX providers favor TLS to sto= p
routers from modifying SIP messages.=C2=A0 But ALGs terminate TLS ... and then modify the SIP messages.


One of the big problems with deploying SIP on customer premise= s are SIP ALG implemented by the consumer routers. Such ALG are typically b= roken and cause SIP call setup failures or call drops. If client equipment = is using SIP over TLS, SIP ALG in routers cannot affect the signaling and S= IP message pass the router unmolested. Because of this, SIP calls over TLS = are much more stable which results in big reduction of customer problems an= d associated support calls. This reduction in support burden is a much bigg= er incentive for service providers to deploy encryption for SIP then custom= er privacy (which, in practice, is almost never their concern).=C2=A0
=
_____________
Roman Shpount
=C2=A0

_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore


--94eb2c03ba046b93090537f538d3-- From nobody Tue Jul 19 08:57:38 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96A4D12D8D9 for ; Tue, 19 Jul 2016 08:57:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uZbDf6bWDQZt for ; Tue, 19 Jul 2016 08:57:33 -0700 (PDT) Received: from resqmta-ch2-11v.sys.comcast.net (resqmta-po-11v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:170]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EFC612DA0D for ; Tue, 19 Jul 2016 08:47:03 -0700 (PDT) Received: from resomta-po-08v.sys.comcast.net ([96.114.154.232]) by resqmta-po-11v.sys.comcast.net with SMTP id PXCtbVlfdEp5XPXEbbCad6; Tue, 19 Jul 2016 15:47:01 +0000 Received: from hobgoblin.ariadne.com ([73.100.16.189]) by comcast with SMTP id PXEabGi3cK5fjPXEabeJSS; Tue, 19 Jul 2016 15:47:01 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u6JFkxPi021503; Tue, 19 Jul 2016 11:46:59 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u6JFkxa6021500; Tue, 19 Jul 2016 11:46:59 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Muthu Arul Mozhi Perumal In-Reply-To: (muthu.arul@gmail.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Tue, 19 Jul 2016 11:46:59 -0400 Message-ID: <87zipdljf0.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfC6SeFvOGIF72smlR71o6a9ZBXP4NOFOYlrP6IjYwV8gXs6gQrt6YQ3/pNSl4pGu9ZqDZRKmn5qIHoTj+yHfnkgFbUvdq498H4kFcwriz59Lug9/sOlX iixBHgRhQ8DliibL17NoxtrC4EFfP/+ZxF5J1grQtbhi9apnq7v0sWNA4b4P+MXLsWctwAhJBJGj3IVCzPhp6n8Z1MDehr8DpAHEER+iGoiozWUxOKLkzC/n Archived-At: Cc: sipcore@ietf.org, roman@telurix.com Subject: Re: [sipcore] Happy Eyeballs: Outbounde X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 15:57:34 -0000 Muthu Arul Mozhi Perumal writes: > Consumer routers deploy SIP ALG to mainly fix the address/port in SDP to > enable media to traverse consumer the NAT, right? Are we saying consumer > endpoints are already doing ICE, so making those ALGs non-functional as a > result of doing SIP over TLS wouldn't be an issue? That's the idea: The UA should use Outbound to keep a NAT binding, and ICE to negotiate media ports. Looking at the SIPit 31 summary (https://www.sipit.net/SIPit31_summary), 44% of endpoints support ICE, whereas only 28% support outbound. Dale From nobody Tue Jul 19 09:10:23 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AB1712D762 for ; Tue, 19 Jul 2016 09:10:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6TR0W5OkWSyz for ; Tue, 19 Jul 2016 09:10:20 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E02EB12D908 for ; Tue, 19 Jul 2016 09:02:43 -0700 (PDT) X-AuditID: c1b4fb2d-f79936d0000030e4-b3-578e4f210d4c Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id F6.D4.12516.12F4E875; Tue, 19 Jul 2016 18:02:42 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.208]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0294.000; Tue, 19 Jul 2016 18:02:18 +0200 From: Christer Holmberg To: "Dale R. Worley" , Muthu Arul Mozhi Perumal Thread-Topic: [sipcore] Happy Eyeballs: Outbounde Thread-Index: AQHR4dTIDNW4SmEaHk2is1leOoM+uqAf6alA Date: Tue, 19 Jul 2016 16:02:18 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B476D7C24@ESESSMB209.ericsson.se> References: (muthu.arul@gmail.com) <87zipdljf0.fsf@hobgoblin.ariadne.com> In-Reply-To: <87zipdljf0.fsf@hobgoblin.ariadne.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJIsWRmVeSWpSXmKPExsUyM2K7t66Sf1+4wZu5PBZ/NvtZzLgwldni 649NbBYvT5Q5sHhM3v+V2WPnrLvsHkuW/GTyuDWlIIAlissmJTUnsyy1SN8ugStj+sVdzAXH OSsublnP2MD4nb2LkZNDQsBE4sPHmYwQtpjEhXvr2boYuTiEBI4wSnxYNxvKWcIo8eXeKuYu Rg4ONgELie5/2iCmiECMxOf1QSC9zAIhEhvuPWcCsYUFDCSWTdjFAmKLCBhKXG9ZzgRhG0nM 7m0Es1kEVCVeXpkHVsMr4Ctxq/MaO8SqCYwSJw9MAzuOU8BYYvapi2DHMQId9/3UGiaIZeIS t57MZ4I4WkBiyZ7zzBC2qMTLx/9YIWwliUW3P0PV60gs2P2JDcLWlli28DUzxGJBiZMzn7BM YBSbhWTsLCQts5C0zELSsoCRZRWjaHFqcXFuupGxXmpRZnJxcX6eXl5qySZGYIQd3PJbdwfj 6teOhxgFOBiVeHgVJHvDhVgTy4orcw8xSnAwK4nwznfpCxfiTUmsrEotyo8vKs1JLT7EKM3B oiTO6/9SMVxIID2xJDU7NbUgtQgmy8TBKdXAaGlVmCXxc2eFgNvTE1fqff00Hip+UDvI4Bv4 pLiG7ZDFHPFXc+4GzmV8oL1kwer5BhvCzl9629ubUXWlcvKCd283HFjXym4bGnfuar2Df/YF 9uSsqCwDhXW/IkKNM/1U2OJ3CkRWty907H79kJH9p4+wvuuPHuv3d5psVR//cDu59u0Bwdf3 lViKMxINtZiLihMBaKrLm6wCAAA= Archived-At: Cc: "sipcore@ietf.org" , "roman@telurix.com" Subject: Re: [sipcore] Happy Eyeballs: Outbounde X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 16:10:22 -0000 Hi, Outbound is more than a mechanism for keeping NAT bindings open. So, before saying "let's use outbound", what exactly are the properties/fea= tures that you need? Regards, Christer -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Dale R. Worley Sent: 19 July 2016 18:47 To: Muthu Arul Mozhi Perumal Cc: sipcore@ietf.org; roman@telurix.com Subject: Re: [sipcore] Happy Eyeballs: Outbounde Muthu Arul Mozhi Perumal writes: > Consumer routers deploy SIP ALG to mainly fix the address/port in SDP=20 > to enable media to traverse consumer the NAT, right? Are we saying=20 > consumer endpoints are already doing ICE, so making those ALGs=20 > non-functional as a result of doing SIP over TLS wouldn't be an issue? That's the idea: The UA should use Outbound to keep a NAT binding, and ICE= to negotiate media ports. Looking at the SIPit 31 summary (https://www.sipit.net/SIPit31_summary), 44% of endpoints support ICE, whereas only 28% support outbound. Dale _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From nobody Tue Jul 19 11:36:02 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4845312D50C for ; Tue, 19 Jul 2016 11:36:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rmhv5STOmf7F for ; Tue, 19 Jul 2016 11:35:58 -0700 (PDT) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 202BF12D168 for ; Tue, 19 Jul 2016 11:35:58 -0700 (PDT) Received: by mail-io0-x231.google.com with SMTP id b62so26858480iod.3 for ; Tue, 19 Jul 2016 11:35:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=87KgE/BDED4fEx0rQE1jUHRz3PythYdHI4urdRRn2Gs=; b=Z5zflY40ehBwq1oyMppxFMTsft2Vx0TspxMGSbQYapgYdiEnzk37MOTQ7C3Skir3PJ HHuKwjO3vvutRIJ3CzKBXxFeM28ylC9RxwwdHEsrNqlEwjuZ1i3u19YI8pbQ/mDTlRsd TAPVyEs32sP9VWAkyy76dDqSqirew+PEMyMirRNOHZDe3n0PuUJX8RCmcaUpItXsh++I yut6FUGLS4D6L/Q629lSqO4XAjY4aO49yefDoDT7XMJdep2yjiv48QjMzXgtKta5Ef7V 7JEo402jzdrX0s5bdgx/961TJRUKs4KFwaOr3KHQmYFrqmUEQcy9TU67L7zUOQnboiD6 Kctg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=87KgE/BDED4fEx0rQE1jUHRz3PythYdHI4urdRRn2Gs=; b=ID5iNjeVrWtFeq2KIyWNuKM46/IInmF1dAcqZffhd1Wb6PSUBlQxfiZmmYm4+lFSnb dfqmAIlduHpvXQEJKd3jOaL1JSQOgpPuugd1CDFGXDnWWZM/rxAHC6iEqZQkMKfaRsN0 Etd16dmYRfzK5sLMIuZY2BMKUd4YPQIXoVVSCn/poNI/fgpThjgKPa5BEPVTO75JPabm 1SniHBORQODqpDUj1sjv/vn34J3F3Pb18k4ya9elYRuJwKUV9KqOaQMdev7zLG55vuRw HKlffGdmsD0bSpP/Fm794GU74AeA/droFC2/wr8KkpuRpC+tnDtaPqxNJHvbm6OMkiyz IxpQ== X-Gm-Message-State: ALyK8tJmQErBJRdfDQYieaitsSwEzU0QVWmjfJxfjnDEzf2ekyKIj8Gg4sQSKKXeraXp5A== X-Received: by 10.107.142.22 with SMTP id q22mr38888063iod.37.1468953357259; Tue, 19 Jul 2016 11:35:57 -0700 (PDT) Received: from mail-it0-f49.google.com (mail-it0-f49.google.com. [209.85.214.49]) by smtp.gmail.com with ESMTPSA id 1sm8381873ion.44.2016.07.19.11.35.56 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Jul 2016 11:35:56 -0700 (PDT) Received: by mail-it0-f49.google.com with SMTP id f6so28099822ith.0 for ; Tue, 19 Jul 2016 11:35:56 -0700 (PDT) X-Received: by 10.36.23.210 with SMTP id 201mr52710981ith.18.1468953355971; Tue, 19 Jul 2016 11:35:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.62.139 with HTTP; Tue, 19 Jul 2016 11:35:55 -0700 (PDT) In-Reply-To: References: <8760sia0vv.fsf@hobgoblin.ariadne.com> From: Roman Shpount Date: Tue, 19 Jul 2016 14:35:55 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Muthu Arul Mozhi Perumal Content-Type: multipart/alternative; boundary=001a114370bef979ee0538015a13 Archived-At: Cc: "Dale R. Worley" , sipcore@ietf.org Subject: Re: [sipcore] Happy Eyeballs: Outbounde X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 18:36:00 -0000 --001a114370bef979ee0538015a13 Content-Type: text/plain; charset=UTF-8 On Tue, Jul 19, 2016 at 12:07 AM, Muthu Arul Mozhi Perumal < muthu.arul@gmail.com> wrote: > Consumer routers deploy SIP ALG to mainly fix the address/port in SDP to > enable media to traverse consumer the NAT, right? Are we saying consumer > endpoints are already doing ICE, so making those ALGs non-functional as a > result of doing SIP over TLS wouldn't be an issue? > > What I am saying is that most consumer routers include ALG code which is broken. This code is supposed to update IP addresses in SIP Via and Contact as well as in SDP. It is also supposed to setup packet forwarding between public IP/port to the NATed IP/port. In reality, code in most of the routers is so bad that the person who wrote it most likely needs to change profession to avoid spreading future misery. Not doing anything to SIP on the router in combination with ICE or server side NAT traversal works much better then SIP ALG. There is almost never a reason to have SIP ALG enabled unless you are using a very restrictive firewall. For more information you can google "SIP ALG are evil" or read any of the following: https://support.onsip.com/hc/en-us/articles/204514014-NAT-and-Firewall-Traversal-Recommendation http://support.phone.com/hc/en-us/articles/204162770-Do-I-Have-To-Change-My-Network-Settings-or-Hardware- http://www.whichvoip.com/disable-sip-alg.htm Look at the number of routers where SIP ALG needs to be disabled: http://businesssupport.vonage.com/app/answers/detail/a_id/21546/~/network-equipment-compatibility You can probably find a similar article for every hosted VoIP provider. Regards, _____________ Roman Shpount --001a114370bef979ee0538015a13 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Jul 19, 2016 at 12:07 AM, M= uthu Arul Mozhi Perumal <muthu.arul@gmail.com> wrote:
=
Consumer routers deploy SIP ALG to mainly fix the= address/port in SDP to enable media to traverse consumer the NAT, right? A= re we saying consumer endpoints are already doing ICE, so making those ALGs= non-functional as a result of doing SIP over TLS wouldn't be an issue?=


What I am saying is that = most consumer routers include ALG code which is broken. This code is suppos= ed to update IP addresses in SIP Via and Contact as well as in SDP. It is a= lso supposed to setup packet forwarding between public IP/port to the NATed= IP/port. In reality, code in most of the routers is so bad that the person= who wrote it most likely needs to change profession to avoid spreading fut= ure misery. Not doing anything to SIP on the router in combination with ICE= or server side NAT traversal works much better then SIP ALG. There is almo= st never a reason to have SIP ALG enabled unless you are using a very restr= ictive firewall.=C2=A0

For more information you ca= n google "SIP ALG are evil" or read any of the following:




Look at the number of router= s where SIP ALG needs to be disabled:

You can pro= bably find a similar article for every hosted VoIP provider.

=
Regards,
_____________
Roman Shpount
=C2=A0<= /div>
--001a114370bef979ee0538015a13-- From nobody Tue Jul 19 11:45:18 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AE2B12D0A7 for ; Tue, 19 Jul 2016 11:45:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8G_tKTyKTAOs for ; Tue, 19 Jul 2016 11:45:15 -0700 (PDT) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DF9712D0A8 for ; Tue, 19 Jul 2016 11:45:15 -0700 (PDT) Received: by mail-it0-x22f.google.com with SMTP id u186so99125756ita.0 for ; Tue, 19 Jul 2016 11:45:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=iUARV9PRqPiDX7isPbNRhZ5iGKtFIsbhs0JozBakR2k=; b=E6WXbcPG7+CMkJz+SfVJm/l8kbKJiJhtz+PDKma+UHyBezHsid9LilYwtQa0yU03rP kcx7gR+lMOyAcPUA47OxOIoWOLmCXiPpzPO78AYsk49znJ+rFTAmC3mwVS8LCAgUuDCl /70cvH+gbkLFjr2vkb3ofu412AqXHLa62ogFw5Ez+U61fjLlkq7tLovSe+kwrXR+x1bS 8A6iNHJ6VOVsNMuimxz7BvcJC/TPsRgNIWxnE4DnpavwyxBqu5O6kp7gjcU9d7gs9/Nq eSq+25LwmnTdii9KElFw62VsnCHsVQrGfiueeL/zE5pqE/RldoXcgHH1D4gO+/USHGZz rG6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=iUARV9PRqPiDX7isPbNRhZ5iGKtFIsbhs0JozBakR2k=; b=YTRqvgoA+3O423jgPZlSpZXC9gjA4e+tz8APQTZ2F5PYyRkjzd+GhQf2mHTJzZC6qc UZlJGCfcPS94eItEufT3cE8+B47/xw60CN83An36NfRIh0U1Oe7Zn2Fmd09SpRC/ddJn smtQDEl4mvTi4ZN/Z99gq+xZN7133uOHD8tP4xe6ojX/YQLC4G4lilJTqo9qy3Rg2iOE MjTVEKO8Ful2Z06T1u/vpDYLNFOWzHqdYgTF4iB5ZnI7LI+f+aGgldnvdoWHKrVzsKp+ +sXfJKxSsyDvHqcDWBG4lMqUuLu+os0NNBIJXsh0QjF+jzSivh++GCIGExgRpNU8TZ9z p0JA== X-Gm-Message-State: ALyK8tJwlRPbace4pf3NNr27vX1BUs3oN43fH1wrj8fnRMtoLhBoLTsUcA9EDvco2Lpwqw== X-Received: by 10.36.46.136 with SMTP id i130mr5321335ita.62.1468953914525; Tue, 19 Jul 2016 11:45:14 -0700 (PDT) Received: from mail-io0-f182.google.com (mail-io0-f182.google.com. [209.85.223.182]) by smtp.gmail.com with ESMTPSA id 4sm7110624itw.4.2016.07.19.11.45.13 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Jul 2016 11:45:13 -0700 (PDT) Received: by mail-io0-f182.google.com with SMTP id m101so27136972ioi.2 for ; Tue, 19 Jul 2016 11:45:13 -0700 (PDT) X-Received: by 10.107.128.210 with SMTP id k79mr33512396ioi.3.1468953913207; Tue, 19 Jul 2016 11:45:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.62.139 with HTTP; Tue, 19 Jul 2016 11:45:12 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B476D7C24@ESESSMB209.ericsson.se> References: <87zipdljf0.fsf@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B476D7C24@ESESSMB209.ericsson.se> From: Roman Shpount Date: Tue, 19 Jul 2016 14:45:12 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a113f8aae3056400538017c4f Archived-At: Cc: Muthu Arul Mozhi Perumal , "Dale R. Worley" , "sipcore@ietf.org" Subject: Re: [sipcore] Happy Eyeballs: Outbounde X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 18:45:17 -0000 --001a113f8aae3056400538017c4f Content-Type: text/plain; charset=UTF-8 On Tue, Jul 19, 2016 at 12:02 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Outbound is more than a mechanism for keeping NAT bindings open. > > So, before saying "let's use outbound", what exactly are the > properties/features that you need? > I have mentioned this in another thread but Happy Eyeballs do not need to have anything to do with SIP Outbound. Main connection that I do see is using SIP Outbound Keep-Alive messages to detect the working flow for SIP messages when multiple local networks or multiple SIP Edge proxy addresses are available. I have also mentioned that this is not the only solution for Happy Eyeballs, since figuring out rules for sending messages in the same SIP transaction across multiple flows can serve as an alternative, and possibly better, solution. Obviously, if we restrict SIP to TLS only as the only acceptable protocol for Happy Eyeballs, then SIP Outbound is the only standard solution which attempts to describe how to make SIP work with TLS from end points behind NAT. This, as I have mentioned before, have serious scalability and fail-over issues for current deployments. Regards, _____________ Roman Shpount --001a113f8aae3056400538017c4f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Jul 19, 2016 at 12:02 PM, Christer Holmberg <christer.hol= mberg@ericsson.com> wrote:
Outbound is more than a mechanism for keeping NAT bindin= gs open.

So, before saying "let's use outbound", what exactly are the = properties/features that you need?

I ha= ve mentioned this in another thread but Happy Eyeballs do not need to have = anything to do with SIP Outbound. Main connection that I do see is using SI= P Outbound Keep-Alive messages to detect the working flow for SIP messages = when multiple local networks or multiple SIP Edge proxy addresses are avail= able.

I have also mentioned that this is not the o= nly solution for Happy Eyeballs, since figuring out rules for sending messa= ges in the same SIP transaction across multiple flows can serve as an alter= native, and possibly better, solution.

Obviously, = if we restrict SIP to TLS only as the only acceptable protocol for Happy Ey= eballs, then SIP Outbound is the only standard solution which attempts to d= escribe how to make SIP work with TLS from end points behind NAT. This, as = I have mentioned before, have serious scalability and fail-over issues for = current deployments.

Regards,
_____________
Ro= man Shpount
=C2=A0
--001a113f8aae3056400538017c4f-- From nobody Wed Jul 20 11:40:33 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3407212DA17 for ; Wed, 20 Jul 2016 11:40:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RniXXUjqg7eD for ; Wed, 20 Jul 2016 11:40:29 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD3EA12DA30 for ; Wed, 20 Jul 2016 11:40:29 -0700 (PDT) Received: from mutabilis-2.local ([173.57.161.14]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u6KIeNLd013844 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 20 Jul 2016 13:40:24 -0500 (CDT) (envelope-from mahoney@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [173.57.161.14] claimed to be mutabilis-2.local From: "A. Jean Mahoney" To: SIPCORE , "Dale R. Worley" Message-ID: <47a61a89-89d0-926c-d371-e512e3f86bdc@nostrum.com> Date: Wed, 20 Jul 2016 13:40:23 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [sipcore] Quick notes from the SIPCORE WG session X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 18:40:31 -0000 Thanks to Dale for presenting at the meeting today! And although we had some technical glitches, I thought the discussion went pretty well. This is what I took away from the meeting (these aren't the minutes, just my notes): Action: Focus on flow setup with separate drafts for each transport. Action: Roman Shpount to send to the list an analysis of DTLS. Action: Chairs to discuss updating milestones with AD. Reducing transaction timeouts is out of scope (Robert Sparks briefly had an action item to send to the list an analysis of reducing timers F and B, but this does not appear to be needed at the moment). The following topics are interesting, and need discussion, but are broader than happy eyeballs: - call/connection recovery - signaling encryption/ALG traversal - DTLS lite - Outbound lite Let me know if I didn't capture it accurately. Thanks! Jean From nobody Wed Jul 20 12:18:31 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A91712B00A for ; Wed, 20 Jul 2016 12:18:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I0IcpbYeqEo4 for ; Wed, 20 Jul 2016 12:18:27 -0700 (PDT) Received: from resqmta-po-09v.sys.comcast.net (resqmta-po-09v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:168]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5FB812B04B for ; Wed, 20 Jul 2016 12:18:27 -0700 (PDT) Received: from resomta-po-19v.sys.comcast.net ([96.114.154.243]) by resqmta-po-09v.sys.comcast.net with SMTP id Px0GbzRAsS0FEPx0lbIH4W; Wed, 20 Jul 2016 19:18:27 +0000 Received: from hobgoblin.ariadne.com ([73.100.16.189]) by comcast with SMTP id Px0kb9iRSSMZYPx0kbmVPR; Wed, 20 Jul 2016 19:18:27 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u6KJIPMA017286 for ; Wed, 20 Jul 2016 15:18:25 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u6KJIPB7017283; Wed, 20 Jul 2016 15:18:25 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: sipcore@ietf.org Sender: worley@ariadne.com (Dale R. Worley) Date: Wed, 20 Jul 2016 15:18:25 -0400 Message-ID: <87k2ggi0e6.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfJpn76roMM3bjdpYqjC89gTlTXBW45WSapu2rY71b+k7ekhdIESfspjQ0KKb2illHObwuyIDsxEM3hZGYZyKdUO9cGQehiD5hrBRtcEahhmXRk5x1dbt r6Pt1dA7YEcThKdsbzOoIhekHmjhD4wFyliHOZxmxpy1NB8cQx5oOztnoQbI5nkmcs8Miy0VNvy7aA== Archived-At: Subject: [sipcore] Why forking calls does not solve transport problems X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 19:18:29 -0000 The question was raised during the Sipcore session of why forking does not solve dual-stack problems. I attempted to outline how problems arise with forking, but I made some mistakes in the details. This is a cleaned-up version. Naively, one thinks that sending a duplicate of a request to an alternative target should not cause a problem, because the ultimate destination UA can arbitrate between multiple requests, rejecting all but the first with 482. I used to think that myself. But I ran into a customer whose SIP system failed in ways that point out problems. They had two offices. Each was served by a proxy/registrar that handled the phones in that office. The two proxies routed calls to phones in the other office via the other office's proxy. Each proxy was paired with a voicemail server that took voicemail for its office's phones. Voicemail was handed in the usual way: A call was serially forked first to the registered contacts for the AOR, and if those timed out, the call was forked to the voicemail server. The ultimate cause of the problem was that each proxy forwarded to the other using the proxy's DNS name, but without a transport specification. In effect, forwarded calls could be serially forked, first by UDP transmission, then by TCP transmission. (Or perhaps it was the other order.) This isn't *real* forking, since the sending proxy doesn't record alternative targets (network addresses) for one destination URI as forks, but the destination can receive two copies of one INVITE, with different branch values (see RFC 3263 section 4.3), so they look like different forks to the recipient. Occasionally, the network between the two proxies was slow, and when a proxy sent an INVITE to the other, the other proxy didn't respond quickly enough, and so the proxy sent another "fork" of the INVITE to the other proxy using the other transport. At this point, one "fork" runs from proxy 1 to proxy 2 and then to the phone, where it rings. The second "fork" runs from proxy 1 to proxy 2 -- which handles it as specified -- sending the second INVITE to the phone. The phone rejects the second INVITE with 482. This causes the second proxy to step the second "fork" to the second destination, viz., the voicemail server. The voicemail server answers immediately, sending a 200 response. That propagates back to proxy 1, which considers the call established. But since proxy 1 does not see forking, it does not cancel the first INVITE it sent. So the phone continues to ring until the user picks up the call. But the caller is talking to the voicemail system. In the case of our customer, the solution was to change the URIs that each used for the other proxy to specify a transport parameter and eliminate the implicit forking. Dale From nobody Thu Jul 21 12:53:51 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73BD112D8D1 for ; Thu, 21 Jul 2016 12:53:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uWMm5EoW76Ig for ; Thu, 21 Jul 2016 12:53:47 -0700 (PDT) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C1FC12D8D0 for ; Thu, 21 Jul 2016 12:53:46 -0700 (PDT) Received: by mail-io0-x234.google.com with SMTP id 38so86065540iol.0 for ; Thu, 21 Jul 2016 12:53:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5uIS9PNT2Lp7fCJzu4PLghaI6o5aHqK10WWRZj1CvnQ=; b=0/0CvAZHkfN5CHILUr58q/0qhes3AveRHCaEuJKZMx4ELuJ9nbSvaNLXgbHpS7uqcR NRcbwEySJVpXx7uYEwaYfuk1s38uBDE7rTCM/evrG4KFfBemXqlTc+6gLx3D/clZ6Pfd B6skLOmLh7ZNWCe2u4+i/x16Isi5xI+yTIcPrKS/6c8AFbO7nAATBh/fbyQV0covKioq p2v64I/gaaYpTOeZHsCIQTnOkytFQdw/O4ZfFiZWydMICBG42ZeFfvIIp0WTAdukJFLU lHw4v3ET5P4Qinl+GrdM8rqxIikqpiI2U5BqnEEECbMP5Y42WH6UOBWF55Q/cskMZXeC lv5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5uIS9PNT2Lp7fCJzu4PLghaI6o5aHqK10WWRZj1CvnQ=; b=APpxrWKkGglLLFWhdZZMbxz5qVKjX9WQzHY0Dfk+uWRp69Jc92I+cnSpcrBIer/AzS xjfFWKVo2rT8JnRXtdyd/Uxwa53RZtjAi9Zby8zb1lis9ikETlxQScJcC1vIFhv1FfWx 4VRqiADftKAIpnsBl/WuMnweHD7LZvYMRdPLYZnag5ocSML9ewDc29CpGg9Q5KhJS8h0 2HAUv0dL9qYSq01AhrMkY9FEzP6dJg5fUlv6Qa4OaOcMt+iLn4D7jN/NscAdoR+nCcDv LPgR+Jqoon3k0N9WuNCB35y5OgTGTxWdW6GE88h+VqHUWW5qnws0h7u4PItbXOCCdLyS iaCg== X-Gm-Message-State: AEkooutdXGyBNrNABSzp7aWyn2LxVPvDHJtsoyUM7fDXKpGSc2rYgjR312vA4jV8ziopoQ== X-Received: by 10.107.151.143 with SMTP id z137mr6918iod.191.1469130826126; Thu, 21 Jul 2016 12:53:46 -0700 (PDT) Received: from mail-io0-f178.google.com (mail-io0-f178.google.com. [209.85.223.178]) by smtp.gmail.com with ESMTPSA id d68sm1926498ith.10.2016.07.21.12.53.45 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Jul 2016 12:53:45 -0700 (PDT) Received: by mail-io0-f178.google.com with SMTP id m101so85930683ioi.2 for ; Thu, 21 Jul 2016 12:53:45 -0700 (PDT) X-Received: by 10.107.12.34 with SMTP id w34mr13513ioi.171.1469130825100; Thu, 21 Jul 2016 12:53:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.62.139 with HTTP; Thu, 21 Jul 2016 12:53:44 -0700 (PDT) In-Reply-To: <87k2ggi0e6.fsf@hobgoblin.ariadne.com> References: <87k2ggi0e6.fsf@hobgoblin.ariadne.com> From: Roman Shpount Date: Thu, 21 Jul 2016 15:53:44 -0400 X-Gmail-Original-Message-ID: Message-ID: To: "Dale R. Worley" Content-Type: multipart/alternative; boundary=001a113f7e1cf57d8305382aac30 Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] Why forking calls does not solve transport problems X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 19:53:49 -0000 --001a113f7e1cf57d8305382aac30 Content-Type: text/plain; charset=UTF-8 This sounds correct (and underlines the existing problem with forking). One of the solutions that we deployed for dual network scenario was to send multiple INVITE or REGISTRATION requests over all available networks. Identical VIA branch value was used for all of those messages to indicate they are part of the same transaction. The way the system was designed all of these messages would be terminated by the same B2BUA/Registrations agent which was selected based on the VIA branch hash value. This B2BUA/Registration agent was specifically designed to aggregate messages received over multiple transports into a single transaction which prevented problems like the one described above. I know this is not a generic solution which can be applied everywhere but it worked quite well with variety of fixed and mobile networks across multiple countries for a fairly large user base. Regards, _____________ Roman Shpount On Wed, Jul 20, 2016 at 3:18 PM, Dale R. Worley wrote: > The question was raised during the Sipcore session of why forking does > not solve dual-stack problems. I attempted to outline how problems > arise with forking, but I made some mistakes in the details. This is a > cleaned-up version. > > Naively, one thinks that sending a duplicate of a request to an > alternative target should not cause a problem, because the ultimate > destination UA can arbitrate between multiple requests, rejecting all > but the first with 482. > > I used to think that myself. > > But I ran into a customer whose SIP system failed in ways that point out > problems. They had two offices. Each was served by a proxy/registrar > that handled the phones in that office. The two proxies routed calls to > phones in the other office via the other office's proxy. Each proxy was > paired with a voicemail server that took voicemail for its office's > phones. > > Voicemail was handed in the usual way: A call was serially forked first > to the registered contacts for the AOR, and if those timed out, the call > was forked to the voicemail server. > > The ultimate cause of the problem was that each proxy forwarded to the > other using the proxy's DNS name, but without a transport specification. > In effect, forwarded calls could be serially forked, first by UDP > transmission, then by TCP transmission. (Or perhaps it was the other > order.) This isn't *real* forking, since the sending proxy doesn't > record alternative targets (network addresses) for one destination URI > as forks, but the destination can receive two copies of one INVITE, with > different branch values (see RFC 3263 section 4.3), so they look like > different forks to the recipient. > > Occasionally, the network between the two proxies was slow, and when a > proxy sent an INVITE to the other, the other proxy didn't respond > quickly enough, and so the proxy sent another "fork" of the INVITE to > the other proxy using the other transport. > > At this point, one "fork" runs from proxy 1 to proxy 2 and then to the > phone, where it rings. The second "fork" runs from proxy 1 to proxy 2 > -- which handles it as specified -- sending the second INVITE to the > phone. > > The phone rejects the second INVITE with 482. This causes the second > proxy to step the second "fork" to the second destination, viz., the > voicemail server. > > The voicemail server answers immediately, sending a 200 response. That > propagates back to proxy 1, which considers the call established. But > since proxy 1 does not see forking, it does not cancel the first INVITE > it sent. So the phone continues to ring until the user picks up the > call. But the caller is talking to the voicemail system. > > In the case of our customer, the solution was to change the URIs that > each used for the other proxy to specify a transport parameter and > eliminate the implicit forking. > > Dale > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --001a113f7e1cf57d8305382aac30 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

This sounds correct (and un= derlines the existing problem with forking).

One of the solutions that we deploye= d for dual network scenario was to send multiple INVITE or REGISTRATION req= uests over all available networks. Identical VIA branch value was used for = all of those messages to indicate they are part of the same transaction. Th= e way the system was designed all of these messages would be terminated by = the same B2BUA/Registrations agent which was selected based on the VIA bran= ch hash value. This B2BUA/Registration agent was specifically designed to a= ggregate messages received over multiple transports into a single transacti= on which prevented problems like the one described above. I know this is no= t a generic solution which can be applied everywhere but it worked quite we= ll with variety of fixed and mobile networks across multiple countries for = a fairly large user base.

Regards,
_____________
Roman Shpount

On Wed, Jul 20, 2016 at 3:18 PM, Dale R. Wor= ley <worley@ariadne.com> wrote:
The question was raised during the Sipcore session of why forking do= es
not solve dual-stack problems.=C2=A0 I attempted to outline how problems arise with forking, but I made some mistakes in the details.=C2=A0 This is = a
cleaned-up version.

Naively, one thinks that sending a duplicate of a request to an
alternative target should not cause a problem, because the ultimate
destination UA can arbitrate between multiple requests, rejecting all
but the first with 482.

I used to think that myself.

But I ran into a customer whose SIP system failed in ways that point out problems.=C2=A0 They had two offices.=C2=A0 Each was served by a proxy/regi= strar
that handled the phones in that office.=C2=A0 The two proxies routed calls = to
phones in the other office via the other office's proxy.=C2=A0 Each pro= xy was
paired with a voicemail server that took voicemail for its office's
phones.

Voicemail was handed in the usual way:=C2=A0 A call was serially forked fir= st
to the registered contacts for the AOR, and if those timed out, the call was forked to the voicemail server.

The ultimate cause of the problem was that each proxy forwarded to the
other using the proxy's DNS name, but without a transport specification= .
In effect, forwarded calls could be serially forked, first by UDP
transmission, then by TCP transmission.=C2=A0 (Or perhaps it was the other<= br> order.)=C2=A0 This isn't *real* forking, since the sending proxy doesn&= #39;t
record alternative targets (network addresses) for one destination URI
as forks, but the destination can receive two copies of one INVITE, with different branch values (see RFC 3263 section 4.3), so they look like
different forks to the recipient.

Occasionally, the network between the two proxies was slow, and when a
proxy sent an INVITE to the other, the other proxy didn't respond
quickly enough, and so the proxy sent another "fork" of the INVIT= E to
the other proxy using the other transport.

At this point, one "fork" runs from proxy 1 to proxy 2 and then t= o the
phone, where it rings.=C2=A0 The second "fork" runs from proxy 1 = to proxy 2
-- which handles it as specified -- sending the second INVITE to the
phone.

The phone rejects the second INVITE with 482.=C2=A0 This causes the second<= br> proxy to step the second "fork" to the second destination, viz., = the
voicemail server.

The voicemail server answers immediately, sending a 200 response.=C2=A0 Tha= t
propagates back to proxy 1, which considers the call established.=C2=A0 But=
since proxy 1 does not see forking, it does not cancel the first INVITE
it sent.=C2=A0 So the phone continues to ring until the user picks up the call.=C2=A0 But the caller is talking to the voicemail system.

In the case of our customer, the solution was to change the URIs that
each used for the other proxy to specify a transport parameter and
eliminate the implicit forking.

Dale

_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

--001a113f7e1cf57d8305382aac30-- From nobody Wed Jul 27 15:37:38 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E08912D9BB for ; Wed, 27 Jul 2016 15:37:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30YQUS9t_qfz for ; Wed, 27 Jul 2016 15:37:36 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D50912D9AB for ; Wed, 27 Jul 2016 15:37:36 -0700 (PDT) Received: from [10.0.1.14] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u6RMbWhP024595 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 27 Jul 2016 17:37:33 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.14] From: "Ben Campbell" To: "Dale R. Worley" Date: Wed, 27 Jul 2016 17:37:32 -0500 Message-ID: In-Reply-To: <87lh25rth3.fsf@hobgoblin.ariadne.com> References: <87lh25rth3.fsf@hobgoblin.ariadne.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-sparks-sipcore-name-addr-guidance-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2016 22:37:37 -0000 I am not aware of any rule against a PS updating an informational RFC. A PS is assumed to have greater "maturity" than an informational. The opposite would be more of a problem. If such text is added, it's probably worth mentioning the status, and the fact that the update is in a PS is not intended to change that. (That is, any text added by the update would still be informational.) Thanks! Ben. On 16 Jun 2016, at 11:25, Dale R. Worley wrote: > "Drage, Keith (Nokia - GB)" writes: >> A reminder that RFC 3325 is an informational document, so I am not >> sure whether a standards track document can update an informational >> document. Anyone able to clarify? > > I searched, but I couldn't find much guidance on what update documents > are or are not allowed to do in the BCP directory. > > Dale > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Thu Jul 28 12:08:28 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B27DE12E019 for ; Thu, 28 Jul 2016 12:08:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ztntfvMf7gs for ; Thu, 28 Jul 2016 12:08:25 -0700 (PDT) Received: from resqmta-ch2-01v.sys.comcast.net (resqmta-ch2-01v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9635012DD38 for ; Thu, 28 Jul 2016 12:08:24 -0700 (PDT) Received: from resomta-ch2-11v.sys.comcast.net ([69.252.207.107]) by resqmta-ch2-01v.sys.comcast.net with SMTP id SqevbloiOTaLwSqfPbgG7K; Thu, 28 Jul 2016 19:08:23 +0000 Received: from hobgoblin.ariadne.com ([73.100.16.189]) by comcast with SMTP id SqfObC7b74t7ASqfPbj3JT; Thu, 28 Jul 2016 19:08:23 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u6SJ8MOY002780 for ; Thu, 28 Jul 2016 15:08:22 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u6SJ8Mde002777; Thu, 28 Jul 2016 15:08:22 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: sipcore@ietf.org In-Reply-To: (ben@nostrum.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Thu, 28 Jul 2016 15:08:22 -0400 Message-ID: <8737mtmvh5.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfE8uHnVRWaTzyQWSO4KPsHTiaGL2pDhC88l5Fdm1JBLl8uS+1aIv3/B7d4X99xiaH45SzrdbATJYe9gssTJdqLheY+f0QgYQLfJ2xHjrW0SlindkQdC2 UXxR0Cra2xamIVsuoy/QRDMTOCll/yITngONDcI2lR7vkvFSyXsk8ruZMQas5RFp/tT2oX7TdVZu1g== Archived-At: Subject: Re: [sipcore] draft-sparks-sipcore-name-addr-guidance-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2016 19:08:27 -0000 "Ben Campbell" writes: > I am not aware of any rule against a PS updating an informational RFC. A > PS is assumed to have greater "maturity" than an informational. The > opposite would be more of a problem. > > If such text is added, it's probably worth mentioning the status, and > the fact that the update is in a PS is not intended to change that. > (That is, any text added by the update would still be informational.) I suppose the thing to do is mark that part of the PS as "non-normative". Maybe "This section is a non-normative update to the informational RFC nnnn."? Dale From nobody Fri Jul 29 13:32:06 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13F6C12D846 for ; Fri, 29 Jul 2016 13:32:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i9ZmW-_is3sU for ; Fri, 29 Jul 2016 13:32:02 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA93C12D742 for ; Fri, 29 Jul 2016 13:32:02 -0700 (PDT) Received: from [10.0.1.14] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u6TKVxSl084273 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 29 Jul 2016 15:31:59 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.14] From: "Ben Campbell" To: "Dale R. Worley" Date: Fri, 29 Jul 2016 15:31:58 -0500 Message-ID: In-Reply-To: <8737mtmvh5.fsf@hobgoblin.ariadne.com> References: <8737mtmvh5.fsf@hobgoblin.ariadne.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-sparks-sipcore-name-addr-guidance-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2016 20:32:04 -0000 On 28 Jul 2016, at 14:08, Dale R. Worley wrote: > "Ben Campbell" writes: >> I am not aware of any rule against a PS updating an informational >> RFC. A >> PS is assumed to have greater "maturity" than an informational. The >> opposite would be more of a problem. >> >> If such text is added, it's probably worth mentioning the status, and >> the fact that the update is in a PS is not intended to change that. >> (That is, any text added by the update would still be informational.) > > I suppose the thing to do is mark that part of the PS as > "non-normative". Maybe "This section is a non-normative update to the > informational RFC nnnn."? I fear that a discussion about what it means to normatively or non-normatively update something would be harder to resolve than we might like. Simply noting that the RFC being updated is informational, and remains so as updated seems sufficient. OTOH, it would also be perfectly reasonable to split any such update into a separate informational draft. Ben. > > Dale > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore