Re: Comments on RFC2806bis

Lawrence Conroy wrote:

> Flemming wrote:
> >
> >Take another example where I as a consumer actually dial a particular carrier
> >selection code as part of my call, but by default, all my calls are handled by
> >another carrier. I don't see how you will route this call correctly without a
> >guarantee that at least one entity in the forwarding path understands the
> >extension (not to mention the fact that routing can be rather inefficient if
> >preceeding hops routed the call incorrectly because they didn't understand the
> >extensions).
> >
> >In other words, I don't see how these parameters can be optional. If you are
> >concerned about lack of implementation support, then perhaps the best way to
> >address that is by including the extensions in 2806bis, since they
> >do seem to be
> >a prerequisite for a generally useful tel-URI.
> >
> To which I reply:
>   It can be used in SIP, but it can also be used in a static form
> (e.g. DNS NAPTR
> content). In the latter case, it may be in the public ENUM space, or it might
> be stored within a Service provider's private space.
>
> I do not believe that a rn or cic parameter is a prerequisite for all these
> cases - Indeed, for the static (DNS) cases one may or may not need this
> parameterisation at all.
>

Right, but I was talking about a *generally useful tel-URI*, not a SIP-URI, or some
private database scheme. In that case, all you have is the tel-URI and the
information it contains. If part of that information is the CIC and the call is
supposed to be routed based on the CIC, but it doesn't, then something is wrong.


>
> I agree with James that it cannot be mandatory (i.e. "use this or fail").
> For example, looking at the SIP case, a recipient of a SIP dialog may or
> may not have a trust relationship with the sender of this information.
> If they do not then they are at liberty to do another dip themselves.

I agree (and don't think I said anything to the contrary).


>
> Thus a mandatory "do or die" is not appropriate, IMHO.
>
> My DSL router/FW/SIPproxy/Registrar box at home sure doesn't understand
> this parameter. Then again, when I outcall with this kind of URI there
> WILL be some external outbound proxy and/or gateway in line, and whilst
> understanding this parameter by *that* box may be required (for regulatory
> reasons ?), I'd be really unhappy if my home box were to be declared
> non-standard because it cannot understand nor act on a cic value but
> instead passes it downstream.
>

I appreciate that problem and share your concern, however the current solution
doesn't seem to work as far as I can tell. You need to have at least one entity in
the forwarding path understand this parameter and route accordingly based on it.

-- Flemming