SIPPING WG, Session 2, Wednesday, March 19th, 2003

reported by Vijay Gurbani
lightly edited by Dean Willis

SIP Role Authorization, Jon Peterson

I-D defining role-based authorizations in SIP. Lot of questions from the floor on how this will be used in SIP. Some more use case scenarios in the I-D may help drill down on. Tom Taylor: 'Role' has a lot of sociological baggage; maybe what you are looking for is 'token'. Gonzalo: Looks like there is a lot of interest; let's take it to
the mailing list.

Mary Barnes, SIP History

<Went through the changes from last version; see slides>

Solution draft; open issues:
  Should index be mandatory?  Right now it is optional.
  Security: primary concern is in regards to a rouge app/proxy  changing HI entries.
    Initial proposal - assume use of Auth identities similar to  draft-ietf-sip-authid-body
Next steps: Requirements is ready for WGLC.
Gonzalo: anyone objects to WGLC? <No one did; so WGLC accepted>
Security solutions: completed the req analysis.  Should this go to SIP WG now?
Gonzalo: Yes.

(Ed. Note:  Room polled for consent on passing History requirements on toward SIP for implementation,  and a stoing consensus was indicated.

SIP and Calling Service Charging Requirements, Wolfgang Beck, Deutsche Telekom

Problem: UAS sometimes want to charge for call duration. Users want to minimize the number of their accounts (trust
relationships).  A trusted third party (TTP) can help here. How to prove that a session is still active? 
* Make sure that UAs use an accounting proxy and are not able to  send messages directly to each other.
* Get signed and time stamped tokens from a TTP and include  them into INVITE and periodic UPDATE messages.

Other TTPs in SIP: PKI, NAI, Authorization service, P-OSP-Auth-Token I-D.

Next steps: should this become a WG item?  Or an extension of NAI/Authorization Service work.

Rohan: Are we interested in gathering reqs for an endpoint based charging model?
JDR: Too early to be asking these questions; need to flush out use cases.
Dean: Is it fair to say that it may be an interesting topic, but they should flush out the document with more use cases?
Rohan: If folks think this is intersting, please email Wolfgang.

Dan Petrie, User Profile Framework

Changes: sync'ed with rfc3261 and rfc3265.  Moved device identity parameters to User-Agent header parameters.
Content Indirection Protocol: SHOULD use HTTPS, MAY use HTTP.
Jonathan: What is the threat analysis?
Dan: User-specific information is transmitted and should not  be compromised.

Device identity parameters: should it be added to User-Agent header as a parameter?  This header does not have a generic name-value
element.  <Take to the list for more discussion>.

How to indicate profile type?  Option A: accept header ==> create a MIME type for each profile type.
JDR: Why can't the R-URI be used here?
<Generated a lot more discussion; eventually Gonzalo asked to be taken to the list>.

Dual Stack Operation, Hakan Persson, Telia.

Assumptions: many ipv4 hosts now; ipv6 is being introduced in dual stacks. 
Issue: If Alice sends an INVITE (alice has ipv4 and ipv6) to a proxy and proxy sends it using IPv6 to Bob who only uses ipv4, we have a problem.  Alice's Contact had an ipv6 address which has no relevance to Bob's UA.
Possible solutions: trial and error - specific error codes, or send 2 INVITES (one using ipv4 and other using ipv6).
Solution: ICE?
<Some discusssion ensued and converged around around an existing  solution of having proxies R-R correctly in each direction.  This
is an open bug in SIP bugzilla>.
Rohan: Please update the document with what can be done with the proxies R-R'ing in each direction.  Which will make this a usage
document.

Gonzalo Camarillo, SIP AAA Reqs.

<aaa-req-02.txt> in WGLC.  Gonzalo asked for more comments.

Early media, Gonzalo Camarillo

Status: we appear to have consensus on this doc.  We define the gateway model and the app server model.  Big open issue: some folks want to see a sip flag that says media coming, don't   initiate local ringback.  Is it really needed?
<No consensus reached, even after a hum>.

Eric Burger, Network announcements.

Open issues for media on hold: what does a media server do when it receives a hold request?  1) Suspend play, 2) Time moves forward (as in PSTN), 3) Invoker specific, 4) sendonly/recvonly? Our option: (1).
Dean: This is not a SIP protocol problem; it is a server and implementation issue.

Open issue: new response code 409 Request Rejected.
Adam: Lets not reuse codes that are being used in HTTP.
<No consensus; take it to the list>

IEPREP Considerations, Jon Peterson

We've been asked to take a look at rfc3478 and provide comments and a formal response.

(Ed: SIPPING was  also asked for comments before RFC 3478 went for last call, and that request was circulated on the SIPPING mailing list.)