Notes, SIPPING Session 2, IETF 58

Reported by francois Audet

SIPPING WG Notes, Thursday PM
-----------------------------

Chairs:
Gonzalo Camarillo (Ericsson)
Rohan Mahy        (Cisco)
Dean Willis       (Dynamicsoft)

Requirement for end-to-middle security (Ono - NTT)
--------------------------------------------------

Presentor (Ono):

Features:
- Logging services
- FW traversal
- Transcoding
- Early media disposition
- Session Policy
- History info
etc.

Relationship with m2e security. Differences are that e2m requires
discovery, m2e does not.

Proposal is to keep m2e and e2m separate.

Open issue: Message body handling at proxies. Proxy may need to
delete a message body in a request in order to delete a user
authentication data (e.g., Proxy-authorization) that is protected

Talk:
- John Peterson: understands requirement to add/delete/modify bodies
   from requests. There needs to be a solution ... maybe's a 4xx/3xx
   response to the UAC to resend without bodies that need to be stripped
   (prefers this) ... aka "redirect approach".
- Gonzallo Camarillo: there are pressing needs for the WG to discuss
   message body handling for not only this but m2m security and session
   preferences; does the WG want to handle e2m and m2e. Wants mailing
   list discussion.
- Rohan Mahy: wants to add guidance to RFC3261

Requirement for e2m and m2e - Mary Barnes (Nortel)
--------------------------------------------------

Presentor (Mary Barnes):
- gathering requirements for now
- relation to e2m from the other perspective ... looking at information
   added by intermediaries for the use of intermediaries.
- effectively builds a transitive trust model
- adds mechanism to challenge intermediaries & ability for intermediaries
   to manipulate message bodies
- do we need m2m or can it all be accomplished by m2e
- next steps: agree the basic requirements & problem domain, take to list.

m2e slightly different than e2m. Share problem of challenging
intermediaries. Both can add and modify message bodies.

Talk:

Camarillo: interesting exercise and is worthy of further discussion.
Encourage everybody to bring feedback on mailing list.

Role(trait)-based authorization draft (Peterson, Neustar)
---------------------------------------------------------

Presentor (Jon Peterson):
- auth decision not always made on identity but rather the role or trait(S)
   or attributes of the request.
- ie. "is a gateway", "is faculty"
- is it something we would want to do?
- Role is better name than trait (probably).
- Incorporated 4 use cases. Minor changes to wording. No open issues.

Good number of people read the draft.

Will be pursued as working group item (unanimously on a hum).

On-demand access authorization (Pressen)
----------------------------------------

Presentor:
- allow auth for "on demand" atomic, maybes time-limited subscriptions
- Authorize access for this very subscription only.
- Formulated 7 high level requirements.

Talk:

Rosenberg: What is special about "this" subscription? Why would access
change from one instance to another. Only requirement that is not
addressed by XCAP.

Oran: One use-case for time-window.

Rosenberg: A validity element should be added in there. That way XCAP
could be used.

Is there demand for solutions to the problem?
How to proceed? Shall we use XCAP?

Dean Willis: Work is relevant, but we need more convincing use cases.

NAT scenarios (Rosenberg): to be discussed in MMUSIC
----------------------------------------------------

Early Media & Disposition (Camarillo, Ericsson)
-----------------------------------------------

Presentor (Gonzalo Camarillo):
- known issues with offer-answer: forking etc
- provides a framework for the application server model for early-media using
   a different offer-answer exchange - new content disposition (early-media).
- uses PRACK to carry SDP as part of offer-answer
- early-session as opposed to early-media in an attempt to avoid clipping

Talk:

- Audet (Nortel): would be able to indicate that early media be the same as
   normal media
- Camarillo (Ericsson): I believe you can.
- Will be clarified off-line.

Adopted as working group item on a hum.

sipping-3gpp-translator IPv6 (Camarillo, Ericsson)
--------------------------------------------------

Presented in v6ops WG in Vienna. Should be done in SIPPING with the support of
v6ops. More competence in SIPPING.

Drage: This is not endorsed by 3GPP yet. Should not be constrained by 3GPP.
Problem is general (v4 and v6) and not 3GPP specific.

Camarillo: Some 3GPP requirements are specific, e.g., they don't do TURN.

Drage: Keep the solution General.

Suresh Sarapati (Cisco): There is a SIP part and a v4-v6 part. The v4-v6 part
should be done in v6ops. The SIPPING document should just talk about the SIP
part of the solution.

Camarillo: Disagree because there is too much overlap.

Allison: NAT-PT will be deprecated. Content is strongly SIP, and should be in
SIPPING with consultation with v6ops.

Dean Willis: every group will have to work with IPv6.

Volunteers to look into this: Marcus Brunner & Roni Even & Keith Drage &
Dirk Kutscher.

draft-sipping-exploders (Camarillo, Ericsson)
-----------------------------------

Presentor (Gonzalo Camarillo):
- UA needs to send a similar request to several destinations via use of a
   BBUA that "explodes" (not forks) the request.
- requires that the "exploder" informs the UA about the status of the
   transactions initiated by the exploder
- requires credentials need to be passed thru by the exploder to prove to the
   desination that the request is being made on behalf of the true orig UA
- Exploders are ALWAYS B2BUAs.

Talk:

Brian Rosen: Support. But are we too busy?

Camarillo: This is a personal high priority.

Peterson: Security implications are high and we need to look into it because
it is potentially very dangerous.

Robert Sparks: Wants to see this on the list a little longer.

Eric Burger: Ditto.

Peterson: Could be REFER-like. Potential for new work on this.

Orit Levin: Agree with Jonathan that this is not for standardization of
a generic SIP mechanism. Not SIP-specific problem. The missing piece is
how to dynamically define the ad-hoc list.

Conclusion: It's interesting: go to the list because requires more discussion.

Dialog Event Package (Rohan Mahy, Cisco)
----------------------------------------

Presentor (Rohan Mahy):
- syntax of dialog-info+xml has changed
- security implications
- Alan Johnson & Rohan Mahy will be editors.
- changes since last Rev:
    o added implicit filtering (if A subs to B and A receives a call for B,
      no NOTIFY)
    o re-organised notification body
    o added correlation information (referred-by and replaces tags)
    o added "replaced" state transition
    o added auth and filtering section
- OIs:
    o Nobody wants to keep CSeq and Route-set, so they will be removed.
    o Proposed escaping will stay as is.
    o Hungup transition will be split-up in local-bye and remote-bye.
      Keep separate.

Lots of security implications and thus need a thorough review. Lots of
substantial changes to document.

Talk:

Rosenberg (Dynamicsoft): Remove out of document what we don't have use
case for today.

Jennings (Cisco): Camp-on is a use case. Will need to know the remote
BYE versus local BYE. We should keep those states because they are useful.

Mahy (Cisco): will send in 2 weeks an example of how people can present
that they are busy doing something.

Mahy: received lots of request for hold indicator. There are many different
flavors of hold, and we need to distinguish between them. Want people to
indicate what they want.

Dean Willis: should this be a UA state package instead of dialog package?
Take to list.

SIP Torture Test (Robert Sparks, Dynamicsoft)
---------------------------------------------

Presentor (Robert Sparks):
- removed deprecated tests that were based on RFC 2543. Added 3261-specific
   tests
- SDP tests moved to mmusic-sdp-torture test
- lots of editorialising to add text and reduce ambiguity
- added a bit accurate archive as a 64-bit encoded tar-ball
- created re-useable tools
- some production bugs
- future work .. support for automation

Created reusable toolsl, e.g., to calculate Content-length.

Open issues: production bugs. Need careful because all messages are new.

Future work: Are they other messages that we need to add (let Robert know).
Should we normalize for automation?

We need 2 people per message to review.

SIP Load Management (Robert Sparks, Dynamicsoft)
------------------------------------------------

Presentor (Robert Sparks):
- current tools to handle overload:
    o 503 with a retry-after: v. severe
    o 302 new requests
- what could we do instead:
    o call gapping
    o give inter-mediaries a way of getting out of a route-set without dying

Jennings: Often we want to control the type of requests.

Camarillo: Is the group interested in load sharing? Strong interest. Keep on list.

Even Notification Throttling (Niemi, Nokia)
-------------------------------------------

Presentor (Aki Niemi):
- Add option-tag for insisting on even throttle being applied. In SUBSCRIBE,
   then in NOTIFY.
- notifier throttles notifies to a separation of at least the throttle value

Talk:

Brian Rosen: Is this problem an immediate problem?

Ben Campbell & Robert Sparks: really important for SIMPLE which expects the
group to work on this.

Keith Drage: I think it is mature enough and should go forward.

Dean Willis: Should this be sent to SIP? or should we continue to work on it?

Rosenberg: Document is not finished and needs more work.

Jennings: I think that some other documents are more ready to SIP than this.

Rosenberg: Gave an example of an issue not addressed.

Camarillo: Go to the list with concerns. If concerns are small enough, will
go to SIP otherwise will stay in SIPPING longer.

RTCP Summary Report Delivery (Alan Clark, Telchemy & Johnson, MCI)
------------------------------------------------------------------

Presentor (Alan Clark):
- provide RTCP XR metrics (VoIP) to SIP 3rd parties
- RTCP XR useful but operates only between endpoins
- H.323 and H.248 already extended with QoS reporting protocols based on
   RTCP XR, would like a common approach for all signalling protocols.
- Draft-02 adds proposed format for Metrics. Binary field -RTCP XR payload
   (32 bytes always). Comma separated ASCII (up to 91 bytes). Recommend ASCII.
- Proposal is to use RTCP XR metrics in SIP. Application for both Enterprises
   and Services providers.
- Scope is per call metrics.
- OIs:
    o events package the right choice
    o format for metrics approved of
    o local and remote metrics to be included?

Talk:

Noname person: Scope is not clear. Some work is done in other group. Would
like some clarification on scope (not rep-inventing new performance monitoring
metrics). RTCP XR limits to VoIP. Do we need to expand to include RMON? If
not, clearly mention in text.

John Elwell (Siemens): Supports the work. Like to see extensibility mechanism
to not be limited to RTCP XR. Not sure we need to report both send and receive.

Alan Clark: The two ends may be in different management domain, so you at
least sometimes need to have both send and receive statistics. Could be
an option.

Noname: Why so specific to VoIP?

Bill Marshall (AT&T): From a service provider point of view, how do you believe
the endpoint.