Subject: [Sip] More on SIP Identity

From: "Elwell, John" <[email-masked]>
Date: Sat, 25 Oct 2008 17:18:47 +0100

First, I have revised the E.164 problem statement draft, which had
expired. The only changes are a clarification to the introduction
concerning E.164 number formats and an addition to the sentence on
number portability in 2.1:
http://www.ietf.org/internet-drafts/draft-elwell-sip-e164-problem-statem
ent-01.txt

Second, I have revised the e2e identity important draft, just to capture
(near the end of section 2.4), a set of arguments Hadriel gave for not
re-signing at intermediaries:
http://www.ietf.org/internet-drafts/draft-elwell-sip-e2e-identity-import
ant-01.txt

Third, a reminder that there were thoughts expressed in Dublin that we
should capture in a draft considerations about how a UA should handle
received identity information. A first attempt at this is in:
http://www.ietf.org/internet-drafts/draft-elwell-sip-identity-handling-u
a-00.txt

Also there are other drafts on the subject from Hadriel Kaplan, Kai
Fischer, Dan Wing and others, mostly expired.

Finally, where do we stand on this whole topic? It is known that certain
SIP intermediaries (B2BUAs, SBCs) break RFC 4474 signatures. In some
cases the reasons for such modification are considered doubtful, but in
other cases there may be justification.

During the Dublin session we focused on a particular problem caused by
B2BUAs/SBCs, that of media steering. This is known to break RFC 4474
signatures (since it involves changing IP addresses and ports in SDP).
There was no conclusion as to whether this is indeed a justified
modification, whether it is a problem that needs solving, and what to do
about it.

It was also asked whether there are other potentially justified
behaviours of intermediaries that break RFC 4474 signatures.

One possible candidate is codec selection, whereby an intermediary
removes from an SDP offer those codecs that fall outside policy or for
which bandwidth is not currently available.

Another possible candidate is topology hiding, by changing Call-Id
values to hide information.

Yet another possible candidate is changing Cseq values, to compensate
for 3PCC actions.

I think we need to get a complete list of such behaviours and assess to
what extent they are justified (and therefore the importance of finding
a solution to the problems that arise). So I would welcome more
discussion on the subject prior to Minneapolis.

John
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Victor Pascual Ávila" <[email-masked]>
Date: Thu, 30 Oct 2008 00:46:46 +0100

Hi John,

> http://www.ietf.org/internet-drafts/draft-elwell-sip-identity-handling-u

Thanks for producing this draft.
Looking at results from the last SIPit [1], Section 3 (UA best
practice for handling received caller identifiers) could represent a
valuable work.

"I asked where people were taking bits from messages to display as caller-id.
There were many different kinds of answers, including
 P-Asserted-Identity if present, then From
 From display name
 username part of From uri
 P-Asserted-Identity only
 Contact uri
 Remote IP address
 P-Asserted-Identity, then Remote-Party-ID, then From
 From, then Remote-Party-ID, then P-Asserted-Identity
 Remote-Party-ID then From
 From then P-Assertid-Identity
 P-Asserted-Identity, then Reply-To, then From
 entire From URI"
Of these, using the From display name occurred most frequently,
but not much more than any of the other responses

[1] https://www.sipit.net/SIPit23_Summary

Cheers,
-- 
Victor Pascual Ávila