Subject: RE: [Sipping-tispan] Re: TIP/TIR requirements

From: "Bemmel, Jeroen van (Jeroen)" <[email-masked]>
Date: Thu, 8 Sep 2005 11:19:36 +0200

Regarding the TIP/TIR requirements:

Currently they are stated as follows (version -02d):

REQ-TIP-1:
    It must be possible for the callee to indicate in a SIP response an additional identity where he is reachable for future direct communications. 
REQ-TIP-2:
    The identity mentioned in REQ-TIP-1 must be formatted as a SIP URI (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol," June 2002.) [2] or TEL URL (Schulzrinne, H., "The tel URI for Telephone Numbers," December 2004.) [3]. 
REQ-TIP-3:
    The identity mentioned in REQ-TIP-1 is considered an end user supplied information that is not asserted by the network.

Some comments on this:

REQ-TIP-1 : I think this should be stated as a requirement, without refering to any particular mechanism (SIP response)
Proposed rewording: "When the TIP service is enabled, the identity of the terminating party MUST be presented to the caller"

REQ-TIP-3: Instead of saying that it is not asserted by the network, I would propose the following wording:
"The identity mentioned in REQ-TIP-1 MUST be supplied by the callee and MUST be forwarded transparently by the network"

In addition, I think there are several requirements missing here:
REQ-TIP-4: "The terminating identity MUST uniquely identify the terminating party, and MUST be usable to contact this party directly for future communications". The period of validity is subject to discussion

In solution terms this rules out private IP addresses, and public IP addresses allocated dynamically (e.g. through DHCP) would need to be valid for a sufficiently long period of time (when used).

For TIR:
REQ-TIR-1: "When the TIR service is enabled, the originating party MUST NOT receive any information that can be used to uniquely identify (and contact) the terminating party"

In solution terms this leads to a B2BUA-based approach, since the last Via header, the Contact header and potentially other headers all contain information about the terminating party. 

Regards,

Jeroen van Bemmel, Lucent

_______________________________________________
Sipping-tispan mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sipping-tispan

---

From: Miguel Garcia <[email-masked]>
Date: Fri, 09 Sep 2005 13:51:50 +0300

Hi Jeroen:

See inline comments.

> Proposed rewording: "When the TIP service is enabled, the identity of the terminating party MUST be presented to the caller"

No, I think your word deviates from the spirit of the requirement. The 
spirit of the requirement is that the callee ***selects*** this identity 
to be presented. Your wording does not reflect that user selection.

> "The identity mentioned in REQ-TIP-1 MUST be supplied by the callee and MUST be forwarded transparently by the network"

If we keep REQ-TIP-1 as is, I don't need to indicate here that the 
identiy is supplied by the callee. And the forwarded transparently by 
the network it is implicitly indicated in the current text when it is 
said that "is not asserted by the network".

Honestly speaking, I don't see the point in changing the wording.

> REQ-TIP-4: "The terminating identity MUST uniquely identify the terminating party, and MUST be usable to contact this party directly for future communications". The period of validity is subject to…

In my opinion this requirement will indicate that there must be a 
mechanism for the network to assess the uniqueness of this identity, 
which is not the case. This is an additional identity selected by the 
user. If the user chooses a non-unique or non-routable identity, it is 
not our problem. As far as the service is concerned, there are no 
further requirements than "give me an identity and I will transport to 
the caller".

> REQ-TIR-1: "When the TIR service is enabled, the originating party MUST NOT receive any information that can be used to uniquely identify (and contact) the terminating party"

So are you planning to obfuscate the Contact header?

> In solution terms this leads to a B2BUA-based approach, since the last Via header, the Contact header and potentially other headers all contain information about the terminating party. 

Exactly... which is not what this service requires.

/Miguel

-- 
Miguel A. Garcia           tel:+358-50-4804586
sip:[email-masked]
Nokia Research Center      Helsinki, Finland