back to SIP Notes and Minutes
Documents that need review:
draft-ietf-sip-record-route-fix - in wglc, not many have read. Will
assign reviewers
draft-ietf-sip-dtls-srtp-framework - in wglc, ending 8/8/08. Parallel
doc in avt also in wglc.
-----Mayumi Munakata - Mechanisms for UA Initiated Privacy
Draft now focuses on providing guidance for UA to conceal private info
using GRUU and TURN. Does not obsolete privacy RFC. Removed indication
of privacy to network elements–concluded it was not needed.
Discussion:
–Should this draft restate that this does not remove need send the
privacy-id? Other private data than p-aid may be inserted by
proxies. Example - location header, location-routing-allowed. Keith:
Location privacy is a location-conveyance issue, not an issue of this
draft. Nils comments that there could be other leaks, i.e. user name
in a record-route, etc. Author says this is a privacy-id rfc feature,
not of this draft.
Using GRUU will not anonymize the domain name. Will add text to
explain using third party GRUU servers to get anonymize domain names.
Next Steps: One more revision based on feedback so far, WGLC. Robert
comments it would be nice to capture implementation info from upcoming
SIPit.
-----Christer Holmberg - Termination of early dialog prior to final
response
Open Issues:
1) Allow sending 199 reliably? Issue with a proxy sending a reliable
prov response–where does resulting prack go?
Proposed: Allow sending reliably, but also allow it unreliably even
with Require: 100rel.
Discussion: Objection to violating 100rel. We already agreed we
weren’t trying to solve herfp. Conclusion: Take to list. Robert will
help beat on it. Want to avoid updating 100rel.
2) Should a UAS be allowed to send 199 in the first place?
Proposed: yes.
Discussion: Allow it. Robert offers to contribute text. Want to
transition this to the endpoint in the long run. Proxy-initiated 199
is a transitional measure.
3) Should a 199 contain info from the final response that triggered
the 199?
Proposed: If request supported sipfrag, recommend including sipfrag
body in 199.
Discussion: Objection to saying anything at all–spec should remain
silent. Discussion over whether such a recommendation is the right
path towards a herfp solution. Herfp was explicitly excluded from this
work when we accepted as wg effort.
Conclusion: Draft will remain silent.
4) Do we need an option-tag to indicate support? Intermediaries may
also be interested, can they insert option-tags?
Proposed: Do not insert an option tag.
Discussion: Will implementations break if they don’t get 199 when they
expect it? Some concern that we have not thought out all the use cases
that keep popping up. Option tag not needed for the current document
scope.
Conclusion: No tag. If people have other use cases, please engage
requirements discussion on list.
-----Christer Holmberg - Keepalive Without Outbound
Draft allows inqdication of support of keep-alives without rest of outbound.
User case: Keep-alive without outbound support, non-registration
emergency calls (needed in 3GPP), intermediate-to-intermediate
heartbeat, IP-PBX trunks.
Details not presented, discussion on list, but not enough to provide
consensus.
Questions: Any technical problems? None significant.
Question: Do we want to solve this set of problems?
Discussion: Why not just use outbound? Answer: outbound not always
possible. P2PSIP might could use this–although ICE already provides
keep-alives.
Question: how many interested in actually working on this problem?
Comment that some interested parties are at the drinks section.
Question: Who thinks it absolutely necessary to solve this?
Response: Several raised hands. Dean comments that was more than the
people willing to commit time.
Out of time, take use case discussion to list.
-----Thomas Froment - Guidelines for double route recording
Did not cover due to time constraints.
back to SIP Notes and Minutes