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

["Yu, James" <[e-mail]>]

Flemming,

Glad to see that your analysis reached the conclusion of using "optional"
instead of "mandatory" for the defined parameters because this causes less
call rejections.

If I don't hear from others that favor "mandatory" parameter in two weeks,
I'll assme that it is agreed those defined parameters are optional.

James

> ---------------------------------------------------
> 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.
>

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





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

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