Subject: [Iptel] RE: Comments on draft-ietf-iptel-tel-np-00.txt

From: "Yu, James" <[email-masked]>
Date: Fri, 2 Apr 2004 16:12:07 -0500

Flemming,

Thanks for the comments.

Please see the responses below on non-editorial comments.

James

-----Original Message-----
---------------------------------------------------
Non-Editorial:
- Mandatory or Optional tel-URI extension parameters. I believe that
"npdi" can be an optional extension, whereas "rn" and "cic" must be
mandatory extensions, since ignoring them may lead to incorrect routing
of the call. I'm not sure I fully understand the 2826bis syntax
requirements on this point (i.e., must a mandatory parameter be defined
with the "m-" prefix or not ?), but regardless it seems we need to agree
on whether the above parameters are optional or mandatory and put that
in the document.

[Yu] Based on rfc2806bis, a network node shall not process a tel URI with
unknown mandatory parameters.  In order not to cause the call be dropped
when a network node does not know the defined parameters (e.g., "rn"), they
are defined as the optional parameters.   Because if a network node that
does not know "cic" and "rn" can still route based on the phone number.
When the call (or signaling) reaches a network node that knows the new
parameters, correct action can be taken there.  

- Section 4.2.3:    Should probably add a sentence noting that the
parameter as defined here is not authenticated, and hence use of it by
any recipient for anything related to charging is done at their own
risk. Of course, the parameter may be used in protocols that actually do
provide authentication or other mechanisms that make it useful for its
intended purpose.

[Yu] Will add.

I'll also add a case where the network node is a PSTN gateway that receives
a call from the PSTN.  In that case, the "rn" info. will be mapped from the
ISUP JIP and would be "authenticated."  The issue now is whether we need to
differentiate the two (using an indicator).

- Section 4.2.4, 6th paragraph: "The network node SHALL include" => "The
network node MAY include". There are potentially several headers/cases
associated with "caller information" where I wouldn't add this parameter
and hence I'd make it a MAY instead.

[Yu] Will change.

- Section 6: "Protocols carrying the "tel" URI MAY need to ensure
message integrity" => "It is RECOMMENDED, that protocols carrying the
"tel" URI ensure message integrity"

[Yu] Will change.

- Section 7: Only the following five of the 14 parameters should be
registered with IANA: "rn", "npdi", "cic", "rn-context", "cic-context".
The rest are simply part of the ABNF and not actual parameters.

[Yu] Agree that only the above five parameters will appear in the tel URI;
therefore, need to be registered with IANA.    It is not clear if those that
are not registered can be re-used when defining new parameters in the future
(may be by referencing to this I-D/RFC?).

- Section 8:     I believe references [1], [3], and [4] are Informative.
Also, reference [2] is now 2806bis-05.

[Yu] Will change.

_______________________________________________
Iptel mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/iptel

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 07 Apr 2004 21:12:54 -0400

> Please see the responses below on non-editorial comments.

snipped the ones we're in sync on.

> -----Original Message-----

But what happens if the call does not reach a node that knows these extensions ?
Thinking a bit further about this, maybe you are right though. In the LNP case,
the telephone number that is present in the Request-URI is still the same; the
"rn" parameter would simply instruct the routing part of the system to send the
Request to another exchange than the one intended. The worst that can happen is
that the incorrectly targeted exchange does not serve this telephone number and
hence the call would fail. Similarly for the freephone number case; the number
stays the same, and the worst that can happen is that it does not reach the
intended carrier, and hence further translation of the number (which is needed
to terminate the call) will simply not happen and again we just see a call
failure. In either case, we're no worse off than if the intermediary did not
support the extension (and clearly, it would be nice if we did have to require
all intermediaries to support it). The only case that could be problematic is if
the "cic" parameter is used for non-freephone numbers (in which case you could
be using the wrong long distance carrier), but I guess the draft does not target
this particular application for the "cic" parameter. Unless somebody see
something wrong the above line of reasoning, I'm inclined to agree with them
being optional after all. Still, it would be good hear from somebody else either
way.

-- Flemming