[Sipping] My notes from this morning's session

1.1      SIPPING
Progress since IETF 71 has been sluggish due to editor day-job pressures. One RFC published.

Agenda is extremely full. 

Keith - 3455bis changes have been agreed in 3GPP, want to have all changes agreed and revise the document one more time.

Please notice the PMOL work on SIP performance metrics.

Please notice the BMWG work on SIP benchmarking (and this work will probably conflict with SIP/SIPPING most of the time).

Please notice ISOC's incubation of the Realtime Text Task Force (R3TF).

1.1.1            Martin Dolly           User Agent Profile Datasets        draft-ietf-sipping-profile-datasets-01.txt
Martin is new editor for this document.

Biggest change since last revision is on visibility attribute (user/admin visibility). 

Policy attribute is used only inside containers.

Using a closest value first merging algorithm.

Ready for WGLC but need additional reviewers first.

1.1.2            Jonathan Rosenberg     Service Identification        draft-ietf-sipping-service-identification-02.txt
Now separating concepts (service identifier, declarative service identifier, derived service identifier) - declarative one is the problem.

Added use case (adding audio to a non-SIP game).

URIs as differentiator is key architectural concept.

Added litmus test (do you fail or fall-back appropriately?).

Added discussion on delayed media offers ("don't do that").

Christer hasn't read new draft - had a number of comments, hadn't had a chance to review Jonathan's responses yet.

Jonathan resisting aggregate tags - use RFC 3840/3841.

Christer thinks this is case-by-case - what does "can do audio" mean?

Spencer (reviewer) thinks this document was "good enough" (in fact, 01 was, but 02 is an improvement).

Delayed offer - didn't run into lots of problems because media tags work anyway.

Jonathan and Christer will duke things out in the hallway and either finish or kill each other.

1.1.3            Volker Hilt SIP Overload Control        draft-hilt-sipping-overload-design-00.txt
Still adding design team members, now have four independent simulation tools.

This draft frames discussion about possible design choices and models, doesn't propose a solution.

Looks like SIP characteristics are problematic for implicit overload control (retransmission, selecting messages to be dropped is almost as hard as processing the messages).

James - not seeing any reference to resource priority header. This draft doesn't discuss the header, and the header could be useful.

Looking at rate-based, loss-based, and window-based overload control feedback types.

Jonathan - is this in addition to a mechanism deliverable in SIP? Yes.

Using three scenarios - sudden peak, peak with gradual release, temporary light overload.

Looking at three fairness criteria - user-centric, provider-centric (within SLAs), customized (any other criteria).

Ted - would you be able to support the airplane "keep irritating the same people, instead of making them happy and irritate new people" algorithm? Could be added as a fairness criteria.

Ted - discussing the SIP equivalent of random early drop (RED).

1.1.4            Henning Schulzrinne     Load Control Event Package      draft-shen-sipping-load-control-event-package-00.txt
Other work not looking at destination-specific congestion scenarios (viewer-voting, holidays, natural disaster), and malicious attacks.

Don't want to penalize users that shouldn't be affected by congestion because they aren't talking to congested destinations. Current mechanism is destination-agnostic, doesn't address destination-specific congestion.

Want to reuse as much mechanism as possible - load-control event package, load-control XML document based on extended policy.

Martin Dolly - American Idol example should reflect databases in PSTN, throttling should happen at gateways for some time to come (until application logic moves to application servers). Not sure subscribe/notify is the right answer, but the answer needs to work asynchronously.

Jonathan - this is an interesting problem to solve, concern is about overlap with general congestion control discussion. Just be crisp about separation.

Adam - how does this work with the general case (where we don't "know" what the next hop is)?

Bernard - inter-domain problem - people don't trust each other at any level, whether information is signed or not.

Want to work as close to the source as possible.

Janet - this is exactly what Resource Priority header is supposed to help with.

1.1.5            John Elwell            P-Asserted-Identity update          draft-ietf-sipping-update-pai-04.txt
Should URIs be extended (number of URIs, types of URIs).

Concerns about impact on existing implementations - don't have a lot of feedback on this yet.

John's experience so far is that implementations ignore additional URIs.

Ted - open-ended scope is problematic. What happens if you have multiple URI schemes and you don't understand ANY of them? Clearest way forward is to progress with present scope. 

If we found someone who choked on additional URIs, we would need to move to a new header.

Jon - don't want to encourage moving forward with existing scope because text about Identity is still ignoring problems.

Cullen - not appropriate for working group, lots of concerns that haven't been addressed, will be IETF Last Call comments (I promise you).

Keith - you don't get backwards compatibility by ignoring the URIs you don't understand - IMS decisions are based on first URI plus default. Also don't want to see lots of URI schemes turning into vCard, etc.

Jonathan - should at least add forward compatibility - we thought this header was going nowhere, but it's widely deployed. If we don't relax constraints, at least have an extensibility story - we did same thing with From header moving to RFC 3261.  Already seeing people cheat. 

Francois - doesn't make sense to vote - not just because of SIP Identity.

If we don't have working group consensus to solve this problem now, we can do it later (even in SIP).

Hum - working group wants to address short-term holes and progress the document.

John - need another draft on forward-compatibility issues, need to think about response Identity, will talk about this with Cullen and Jon this week.

Will need another WGLC.

1.1.6            Salvatore Loreto SIP Context-ID requirements      draft-loreto-sipping-context-id-requirements-00.txt
This is about correlating multiple SIP dialogs when they form part of the same "conversation".

Draft includes three use cases motivating the work.

Jonathan - thanks for working on this, glad you're looking at use cases and requirements, but draft is still assuming a solution for problem areas that are quite different. Camera use case is very interesting, on its own, should think about splitting media streams when people have loosely coupled devices.

Keith - not entirely convinced CCDS request example is of value, isn't guaranteed in PSTN today. Trying to bind messages together looks like MSRP all over again, which is where we should not go. I'm concerned about layering - within the body of the message, rather than at the SIP layer?

Agree with Jonathan - this draft is just to start the discussion.

Dale - buried requirement - the reasons we correlate messages is because we don't expect to have a long conversation, but find out that we do - this is a bookmark that we might need later, but we don't know that, for sure. Minimize up-front overhead and do more work when you use it. Why not use Call-ID as correlator? No additional overhead in the initial message. 

1.1.7            Christer Holmberg           3GPP Usage of the Offer/Answer Model LS from 3GPP Mailing List Discussion draft-ietf-sipping-sip-offeranswer-08.txt
Issue was known before we got the liaison statement - if a re-INVITE fails what happens with successfully-finished offer-answer transactions that have already taken place (using reliable 18x messages with SDP answers)?

No obvious right answer within 3GPP, SIP community needs a solution.

(Obvious) alternatives - full roll-back when re-INVITE fails or continue with negotiated SDP state. 

Full rollback problems are not being able to restore SDP state because resources were freed, race conditions with UPDATE containing another offer. Continuing problem is not having original SDP after the failure.

Need to pick one alternative now.

Jonathan - rant on, letting process get in the way of doing the right thing. Offer-answer doesn't' address what to do about this problem, and it should. Offer-answer isn't mature if it doesn't address this problem. 

Mary - agree about the process comment, need a way forward.

??? - agree a solution first, but was hoping for agreement in principle in this meeting. Need document that details this solution, need reply back to 3GPP to describe the path forward (don't care about the form of the answer).

Jonathan - mild preference for continuing with current SDP, already made decision about loosely coupled SIP and SDP. Not obvious that precondition flows in middle of established dialog even needs to work the same way as re-INVITE with UPDATE - we weren't trying to solve mid-transaction signaling when we made the decisions we've made so far.

Robert - very careful to have discussion decoupled from SIP dialog state and remote context state in that failure. Still have mild discomfort that when we figure out what to do with remote target, but we expect that we'll do rollback there - we are loosely coupled, but the divergence just makes me nervous.

Gonzalo - will solve problem as soon as possible.

Hum in the room - some support for rollback, but much more for continuing with current state.

Robert - is anyone else uncomfortable with making a decision now? About six-seven people want more time (show of hands).

Gonzalo - please say something on-list by Friday.

Do we have agreement that we want to solve the problem? No one spoke against this.

1.1.8            Alan Johnston      Transporting User to User Information for SIP Call Control           draft-johnston-sipping-cc-uui-04.txt
Does not require SIP-T (ISUP transparency is not required), is not suitable for transport using SIP INFO (produced and consumed at time of call setup).

Martin - UU information is also used during a call.

Keith - concern is specifically about modification by proxy.

Current approach is that a new header is proposed.

Dean - also need option tag, need to make sure we have support for this.

Hand this off to SIP working group to standardize the header?

P-header or regular header? Not private, proprietary or provisional, need an option tag to ensure support all the way end-to-end.

Keith - reasonable discussion of use case, but couldn't find requirements in current draft. Want requirements called out clearly so we can make sure we meet the requirements in SIP.

Adam - sympathetic to what Keith said on the mailing list. Initial reaction is that header field isn't the right answer because we do the same thing in SIP-T, should be consistent with SIP-T. If proxies don't insert this, we could be consistent.

James Rafferty - lot of customers don't want to step up to full SIP-T support, got immediate support from customers to implement this. Definitely a problem to be solved.

Jonathan - is this only tandem situations? No. So SIP-T is not the right answer. SIP is infinitely extensible for new stuff, so let's consider a new thing that has meaning in a pure SIP environment. Also have no idea what to do with the data unless vendors have private arrangements.

Only applicable when at least one of the endpoints are not SIP (not SIP-to-SIP). Need to explain this better.

Hum - worth developing the requirements further? Strong support in the room.

1.1.9            David Schwartz    No Service To This Number Reject Code        draft-schwartz-sipping-nsr-code-00.txt
Current Not-Found failure handling assumes strong tie between domain context and userinfo. If there's no such linkage, we need a response code that describes that.

410 implies that user is valid, 604 says "don't try anywhere else". 404 isn't clear that you should try elsewhere. LNP CDB might only have information about one country (or less).

Don't want to assume any fault for failure (so no 5xx), want automated handling.

Do we need any more SIP failure response codes? David doesn't think so.

Henning - if there's a problem here, there's a case for illuminating the issues and clarifying.

Jon - this is all about telephone numbers - userinfo with very different properties. This is the counterpart to ENUM UNUSED. Custom SIP response codes that are only used with telephone numbers? Just have a different meaning for 404 with telephone numbers.

Dale - lots of problems with "can't find it" errors, can't actually disambiguate these cases, everything behaves the same for all the responses. 6xx is completely diseased. "this request failed, you should try another one" is also hard. Retry problem is another can of worms. 

Joel - response code from a server that says "you guessed the domain, please try something else" - receiver can't tell it was retargeted, can't solve this in the response code. Tel URI is a different question.

David - sometimes there are things I can do, but a 404 doesn't encourage that. Needs to be a mechanism that says "maybe you can fix this" - almost like a 3XX to 0.0.0.0.

1.1.10       Saverio Niccolini Requirements for vertical handover of multimedia sessions using SIP    draft-niccolini-sipping-siphandover-04.txt
Interface being used may not be available after handoff, but MH wants to keep sessions active.

This is assuming no network support (so not Mobile IP). 

Henning - we had session mobility effort going on a long time ago. This isn't fundamentally different. Think I wrote terminal mobility draft in 1999, not reflected - don't understand the history.

Presenter - history is described in the draft (but I am not an author, so don't shoot the presenter).

Francois - "needs to be faster" than what? Existing solutions (but they are at different layers).

Christer - work related in 3GPP - are you aware of that? Will you take this work there? Authors are aware of 3GPP work and one solution is similar to what's being discussed in 3GPP.

Henry - user selecting link layer to avoid access charges?

Jonathan - good document, does what SIPPING was meant to do, crisp problem statement, deployment considerations, so we can have a discussion - would like to see more like it, would like to see the work go forward.

Bernard - have seen a lot of nonsense that results from "must be faster" requirement in the IETF - please define this very precisely, "slow" may have nothing to do with the original protocol.

Savario - "fast enough".

Hum - Revise draft and refine? More people hummed for this than "bad idea, stop working on it".