SIPPING Working Group Second session, IETF 64:
Notes taken by Jim McEachern. jmce@nortel.com
Topic: Retargetting Issues
Agenda item was withdrawn and single chart shown instead.
Issue: Topic covered by previous informational draft (voice uri). Rohan pointed out that some time ago the group decided that it did not want to take it on as an issue, hence the informational status. This is needed by Tispan, but the informational draft should meet tispan’s requirements. Discussion of whether or not the group should review it first.
Conclusion: Agreed to send as informational without further review. (I think)
Topic: Extending the SIP Reason Header with Warning Codes
Issue: RFC3261 only allows warning codes that are related to SDP. Should this remain the case in the future?
Cullen Jennings asked about the motivation for this? ????? Questions about the usefulness of warning codes. No implementations currently use them. Need discussion of what, if anything we want to do with warning codes.
??? TISPAN is looking at the use of warning codes, and some TISPAN people are using them.
Need to agree guidelines.
Jonathan: we aren’t using them because we have response codes, and they provide the information that automa need. The only reason for warning codes is if we are running out of space – and when we do we should define a mechanism to extend the space.
???? said we are running out of response codes, but Jonathan countered that most of the space is still unregistered.
Rohan pointed out that we have a disagreement on fact. We need to investigate and find out what the reality is, especially 4xx and 6xx. Need to include working drafts that have not yet made it into the registry.
Conclusion: ??? will investigate and let the group know.
Topic: GRUU Reg Event Package
Issue: Said that it is ready for working group last call.
Conclusion: Consensus to go with the draft as is, and will schedule WG last call
Topic: URN for Services
Issue:
Looking for feedback on what to do with this proposal.
Cullen Jennings – for informational services this is good. For emergency services it is a problem. Previous proposal used the same path as all calls. This one uses a new path for emergency calls, which means that if it is set up, then you will not spot problems until emergency calls fail.
Jonathan – sees separate code path as a feature. Want to separate emergency calls out asap, and treat them with priority immediately.
???? – support for separate code path. You can optimize performance for it then.
Hanis – doesn’t care where it is done, but supports doing it somewhere.
Henning – does not want Sipping to say “good idea, go to ecrit” and ecrit say “good idea, do it is sipping”.
Henry – what if there are competing emergency services. Will Google have competing ads?
Steve Norries – need a discussion of how this urn will be work in practice. Will it be extended to commercial services such as Pizza?
Conclusion: Sipping chairs to confer with Ecrit chairs and Area Directors and determine where this work should be done. (Henning is fine with this as long as the resolution time is in weeks, not years.)
Topic: Requirements and Possible Mechanisms for File Transfer Services Within the Context of SIP Based Communication
Issue: Joel - here are many, many things they might want to do, so why should we pick one specific thing (i.e. file transfer) that we want to pick on. It is not this working group’s job to work out how they do every single application. Eric Burger asked what this gives them that sending an IM doesn’t. Jonathan said it is not clear, so someone probably needs to write down call flows. Dean said maybe this is a Simple problem. Eric asked why are we standardizing an application level thing that there are many variations of. Francois said we should investigate, is there a reason things don’t work. Cullen Jennings supported this investigation. Shawn Olsen – is there a suggestion that MSRP is going to be used for file transfer. Answer: it is one of the possible ways, yes. Jonathan – what url do you post to if you are going to use it for a file transfer. Let’s write a requirements document and see where it takes us.
Conclusion: Will write a requirements document and continue the process. For the time being will post them to Sipping, and we will revisit another day.
Topic: SIP Identity Usage within Enterprise Scenarios
Issue: Cullen – do you still think that enterprise certificates from certificate servers are only available inside the enterprise? He does not understand, or agree with the assertion that certificate servers in this draft are the same as corporate directory. Is it something that will not be deployable under European privacy laws. ??? previous example was a user based certificate. Sometimes device based certificates are used instead. Cullen – what is a device based certificate, or a self-signed certificate, both of which are allowed by SIPPING Certs ID? How is this different from that? John elwel – the phone might also have a cert. Francois – going off track. This is not about user certificates. It is about scenarios where, for whatever reason, you cannot use user certificates. Cullen – for this draft we are talking about device certificates generated for a device, which will be used by multiple users who are using this shared device.
Is there interest in pursuing this in the wg?
Cullen – 3261 already covers this.
???? – what is enterprise specific about this material? Ans: if IP phones are issued with certificates, there is no binding between the device and the user. For calls outside the company the corporate directory will not help.
Dean – this is creating a temporary binding between a device and an identity as asserted by a corporate directory.
Francois – this is not defining anything new. It is a BCP, and people should read the draft.
John Elwel – I receive a call from Siemens.com with identity asserted by their authentication service. As long as I trust their server, how do I get the certificate from inside the company for that user. But if I know the device can be trusted? Using the identity header to certify that this is coming from xxx @ siemens.com.
Rohan – suggesting it is circular argument
Discussion terminated by the screen saver rule.
Conclusion: Need to explain the problem better so that Rohan understands it. Once he does, we will discuss further.
Topic: Calling Party Category
Issue: Jonathan – in SIP there is no way to know whether a header was inserted by a SIP proxy or by the end user. Would allow any user to bypass call screening by asserting their role. Should use SAML to do this? (Dean agrees)
Martin Dolly – this draft includes OLI categories in addition to calling party.
Jonathan – does this mean SAML can’t work?
Martin – for interworking with pstn the parameter needs to exist somewhere inside the sip header or it will not interwork properly.
Stever Norries – there are also many nation specific versions of this.
Presentation is proposing that we define a new SIP header to deliver this information,
Janet Dunn – need to separate the issues. CPC issues in the pstn need to be done in SIP. But CPC has been extended and overloaded. We need to work out the essential function, and work out how to do it in SIP, but don’t necessarily just try to copy the convoluted way that it evolved in the pstn.
Eric Burger – many essential services depend on this. Support this.
Jonathan – Key is role assertion. This just happens to be something that is conveyed by CPC and OLI. But they also convey other things, which we may not want to do, and certainly don’t want to blindly do it in the same way that it is being done in CPC, OLI etc. Let’s focus on the things that are valid roles, and ignore the rest.
Eric Sasake volunteered Hanus to do this.
Conclusion: Going to gather requirements for conveying role information – the types of things currently carried in CPC and OLI, to understand the requirements and determine how to fully satisfy these requirements (probably using SAML).
Topic: Payment for Services in SIP
Issue: use of a deposit as a mechanism to prevent SPIT
Joel Halpern – would hate to see SPIT prevention depend on a cheap effective micro payment mechnanism: Sipping is not an e-commerce working group.
Cullen Jennings – traditional payment mechanisms require at least 30 cents per transaction. One new one will do it for under a penny.
Rohan Mahy – likes the draft, and there are several applications for it. Does not think that you can come up with an amount that is an effective deterrent in rich countries, yet affordable in poor. Who cares if it will deter spit. Remove references to it. There are other applications, so let’s progress this and let the market decide if and how they will use it.
??? – agrees with above.
Cullen – suggested sending comments to spam group.
??? – charge will need to be based on the called country, rather than the calling country. Spam today comes from out of the country.
???? –
Dean – getting caught up on what to charge, rather than the technique.
Robert – how many people know enough about SAML to have high level discussions about it. Poll showed a reasonable scattering of people – 20+ by my rough count.
Q. Do we want to continue with this work, and do we want to use SAML.
Conclusion: No one objects to continuing this work, and to using SAML
Topic: Discussion of PRACK Implementation (not on the agenda) Rohan
Issue: Jonathan – these complex protocols result because the problems are complex, not because we want to be nasty. Before redesigning, decide which one of the original requirements will no longer apply. Just a note of caution.
Cullen – if we want to consider this, someone will have to write a draft, and then we can read it and assess it.
Jonathan – people don’t issue protocols because they cannot find a business case, not because it is difficult.
Robert – many people claim they implement PRACK, but they only implement the sunny day states, and if it encounters anything else they fall over.
??? – maybe we should publish rohan’s state diagram.
Conclusion: If there was one, I missed it. I think we will do nothing, pending further input.