SIPCORE, 79th IETF, Beijing, China

Status and Agenda

Agenda accepted as proposed. See slides for summary of working group items.

Location Conveyance

Handling of 424 Response Code

Proposal is to send 424 only when no location can be understood; and that intermediaries that have added a location do not proxy 424 response to the UAC.

Martin Thomson: agrees with the proposal

Chairs call for any disagreement in the room; none raised. Will defer call for consensus until there is specific text proposed.

Ordering of Location Values

Proposal is to require new locations to be added to the end of the list, but to assign no specific semantics to ordering.

Hadriel Kaplan: Are we being too wishy washy? Should we be more specific? Is this unavoidable?

John Elwell: Consensus on list was to allow multiple location objects.

Hadriel Kaplan: Can we have a rule which is more specific?

(Some discussion of the past history and some of the corner cases which makes this hard)

Hannu Hietalahti: 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 Thomson: are we attaching semantics (e.g. with chrono order). Safer to just consider as a set.

John Elwell: order might be easy and can say caveat emptor... don't see the harm

Martin Thomson: either way is OK

Call for consensus: Who is OK with putting text to say "insertion must be done at the end of the list"?

Consensus: Document will normatively state that implementations MUST add location to the end of the set. (18 in favor, zero against)

Geolocation option-tag

Error codes indicating which profiles a UAS supports were viewed as somewhat cumbersome (review by John Elwell). Proposal is to use option-tag profiles. List discussion for this approach have been favorable.

John Elwell: Happy with general proposal. Pointed out using Require does not make sense.

Jon Peterson: Leaving the door open, might not need it.

Keith Drage: What happens with multiple locations and end-to-end support of a tag... will option tag get changed?

Jon Peterson: You would add additional supported tags as it goes... in the case of intermediary.

Hadriel Kaplan: Concerned about putting this in Require. Do we want calls to fail in those cases?

John Elwell: Might be useful in error code.

Martin Thomson: Use in requests might not make sense, but will end up in the Supported header in a 424 and it is actionable.

Adam Roach: 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 Peterson: A lot of this is an artifact of multiple locations, we could find some remedies e.g. tag on header instead of in supported.

Adam Roach: there are non emergency cases where it makes sense to fail the call when you can't get a location.

Martin Thomson: Request in geolocation has a URI, don't need to say how to use a particular URI.

Jon Peterson: Unless we're committed to one profile then we need multiple location cases.

Martin Thomson: Let's put a new parameter in header with a new RFC...

Jon Peterson: Gross profile solution might work...

Hadriel Kaplan: option-tag is a hammer looking for nail... if it's in Supported need to put in all all the time.

Jon Peterson: We conceded supported in request might not be useful, but in response it is.

James Polk: Just one location would solve this... the pain threshold for this is high.

Hadriel Kaplan: It's a collision of scheme - not solved by just one location.

No conclusion reached -- will attempt to find workable solution on the list.

Geolocation Header Errors

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 Thomson: Are the errors actionable?

James Polk: We need these error codes.

Martin Thomson: But I can't do anything with the information.

(Discussion about specific error codes... 100, 424, 301, 302 etc.)

Martin Thomson: Lot of mechanism here - not sure it adds a lot of info other than better feedback.

Jon Peterson: What do the different subsides tell us?

James Polk: Retention, Routing Allowed could result in

James Polk: Pizza hut case... (rapid steam of error codes), server could correct and retry.

Martin Thomson: Maybe, but the cost is high for this.

Hadriel Kaplan: Detailed error codes are for troubleshooting - not for self-healing. They do have value.

Richard Barnes: Maybe we don't need this detail in this doc. Just put in a separate doc.

Keith Drage: Need to be able to reject the location but accept the call - so we need to keep the geoloc error.

Jon Peterson: I think we still need these. We tried to get rid of them, but can’t. We should have as few as possible - may be able to get a bit smaller but not much.

Hannes Tschofenig: Support for a separate doc seems good idea.

James Polk: Disagree with separate doc.

James Polk: Geopriv was very fixed on this... 5606 is a bad case...

Alissa Cooper: Geopriv fields are directives for a recipient.

Martin Thomson: They will take the call

Hannes Tschofenig: We could use the reason phrase - lots of other protocols do <no idea if this is what Hannes said>. We could add something later.

Hadriel Kaplan: Beware reason phrases - they do not localize

Jon Peterson: Let's take an expedient path. Leave what's in there. It does no harm.

Consensus Call: Should we leave in error codes as they are?

Consensus for leaving current error codes as they are presently specified.

Sohel Khan: Let's go to a separate room and discuss this topic offline with 3 dimensional color holograms to visualize the options.

Routing-Allowed syntax

Issue deferred to mailing list for resolution.

Postscript

Chairs: Let's try and do some interim work to get this draft completed... watch the list for details.

(Keith Drage raised process question about whether it is appropriate for authors to put text into an adopted WG document without the WG signing off on the exact language first)

RAI Area Director: The authors have a clear guidance on a way to update the document. They will use their discretion to update the draft according to that guidance and, if it turns out the proposed text does not work, we can decide how to change the draft.

History Info & Target-Uri Support

See also the ad-hoc meeting notes, below.

What messages contain History-Info?

Hadriel Kaplan: Out-of-Dialog REFER could have History-Info...

Mary Barnes: OK - we'll remove the bullet. Also, we'll scratch it from NOTIFYs.

Privacy

No objections to proposals given on slides for issues 1 through 3.

Proposal for issue 4: "Ignore 'none' -- it doesn't apply to History-Info, since History-Info doesn't reveal identity of UAC."

Paul Kyzivat: I'd like to think about this....

Jon Peterson: Trying to apply 3323 to model 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 Kaplan: problem here 3323 was designed about protecting who it was from and History-Info 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.

Reason in History-Info

Adam Roach: Agree with leaving it alone... anything else out of scope

Dale Worley: In favor. (with explanation)

Paul Kyzivat: OK - I give up.

Chair: Anyone against?

No objections to leaving Reason handling as currently specified.

Proxy Features

Dual-Direction Tags/Path:

Dale Worley: 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.

Hadriel Kaplan: No INVITE might not follow the same path.

Christer Holmberg: But this is a policy issue... in some cases yo do want the INVITE to follow the same path

Dale Worley: Does this not happen by default?

(more discussion)

Paul Kyzivat: Rat-hole. Let's move on to the mechanism.

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

Chair: Please keep the discussion going on-list. We would need to add a milestone and make sure this is the right working group for this work.

Reason Header Extension for Applications

Not much feedback on the list...

Paul Kyzivat: I thought this was germane since we're doing work on History-Info bis...

Paul Kyzivat: Not clear how reason goes into History-Info, there are no responses which allow Reason

Roland H: Reason in response is in Dispatch

Mary Barnes: we don't want to extend 4458

Paul Kyzivat: Is there an interaction with History-Info which needs to be dealt with

Mary Barnes: Don't think so.

Dale Worley: several of these just indicate why a number was translated. Many of the codes are straight-forward, but first has to do with paid services. Might want to be subdivided...

Cullen Jennings: Don't understand why we need this...

Chair: Work through on the list. Express interest... We would need to determine whether this is a core modification (and therefore belong in SIPCORE) or be dispatched elsewhere...

Appendix: History-Info Ad-Hoc Meeting Notes

A group of interested participants met on Monday, November 8th to discuss the History-Info document. Notes from that discussion follow; all ad-hoc section names start with "Ad-Hoc".

Mary Explained the progress and current state of the document.

Ad Hoc: What messages contain History-Info?

Proposal on the slide: Take it out in 100 response, NOTIFY and REFER.

Hadriel Kaplan: Has to carry History-Info in REFER because that's the only way to deliver GRUU to the REFER-To URI.

Hadriel Kaplan: Problem was that text read like entity receiving the REFER composing the INVITE based on REFER sets the History-Info that was present in the REFER and that's wrong.

Mary Barnes: Will fix it.

Mary asked, for each requests listed in the slide if it's useful to have History-Info embedded.

Dale Worley: Proxy will have consistent rule to put them in despite the type of method/request it is. Make no sense to rule out some requests that don't break anything.

Everybody seemed to agree.

Mary asked about 100 response?

Hadriel Kaplan: Can't possibly be useful in 100.

John Elwell: Mandating History-Info in 100 response is not good.

Debate on what language to use to reflect this.

John Elwell: Just state MUST except 100 response.

Keith Drage: Be consistent with the term used in RFC 3261.

Gonzalo Camarillo: Just say "non-100 provisional responses".

Ad Hoc: Privacy

Paul Kyzivat: What would happen if the contact in 3xx has privacy header escaped in the URI.

Mary Barnes: Whether privacy header escaped in the URI will remain in the URI is based on the local policy.

Mary will Write the text that clarify the step/order of handling the contact URI in the 3xx including how it would handle the embedded privacy header etc.

Hadriel Kaplan: For privacy in response, make sure it's clear that it's the proxy in the path that is going to handle the privacy of the History-Info in response.

Ad Hoc: Reason

Some debates about the rationale etc. of using Reason header escaped in the request. This was decided the way it is under the prior SIP leadership.