Re: Comments on RFC2806bis

At 9:22 pm -0400 21/5/02, Flemming Andreasen wrote:
>Lawrence Conroy wrote:
><snip>
>  > 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).

To which I reply:
   great - I wondered when you seemed to suggest rolling it into the tel: URI.

>
>  > 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.
>
To which I reply:
  absolutely.
Are you suggesting that even if an intermediary doesn't understand 
the parameter,
it should not expunge it? I'm fine with that.

alternatively,
If I'm making a call and asserting a carrier selection, AND this carrier
selection has any meaning, then perforce I have to be passing my SIP call
via an entity that can act on it; specifying WCOM for use when I'm calling
the next desk may well not make sense. Specifying WCOM for use when I call
around the world might, and if I have a public service provider using SIP
then they may be forced to pass this off to WCOM (and, by definition, have
an interconnect with WCOM). I suspect that this means that *their* system
will have to include something that understands and acts on the carrier
selection request. Thus it MAY be mandatory for one of their entities
*FOR REGULATORY REASONS*, but it isn't mandatory for the call to work, and
isn't mandatory on ALL entities in their system.

[This is a non-IETF topic, IMHO, but I suspect that any public service provider
who uses SIP intermediaries may be covered by the same regulations as TSPs are
at present - even if said public service provider is Microsoft. It will be
interesting to see how this influences available choices for 
interconnect carriers :]

atb,
    Lawrence
-- 
[email protected]: +44 1794 833666::<my opinions>: