Notes from SIP Session II, Wednesday 1PM-3PM, Montreal, Canada.
Recorded by AC Mahendran
1) Location Conveyance (draft-ietf-sip-location-conveyance-03)
Presenter: James Polk
Goal of the draft is to push UAC's location to another SIP element.
Open issues:
* Move the requirements to an appendix - this will stay in the RFC.
Agreed. Keith mentioned that the format needs to be consistent with
other SIP documents.
* Carve out basic operation section without normative text. Re arrange
sections 4&5 into per element behaviours
* Reduce the text in section 2.
Agreed.
* Suggestion to list all SIP methods this extension
applies/does-not-apply-to in the abstract.
Adam mentioned that it is not necessary to add this list. Keith agreed
with Adam - we dont want to rule anything out of scope in this document.
The scope of this document is just location-by-push, and not to list the
methods which can/cannot carry this information.
* Suggestion on the list that S/MIME message body is always used
initially and to allow a backoff to less secure communication if there
is an error.
Hisham: Not interested in delaying setup time. Henning: S/MIME only
works if you can encrpyt wit public key of the particular destination.
You would not know this all the time. So, it is better not to mandate
this behavior.
* Suggestion: expanding the location header to allow a base64, PIDF-LO
equivalent header value i.e. allow the PIDF-LO object to be present in a
SIP header (probably, encoded in base64).
Henning: Data URL allows for the location to be included in the SIP
header. (MIME type and encoding. See no technical reason why it would'nt
work.) Keith requested these discussions to be taken to the list
(including discussions on motivations for carrying this information in a
header as supposed to the body).
* Should location be allowed in responses?
* Add a new requirement that HTTP is required to be used by receipient
for de-referening location.
James requested more reviewers for the draft.
2) SAML for SIP (draft-ietf-sip-saml-00)
Presenter: ?
What needs to be done in future versions:
- Is this spec a soution for only meeting the trait based auth
requirements?
- Discussion about enabling SIP proxies to add SAML assertions to the
SIP header by value.
Keith: postive responses on the mailing list.
JDR: Yes, it covers the requirements. Concerns about binding of SAML
asserting to SIP call. Some fields like Call ID etc need to be in the
SAML assertions. Would like to have standalone binding of assertion to
the call.
Keith: discussion has to be taken to the list.
3) Certificates. Arboreal Rodents Or Fruitless Canine Vocalization?
(draft-ietf-sip-certs-01)
Presenter: Jason Fischl
A good number of people seem to have reviewed the draft.
Questions/Next steps:
* Will people implement it?
Yes.
* Should we go to WGLC?
Keith: after a week or two, the document will be sent to WGLC.
4) Hop Limit Diagnostics. Is my bunny sick?
(draft-ietf-sip-hop-limit-diagnostics-03.txt)
Preseter: Scott Lawrence
Presenter indicated that the document went thro WGLC.
Cullen: This is not yet a SIP WG item. So, it cannot be in WGLC.
Issues:
* Issues raised on the list whether "request message" should be returned
in other un-recoverable errors (400, 403, 410, 414...)
- the problem is this changes the focus of the draft.
JDR: is ok with expanding the scope of the draft to include this for
other error messages.
RJS: No one has come to the microphone to say don't increase the scope.
* Is it ok to use Warning header for problems other than SDP? Should we
use a specific warning code be defined?
Henning: at that time motivation was mainly SDP. However, see no reason
why we cant re-use it for SIP.
RJS: wont object. However, text for registry document needs to be
changed as well.
Agreement: group is ok to using warning header.
* Should a limit be set on response size?
Very large UDP responses may fragement so much that no response reaches
the request originator?Should that limit apply to all responses? If yes,
what size?
There were a number of solutions proposed at the mic - sending
first/last via, using content indirection etc. However, no resolution.
The discussion needs to be taken to the mailing list.
5) Connected Identity (draft-ietf-sip-connected-identity-00,
draft-elwell-sip-tispan-connected-identity-01)
Presenter: John Elwell
Open issues (draft-ietf-sip-connected-identity-00)
* need for option-tag to indicate UAS support for the identity header
field in mid-dialog requests?
agreement: no option tag needed
* sip-identity is silent on how to behave if identity in "From" header
field is not one that authenticated UAC is allowed to assert
Proposal: Add a note to indicate that it is effectively left to local
policy whether to reject or forward without identity header.
Accepted.
* should we mandate UPDATE for sending connected-identity
Rohan: Any one sophisticated to use Connected-Id would do UPDATE.
Keith: If you support this draft, you should support UPDATE as well.
Agreed.
* Should we mandate the inclusion of SDP offer in the UPDATE?
RJS: Dont mandate it.
Dan wing: Agree with Robert.
Agreement: Not required. It needs to be optional.
draft-elwell-sip-tispan-connected-identity-01
* Should the To header field URI in the response be allowed to differ
from the request.
TISPAN needs two identies each for caller and callee - one identity is
used for billing, the other is used for call-backs. For caller's
identities, the proposal is to use PAI (P-Asserted-Inentity) for
billing-id, and "From" for call-back-id. For callee's identities, the
proposal is to use PAI for one of ids, and there are a number of options
for carrying the other identity - To header, "From" of a new UPDATE
request from callee to caller, etc.
A number of folks raised concerns about using PAI for billing
identities. Most have the understanding that PAI will be used for call
backs as well.
Cullen: Can we use something like P-Charging-Vector to carry the billing
ids?
Further discussions on the mailing list.
* Should the connected-identity draft talk about dual identity?
Agreement: NO
6)Security Flows (draft-ietf-sip-sec-flows-01)
Presenter: Robert Sparks
Robert is working on creating examples with automated tool. He will
shortly submit a draft for WGLC and publication.
No issues reported.
7) Fork loop fix (draft-ietf-sip-fork-loop-fix-02)
Presenter: Robert Sparks
One Suggestion on mailing list:
* dont start putting in loop detection tokens until you see yourself
earlier in the via stack
RJS: Plan not to include this suggestion. Agreement in the WG.
Issues:
* in the computed hash, why include all route values, callid, to-tag,
from-tag, proxy-require, proxy-authorization headers?
RJS:I will leave it out unless someone raises valid reason why we need
those.
8) Feature list for advance specification
Presenter: Robert Sparks
Work is just getting started. There will brain-stroming on this topic in
global.sipit.net. The expectation is to have an initial darft by the San
Diego meeting.
9) Hitchhiker's Guide (draft-ietf-sip-hitchhikers-guide-00)
Presenter: Jonathan Rosenberg
Issue:
* How to proceed with the draft:
Proposal A: - Split core into a separte doc, issue immediately; rest of
it goes much later
Proposal B: Keep as one doc, pick a point at which we decide to issue,
revise later on.
Suggestion by Jonathan: Proposal B
JDR will post this to the list. Consensus will be determined on the
list.
10) SIPS: Guidelines (draft-audet-sip-sips-guidelines-02)
Presenter: Francois Audet
Document will not contain any normative changes. Document to explain
what we have and what we mean.
Paul K: the more we get into this work, the more we will realize what
less we have got!
Keith: Any objections to proceeding with a informative document? Will
ask ADs to add this to the charter.
There was consensus to add this to the charter.