Re: Comments on RFC2806bis

"Yu, James" wrote:

> > >
> >
> > But what if the call never arrives at a PSTN gateway or
> > SIP server that
> > understand these extensions ?
> >
>
> [JY]  The node at least has the phone number for routing decision.  If it
> does not know how to route based on a phone number, the call then fails.
> But it does, the call will continue.

OK - I'll buy that for the "rn" parameter.


>
> >
> > But again, what if the call does not arrive at such a
> > node ? You seem to be
> > arguing on the precise of assuming that if entity A does not
> > support these
> > parameters, then probably some other entity B will, and hence
> > everyting will
> > work OK. I don't find this convincing.
>
> [JY] Same as above, the call will fail if the next node does not even know
> how to route based on the phone number.  At least the call has a higher
> chance to survive if we allow it to continue with the downstream node.  The
> call will never be set up if any node in the call path will drop the call
> because it does not understand "rn" or "cic."
>

Maybe so, but as far as I can tell, it gets routed incorrectly here. Let's say I
dial 1010321+0 to reach an alternate IXC operator. 2806bis explains, that I
shall not put the dial-string in the tel-URI, but rather the telephone number,
which in this case is "0". The CIC is "0321", so my tel-URI becomes something
like "tel:0;cic=+10321". Now, if nobody understands the CIC parameter, the call
ends up at the presubscribed IXC operator, and not the alternate operator. That
doesn't seem right.

>
> >
> > 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).
>
> If a caller (SIP UA) can put in the "cic" to specify the carrier to use and
> if the outbound SIP proxy server (assume that it is operated by a service
> provider) does not understand the "cic," I don't see how that service
> provider can support this type of "dialing."
>

That is my point. If what you are trying to do is support telephone numbers,
then you need to support carrier selection, and hence it cannot be optional.


>
> I can see that when "cic" is not popularly supported by many nodes, it is
> likely that "cic" (if received in the response to the database query) may be
> mapped to a host associated with that "cic" so that "cic" is not carried in
> the tel or sip URL.  Or the carriers can set their routing tables so that
> the next node understands "cic."

That sounds like fixing the sympton, not the problem IMO. If this is what you
envision, then the limitations and pitfalls shold be pointed out clearly. As it
stands now, the CIC parameter is useless as far as I can tell (since you can't
depend on it), and we should rather simply require mapping such a selection to
an appropriate domain name and then use SIP-URIs instead of tel-URIs. Am I
missing something here ?

-- Flemming