Subject: Re: [IPTEL] Comments on RFC2806bis

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 21 May 2002 10:57:38 -0400

> - 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.
> 
> I suggest that 2806bis discuss whether a node drops or keeps "unknown"
> optional parameters when it receives the INVITE message and needs to send
> another INVITE message out.  It seems better to keep the unknown optional
> parameters in the message because the next node may be able to handle it. 
> 

2806bis is not SIP-specific, so it would not be appropriate to discuss 
transformations of URLs there. Generally, the normal URL rules in SIP apply.

> Can the country code contain hex digits? Is there the possibility 
> that country codes need more than three digits? Does East Timor have its 
> own country code?
> 
> [JY]
> According to E.164, country codes (CCs) can be assigned
> 
> - For geographical areas - CCs are one to three digits long.
> 
> - For global services -  CCs are always three digits long.
> 
> - For shared international networks - CCs are always three digits long.
> 
> In all three cases the CCs do not contain digits A thru F.
> 
> The global routing number I have in mind will always start with "+CC" where
> the CC does not contain digits A thru F and the digits after CC may contain
> hex digits.  So a global routing number, rn=+1-202-533-1234, would be the
> same as a local routing number, rn=202-533-1234;phone-context=+1. 
> 
> May be we can use "number-context" instead of "phone-context" so that it can
> be used for the phone number and routing number.

I thought somebody already complained when I had accidentally changed 
the label to "context". If a change is acceptable, I'd rather go for the 
shorter "context". In the end, I don't think the name much matters, as 
long as the description is clear.

> James

_______________________________________________
IPTEL mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/iptel

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 21 May 2002 11:15:57 -0400

"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:
>

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

---

From: Lawrence Conroy <[email-masked]>
Date: Tue, 21 May 2002 18:06:32 +0100

>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-masked]: +44 1794 833666::<my opinions>:
_______________________________________________
IPTEL mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/iptel

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 21 May 2002 21:22:20 -0400

> cases - Indeed, for the static (DNS) cases one may or may not need this

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.

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

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

-- Flemming

---

From: Lawrence Conroy <[email-masked]>
Date: Wed, 22 May 2002 03:24:47 +0100

At 9:22 pm -0400 21/5/02, Flemming Andreasen wrote:
><snip>

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

>the forwarding path understand this parameter and route accordingly 
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

---

From: Lawrence Conroy <[email-masked]>
Date: Wed, 22 May 2002 19:07:11 +0100

At 10:57 am -0400 21/5/02, Henning Schulzrinne wrote:
>
>I thought somebody already complained when I had accidentally 
>changed the label to "context". If a change is acceptable, I'd 
>rather go for the shorter "context". In the end, I don't think the 
>name much matters, as long as the description is clear.

To which I reply:

Hi Henning, folks,
  first, sorry for the delay; takes a time to contact people.
Speaking as the person who complained (loudly) at the change
from "phone-context", I've checked in-house.

We have two implementations with this - one for PINT and one
for SIP. I've checked with the respective developers and sales
people, and they agreed that they can handle a name change with
no problem (I thought so, but had to check :).

Hence, as the URI is getting long, if people want to change
from 'phone-context' to, for example, 'context' then that's
fine by us.

all the best,
   Lawrence

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 22 May 2002 14:36:26 -0400

Last call to rest of group: Please let me know immediately if the 
parameter name change to 'context' causes you grief.

---

From: "Brett Tate" <[email-masked]>
Date: Wed, 22 May 2002 15:28:06 -0400

> Last call to rest of group: Please let me 
> know immediately if the parameter name 
> change to 'context' causes you grief.

The name change would cause grief for 
BroadSoft because we have products deployed 
within networks which send, receive, and
use phone-context.  An attempt to rename 
or introduce a short-form of the parameter 
would complicate interoperability.

Also rfc2806 allowed a much greater 
non-escaped character-set for the 
phone-context value.  Reducing this 
character-set within rfc2806bis will
potentially also cause some grief.

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 22 May 2002 15:55:56 -0400

> would complicate interoperability.

Sounds like a definitive answer. It stays "phone-context".

> potentially also cause some grief.

The previous definition was not interoperable, so I'm not inclined to 
change this. This is not a character-set issue but defining in a 
meaningful way what phone-context means and minimizing the damage caused 
by local phone URIs that escape their intended scope. I believe there 
was group consensus on that, but as usual in the IETF, this is subject 
to re-discussion at any point :-)

---

From: Lawrence Conroy <[email-masked]>
Date: Wed, 22 May 2002 21:54:42 +0100

At 3:55 pm -0400 22/5/02, Henning Schulzrinne wrote:
>>The name change would cause grief for BroadSoft because we have 
>>products deployed within networks which send, receive, and
>>use phone-context.  An attempt to rename or introduce a short-form 
>>of the parameter would complicate interoperability.
>

This saves each of my guys at least 30 seconds quality time, so fair enough.

I am, however, surprised if Brett means that a comma-separated list form
will cause grief. Anyone dealing with tel: URIs will almost certainly have
to deal with other parameters (mandatory or otherwise :).

>  it is.
>>
>>Also rfc2806 allowed a much greater non-escaped character-set for 
>>the phone-context value.  Reducing this character-set within 
>>rfc2806bis will
>The previous definition was not interoperable, so I'm not inclined 
>to change this. This is not a character-set issue but defining in a 
>meaningful way what phone-context means and minimizing the damage 
>caused by local phone URIs that escape their intended scope. I 
>believe there was group consensus on that, but as usual in the IETF, 
>this is subject to re-discussion at any point :-)
>
I also will be VERY unhappy if the old Reverse Hungarian is retained.
I understand 2806bis phone-context to a pure sub-set of the 2806 list
of hex ranges. It's also clear in intent, exactly as Henning says.

Testing therefore should not be a problem - your installed base is
capable of handling this "narrowed" set adequately.

Brett - are your machine generating private context values, or the 
local-prefix Morse code allowed in 2806?
I'm Puzzled.

all the best,
    Lawrence

---

From: "Brett Tate" <[email-masked]>
Date: Thu, 23 May 2002 13:57:04 -0400

> will cause grief. 

Commas are no problem, and coding is
no problem.  It would be a deployment
and interoperability inconvenience resulting
from some devices supporting rfc2806,
others only supporting rfc2806bis.

> Anyone dealing with 
> tel: URIs will almost certainly have

Agreed.  Just as an FYI, rfc2806 section
2.5.11 mentions to reject the request 
if any parameters were unknown.  For 
example if cic was present and you do 
not know what cic means, the message
MUST be rejected.
 
> local-prefix Morse code allowed in 2806?

The rfc2806bis definition of phone-context 
replaced the private-prefix with domainname.
Both have effectively the same meaning within 
telephone-subscriber; however domainname
reduces the character-set of what can be 
considered a valid value within phone-context.  

rfc2806bis also imposes a domainname 
format upon rfc2806's private-prefix.

The rfc2806bis example of
phone-context=cs.columbia.edu
isn't valid in rfc2806
because it started with a 'c'.

I agree that the new phone-context 
definition is better since it forces 
structure for potential use with DNS, and it 
provides an explicit solution to avoid 
accidental duplicate private-prefix names.

We can reformat our rfc2806 usage of 
private prefixes to accommodate the 
rfc2806bis format.

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 23 May 2002 14:17:10 -0400

> others only supporting rfc2806bis.

You haven't identified what these "inconveniences" would be. I think 
there's general agreement that allowing random character string in 
context is a potentially large interoperability problem, so we have to 
pick our poison.

> not know what cic means, the message

We want to arrive at a more nuanced version, I think. Thus, the 
distinction between the two parameter types.

> considered a valid value within phone-context.  

As noted, any other random strings are likely to collide and thus create 
interoperability issues.

> private prefixes to accommodate the 

Glad to hear that. There having been no other notes on this topic, can 
we declare it closed?

---

From: "Brett Tate" <[email-masked]>
Date: Thu, 23 May 2002 15:00:22 -0400

> interoperability problem, so we have to 

My above comment was in response to the slam
about the 30 second development effort to 
rename "phone-context" to be "context".  
It was not regarding the valid contents
of phone-context.

> no other notes on this topic, can 

Yes, assuming your prior email is
still correct that "phone-context" 
shall not be renamed to be "context".