RE: Comments on RFC2806bis

I agree
Here we dial the carrier selection, if we don't handle these numbers they
will not routing to right path.

Roberto Crizza -   CCDA			
EDS Brazil - CI - Telecomunicacoes
I. Solutions  - DowNet Project
Phone.: 55 11 3471-4536 (8-893- )
Fax.:      55 11 3471-4557 (8-893- )
Cell.:      55 11 9531-9695 
email.:    [email protected]



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.

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

For both these reasons, I belive that this is a stand-alone extension, and
is NOT a core part of RFC2806bis. Note that we lost the 'tsp=' parameter as
well in the bis process; that would also be a stand-alone extension.

all the best,
   Lawrence

-- 
[email protected]: +44 1794 833666::<my opinions>:
_______________________________________________
IPTEL mailing list
[email protected]
http://lists.bell-labs.com/mailman/listinfo/iptel