[sipcore] Notes from SIPCORE meeting IETF 79

Cullen Jennings <fluffy@cisco.com> Thu, 11 November 2010 11:46 UTC

Return-Path: <fluffy@cisco.com>
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 694AD3A683A for <sipcore@core3.amsl.com>; Thu, 11 Nov 2010 03:46:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.573
X-Spam-Level:
X-Spam-Status: No, score=-110.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 J7T1h-Q6QFC2 for <sipcore@core3.amsl.com>; Thu, 11 Nov 2010 03:46:56 -0800 (PST)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 0B9803A6A3F for <sipcore@ietf.org>; Thu, 11 Nov 2010 03:46:56 -0800 (PST)
Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAEZm20yrR7Hu/2dsb2JhbACiQXGkY5tQhUoEhFqFPEKDCw
X-IronPort-AV: E=Sophos;i="4.59,182,1288569600"; d="scan'208";a="618136039"
Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 11 Nov 2010 11:47:25 +0000
Received: from [192.168.4.2] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id oABBlOQn007498 for <sipcore@ietf.org>; Thu, 11 Nov 2010 11:47:25 GMT
From: Cullen Jennings <fluffy@cisco.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Date: Thu, 11 Nov 2010 04:47:46 -0700
Message-Id: <39D9259D-1505-4008-89DD-C8C1909D814C@cisco.com>
To: sipcore@ietf.org
Mime-Version: 1.0 (Apple Message framework v1081)
X-Mailer: Apple Mail (2.1081)
Subject: [sipcore] Notes from SIPCORE meeting IETF 79
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Nov 2010 11:46:57 -0000

Chair Slides
- See slides for status of drafts


----------------------------------------------------
 Location Conveyance

1) Number of location values. 

Draft will allow as many as you want with warning not to do it. 

No objections to the 424 handling proposed. Martin like this and pointed out only this is the reasonable thing to do. Richard Barnes agrees too. 


2) Ordering of location, what does it mean

The order is the order they were added and mean nothing more or less than that. 

Hadriel said he did not understand this work then convinced us he was right. 

Hannu: He likes the multiple objects and like adding them in chronological order. He does not think it is possible to provide a rule that does better than this. 

Martin : Would prefer to say that it is just a set and the ordering does not provide chronological. Jon thinks it easy to order these (like Vias) and there are environments. Jon does not see harm, Martin can live that. 

We agreed that you MUST add location to the end of the set. (18 in favor, zero against)


3)  There was a bunch of fluff. Propose replacing the fluff with a option tag for each type of differencing. This allows one to use normal SIP extensibility to replace the fluff. 

John Elwell:  happy with general proposal. Pointed out using Require does not make sense. Hadriel could not imagine when you put this in a Require. 

Martin pointed out that this will end up in the Supported header in a 424 and it is actionable. 

Adam: noticed it has warts and they are effectively profiles. We end up needed one option tag for each for each URI and no good way to correlated the option tag with the correct URL. 
Jon: could approach this with things like putting the tag on the URL so they are correlated. May be better approaches. 
Adam: there are non emergency cases where it makes sense to fail the call when you can't get a location. 
Jon: 
Martin: When you sent a URI, it has all the information you need to know to get the location
Jon: I am the ghost of Rohan Mahy and I have come with an new Event package to haunt you 


Geo location Errors Codes

The question is when you return different error codes, does the device receiving the code do anything differently. Ans: if the retransmission is flag is set to “no”, and it got an error saying it needed to be yes, then it can resend with it set to yes. 

Martin: points out the price is high and ask if there could be another SIP code. 
Hadriel: These codes are also used for logging to help figure out what went wrong. 
Richard: does not see the point of the complexity. 
Keith: need to be able to reject the location but accept the call - so we need to keep the geoloc error 
Jon: We tried to get rid of them, can’t  - should have as few as possible - may be able to get a bit smaller but not much. 
Hannes: We could use the reason phrase - lots of other protocols do <no idea if this is what Hannes said>. We could add something later. 
Jon made strong argument for leaving it as it is is the quickest path to get done and this does not harm. 
Neutral Observer: you can go to a separate room and discuss offline along with 3 dimensional color holograms to visualize the options 


Hum Do you believe we should leave in the base specification the error location codes as they are roughly today. It was strong consensus to leave in. 

Result: Leave the error codes in roughly as they are today. 

4) Will close this on the list 

Chairs will put information on list with plan to move this faster. 

AD Position: The authors have a clear guidance on way to update this. They will update that in the draft and if it turns out it does not work we can decide how to change the draft. 


---------------------------------------
Delivering request-URI and parameters to UAS via proxy

There was an ad-hoc meeting on Monday. 

There seems to be some debate about what was agreed to at the Monday meeting. 

We are scratching the out of dialog refer in the bullet in slides - It can be in out of dialog refers. Just not notifies. 

Slide 6: Issue 3. Hadriel points out this solution is really weird. This is to hides your domain. 

Issue #4: Paul was not especial OK with this. No one else expressed opinions. Paul wants to think about it. 

Jon: Trying to apply 3323 to model day is going to be hard. The design of 3323 was you would use a service that provided they anonymization service. “none” was for the case you were forced through it but did not want it to anything. Choosing option 2 to issue 4 seems as good as anything. 

Hadriel: problem here 3323 was designed about protecting who it was from and HI is about who it is going to and just hard to map. Andrew points out this is not exactly the case and it does provide some privacy. 

Slide 8: Reason header issue 

Adam (as individual) agreed with this recommendation to meet goals of WG milestone. Dale also supports this as this will help reveal why the previous request failed. Paul gives up on this misguided idea and supports this. 

No one objected to this. 




---------------------------------------------
Proxy Feature Tags

Dale: What do you need this for, why wouldn’t your INVITE go same path as Register? Evidently IMS likes the invite to get lost but Register work fine. No information on why was provided. Paul tried to stop the rat hole. It sounded more like a full blown routing rabbit warren. 
Chair: we should discuss more about mechanisms, instead of use cases.

Problem with option tags require RFC but that would probably not work for session continuity. 

Andrew Alan: Would like to solve this - would like to solve service interaction problem. Would like to be able to fine the URI of intermediaries on the path so one can send them out of dial requests. 

Chair: Let’s move the discussion to mailing list.

-----------------------------------------------
Reason Header Extension for Applications

Paul K (as individual): We don’t even have a place you can put this in the HI today. 
Christer: has a draft in to put Reason code in HI 
Hadriel: The internal proxy processing of HI might be able to be used for this 
Mary: We probably need to update HI to be clear about this 
Dale: several of these just indicate why a number was translated 
Dale: The paid service code may need to be subdivided into multiple cases 
<Cullen> I  don't understand why we need this 

Chair: would need to take to list and not clear if sipcore would be right place or not

 
Thank you Cullen and the secret but supper helpful Anonymous User 6 to take the minutes!