Re: Comments on RFC2806bis

James,

Could you clarify, if a service provider does not support these parameters 
(cic= and rn=) how this information is mapped into SIP?  Does this mean 
that there is more than one way to support this?  Are you suggesting that 
sip: uris are preferred over tel: uris for ISUP to SIP translation?

I would assume that in certain regulatory environments that the ability to 
dial and be routed to a "1010-XXX" type number would be mandatory.

Mike

At 11:10 AM 5/24/2002 -0400, Flemming Andreasen wrote:


>"Yu, James" wrote:
>
> >  -- Flemming Andreasen wrote --
> > >
> > > 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.
> >
> > [JY]  We are addressing VoIP issues.  If the caller is using a specific
> > service provider for outbound calls, then he had better make sure that his
> > "presubscribed" service provider supports the "cic;" otherwise, the way you
> > describe will not work (but the call will still be completed, serviced by
> > his service provider). If that service provider does not support the "cic"
> > and the caller really wants the "carrier selection," then he just need to
> > send that particular SIP INVITE message to the host associated with the
> > selected carrier/service provider (if his SIP UA can be easily 
> configured to
> > do this once in a while task).
> >
>
>I think this needs to be pointed out clearly in the draft, as it is not what I
>would have expected.
>
>
>
> >
> > >
> > >
> > > 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 ?
> >
> > [JY]  The "cic" is designed for supporting freephone service (e.g., used
> > within the networks by the carriers/service providers).  Carrier selection
> > is a side product.  A carrier/service provider can support the "cic" for
> > carrier selection and use it as a selling point.  I view "carrier 
> selection"
> > as a feature, which may or may not offered by a carrier/service provider.
> > If an end user cannot get this feature from a carrier/service provider, he
> > can always turn to another for such a service.
>
>That was not my understanding of current (US) legislation for telephony, 
>but I'm
>not an expert on this. If you insist on keeping these semantics, then the
>document needs to point this out as well as the consequences more clearly.
>
>Thanks
>
>         Flemming
>
>
>
>
>_______________________________________________
>IPTEL mailing list
>[email protected]
>http://lists.bell-labs.com/mailman/listinfo/iptel