Re: Comments on RFC2806bis

Flemming Andreasen <[email protected]> Tue, 21 May 2002 11:15:57 -0400
Newsgroups gmane.ietf.iptel
Message-ID <[email protected]>

"Yu, James" wrote:

> -------- Flemming Andreasen --------
> I must be missing something then. How can a CIC code and a routing number be
> optional ? Are
> you saying you can just ignore carrier selection and route ported numbers to
> the old
> exchange ?
>
> [JY]
> Comparing the following two:
>
> - A node does not understand "m-rn" or "m-cic" and stops processing the SIP
> INVITE message
>
> - A node does not understand "rn" or "cic" and routes based on the phone
> number
>
> The choice is the latter.  This is because when the call arrives at a PSTN
> gateway or another SIP proxy server, that gateway/server may understand "rn"
> or "cic" or may be able to do another NP/800 database dip.
>

But what if the the call never arrives at a PSTN gateway or SIP server that
understand these extensions ?


> The "cic" case may be more complicated.  If the tel URL has an 800 number
> and a "cic" and the node does not understand "cic," it will route based on
> the 800 number.  Such a node is not likely to launch 800 database queries.
> It is more likely configured to route the call to another node that can
> handle the 800 calls.

But again, what if the 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.

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.

Thanks

        Flemming