back to SIP Notes and Minutes
Agenda bash 5
Chair: Asked who had read record-route-fix-03, just finished WGLC - only
one person, so need to assign reviewers so that it gets read by Sunday.
Reminder on WGLC of dtls-srtp-framework-02. Companion in AVT also in
WGLC.
Domain-certs-01 now updates RFC 3261 and is now Standards Track. All to
make sure they are happy with this, so any further comments needed very
quickly. Publication about to be requested.
Locaton-conveyance-10 will have another 1 week WGLC.
New milestones.
Identity discussion on Tuesday inconclusive, so participants asked to
continue on list. Also on the further suggested work item of a document
documenting existing identity mechanism in terms of security
expectations (on Tuesday's slides but not presented), the chairs intend
to open a work item on this.
v Mechanisms for UA Initiated Privacy: Mayumi
Munakata 25
John: Need to make it clear that Privacy: id still needs to be sent.
Martin Thomson: Need to consider impact of location-routing-allowed
header field, being discussed in GEOPRIV.
Richard Barnes: This is not a problem, because default is not to allow
insertion.
Nils: Question concerning information added to Record-Route.
John: The GRUU will identify the domain name of the user.
Mayumi: You need to use a GRUU from third party domain if you want to
hide the domain name. The document needs some more text to describe
this.
Chair: When these issues are fixed, is it ready for WGLC?
John: It also needs a bunch of editorial changes, which I have sent to
Mayumi, but when those are done it will be about ready.
Chair: So WGLC will start shortly after next version becomes available.
Robert: Please wait until after SIPIT in October.
Chair: OK
v Termination of early dialog prior to final response:
Christer Holmberg 20
Open issue 1: should it be allowed to send 199 reliably. Proposal to
allow sending it reliably, but you don't need to even if you have
received Require: 100rel.
Robert: So this is asking to violate the provisions of RFC 3262? Does
not find the motivation sufficient for breaking RFC 3262, and does not
believe this would be part of a future HERFP solution. So if someone
asks for 100rel, they have to forego any expectation of receiving 199
when a proxy sends it.
Francois: Because 199 is sent by a proxy, it should be treated more like
a 100. Can't get a proxy to send 199 reliably.
Christer: So issue of whether proxy can send 199 at all if 100rel has
been requested.
Chair: In summary, we want to preserve requirements of RFC 3262.
Robert: If proxy sends 199, it is effectively acting as UAS and subject
to UAS rules for 100rel. We can't resolve this now, but I will help
off-line.
Chair: We need to identify text that does not involve updating RFC 3262.
Continue on list.
Open issue 2: can a UAS be allowed to send 199.
Proposal: Allow UAS to send 199.
Robert: This is the right thing, and you can expect more text from me.
Want UASs to use it.
John: A proxy acts as a UAS when it sends 199, so no issue.
Open issue 3: Should 199 contain information concerning the final
response that triggered it.
Proposal: If the initial request indicates support of sipfrag,
recommended to include sipfrag message body in 199.
Robert: I have already objected to anything as strong as SHOULD,
particularly if motivation is solution to HERFP, because it doesn't
solve HERFP.
Francois: If we don't do that now, implementations will go on market for
199 and will later have little motivation for doing more for fixing
HERFP. Uncomfortable with going forward with 199 while still in dark
about how we will solve HERFP. Does not believe the other problems
solved by 199 are sufficient motivation for publishing this draft.
Chair: If you think that work is required, it requires a new draft.
Robert: When we agreed to adopt this as a WI, we explicitly said HERFP
was outside scope.
Scott: Agrees with Robert. I can help with text. Doesn't prevent any UA
putting such information in a sipfrag body. Would help to gain
implementation experience.
Open issue 4: Do we need an option tag, so that UAC can declare its
interest in receiving 199.
Proposal: Do not specify an option tag.
Cullen: Not sure. I am getting more and more concerned there are
networks that won't work unless you have 199.
Christer: No. This only allows resources to be released earlier.
Cullen: Proxy doesn't maintain state for early dialog.
Christer: There are 3GPP uses.
Cullen: Re-iterates concern.
Chair: Need to review draft to ensure it includes appropriate
compatibility mechanisms.
Cullen: Concerned with fact we keep hearing discussions around features
that were not part of the original use case on which we based the work
item - scope creep. That initial one requirement does not need an option
tag, so why do we need it?
Christer: But needed to avoid unnecessary traffic.
Cullen: That is a good answer - I am satisfied.
Chair: Conclusion - don't include option tag, but add more discussion on
compatibility.
v Keepalive Without Outbound: Christer Holmberg
10
Christer: Present 4 use cases.
Chair: Little discussion in list. Is there anything broken in what
Christer has been saying, such that we shouldn't be doing this in first
place.
Remi: Is there a requirement in 3GPP?
Christer: There is.
Remi: Why not use options?
Christer: Need a keep-alive between UE and edge proxy. Options is e2e,
and also too much overhead.
Chair: Lets go through these use cases and see whether they are problems
to be solved.
Aki: But is the problem already solved by other means?
Bruce: Question concerning use for P2PSIP.
Jonathan: Uses STUN.
Francois: Use case 1 (poor man's outbound) and IPPBX trunking are
probably the more interesting use cases, but does not have a strong
opinion whether we should do it.
Chair: How many think it is absolutely necessary to solve this for use
in absence of outbound? About 25.
Jonathan: Use case 3 (intermediate-intermediate) is the most useful, and
can achieve a much faster detection of a broken connection than options
(which is used now).
Chair: Out of time, but list discussions should try to identify how many
of these use cases we really need to address.
v Guidelines for double route recording: Thomas
Froment TBD
No time.
John
back to SIP Notes and Minutes