[dispatch] Ad hoc on SIP Identity

["Elwell, John" <[e-mail]>]

We have not asked for agenda time in DISPATCH, but in order to get things moving again we and the chairs are organizing an ad hoc DISPATCH meeting on the subject, probably last session on Monday. This is in parallel with MEDIACTRL, but has the advantage of being before the DISPATCH meeting on Tuesday morning, so the chairs can report back. A definite announcement on this will follow later.

The purpose is to discuss next steps, so I would like people to propose ideas, preferably on the list prior to the ad hoc.

Our own thoughts are as follows:

1. http://tools.ietf.org/id/draft-elwell-dispatch-identity-reqs-01.txt has received some feedback, suggesting it is heading in the right direction. So at least we have some written requirements. Are these a good starting point, or do we need to make substantial changes or go about it in a different way?

2. We have several expired drafts proposing solutions. These can roughly be categorised as:
- reducing the amount of signed information (to avoid the need for breaking the signature when changing information en route);
- signing a copy of certain information, so that if the original information is changed en route, the signature is still valid and the copy of the original information is still available);
- performing a return routability check of some form.
Are any of these a suitable basis for more work? Are there any other approaches?

3. It is recognised that there are difficulties with E.164 numbers, in the sense of what a domain can assert about an E.164 number. However, since E.164-based SIP URIs are by far the most common (for voice at least), we should try to do something with these.

4. There seems to be a consensus we can't do much about PSTN interworking. The most we can do for a call from PSTN is to provide some authentication of the gateway that asserts the calling number (based on the assertion received from PSTN).

John and Victor