Subject: Re: [IPTEL] Comments on RFC2806bis

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 20 May 2002 23:13:18 -0400

> 
> Is there a reason why "context" is put inside ()? 

No, but it doesn't matter, since the () are just grouping. I removed the ().

  Also, the syntax allows
> more than one "context" parameter.  Is it possible to have more than one
> "context" in real situation?  If yes (e.g., two domain names plus one
> prefix), which one is to be used?  Suggest to add some discussions about the
> allowed situation where more than one contexts occur.

This was supposed to be an "OR", i.e., the number applies in all such 
contexts. However, come to think of it, that's probably a bad idea. I 
don't think URIs typically have multiple parameters with the same name. 
Some parsers are likely to not take this gracefully. For the OR case, 
the pickings are slim, however:

- + is taken
- comma and semicolon are not allowed (without escaping)
- / doesn't fit well and would be confusing
- . doesn't work for domain names
- : is one possibility, as in

tel:1234;phone-context=example.com:+12345

Other suggestions welcome.

> 
> I've the "global routing number" parameter that begin with the country code
> followed by hex digits.  Is it possible for you to describe "country code"
> part of the global-number-part so that I can use it in my I-D.  I hate to
> see that the "extensions" defines something in more details.  The first one
> to three digits of the global-number-part identify the country code.

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

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

---

From: Lawrence Conroy <[email-masked]>
Date: Tue, 21 May 2002 10:28:57 +0100

At 11:13 pm -0400 20/5/02, Henning Schulzrinne wrote:
in response to James' comments -
>This was supposed to be an "OR", i.e., the number applies in all 
>such contexts. However, come to think of it, that's probably a bad 
>idea. I don't think URIs typically have multiple parameters with the 
>same name. Some parsers are likely to not take this gracefully. For 
>the OR case, the pickings are slim, however:
>
>- + is taken

Actually, I can think of a number of situations in which an identifier
can be used for different objects.

The context is a qualifier on the applicability of the URI. It's not
really more than one parameter - The single parameter 'phone-context' can
have more than one value. This can happen due to introduction of relief codes,
or the Vienna case, where there are two codes to dial Vienna (within Austria).
Thus a Viennese phone could have two values for its phone context (01 and the
old code - can't remember what this is, off hand). As an aside, the old code
is not valid outside Austria, so writing this in International form is strange.

[Also, for example, the tel: number might be associated with voice telephony
or fax or mms or... I understand that one can use SIP as a "Service Resolution
Service" and am still thinking on whether or not such explicit service idents
are ever needed, but these could indeed have more than one value to 
the hypothetical
parameter 'service' - I suspect that these would be 'hints' rather 
than mandatory]

This, BTW, is why I originally asked the dumb question on comma separated list
values. The conclusion of that is that there will be a set of params, each with
one value. The alternative (there is one parameter with multiple values) needs
to be syntactically valid, but may be more compact.

Any ideas on value separators - is the above an exhaustive list?

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

Hmm...should be in E.164, IMHO. Will look.

BTW, James, the conclusion we had was that a RN is not in International format
so that a local number is OK when using HEXDIG. I can't think of a situation
where one needs a "pseudo-E.164" number with HEXDIG in the 
country/service code.
Was this your intention?

atb,
   Lawrence
-- 
[email-masked]: +44 1794 833666::<my opinions>:
_______________________________________________
IPTEL mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/iptel

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 21 May 2002 08:27:45 -0400

> Any ideas on value separators - is the above an exhaustive list?

I agree that multiple contexts are useful. The choice of separators is

Systematically, from RFC 2396

delims      = "<" | ">" | "#" | "%" | <">

are out, as are

  unwise      = "{" | "}" | "|" | "\" | "^" | "[" | "]" | "`"

The best set to draw from is

  reserved    = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" |
                     "$" | ","

as they are meant for delineation. For tel URLs, ";", "+", "=" are 
taken. I was wrong about the comma - it's a legitimate separator. I 
suspect I got confused by the difficulty that this sometimes causes in 
Contact and To/From SIP headers, requiring <> enclosure.

 From the set, "&" or "," seem the most semantically meaningful. May as 
well use the comma.

---

From: Michael Hammer <[email-masked]>
Date: Tue, 21 May 2002 15:52:07 -0400

It would not be a good idea to use a local dial plan in an international 
number format as suggested for Vienna.

I assume that E. Timor as a newly created country might not have one now, 
but would likely get one quickly.

Finally a random number, if the first few digits matched a dial plan could 
be routed.  Excess digits could be ignored.  But random hex digits might 
have a harder time.

Mike

At 10:28 AM 5/21/2002 +0100, Lawrence Conroy wrote:
>>Some parsers are likely to not take this gracefully. For the OR case, the 
>>pickings are slim, however:
>>
>>- + is taken
>are ever needed, but these could indeed have more than one value to the 
>hypothetical
>parameter 'service' - I suspect that these would be 'hints' rather than 
>mandatory]
>
>where one needs a "pseudo-E.164" number with HEXDIG in the country/service 
>code.
>Was this your intention?
>
>atb,
>   Lawrence
>--

---

From: Lawrence Conroy <[email-masked]>
Date: Wed, 22 May 2002 17:34:10 +0100

At 3:52 pm -0400 21/5/02, Michael Hammer wrote:
>It would not be a good idea to use a local dial plan in an 
>international number format as suggested for Vienna.
>
>In response to my earlier posting
>>

To which I respond:
Hi Mike, folks,

(This may be where we get to counting the number of Angels on a pinhead :)

Strictly, the old code is blocked at the International Gateway Exchange.
Thus it can be written as a valid E.164 number; it is just blocked from
International origination. Both versions are unambiguous, it's just that
one is not routable from some origination points.

+43-22-123456 - is this an E.164 number?
+43-1-123456 - is this an E.164 number?
If these are dialled from within Austria, they should terminate at the same
'phone. If you try to dial the first variant outside Austria, it's blocked.

Thus I can imagine this kind of URI:

<tel:123456;phone-context=+431;phone-context=+4322>

but...the fully routable one would be:

<tel:+43-1-123456>

Thus, I'm not sure I understand the concern.

all the best,
    Lawrence

---

From: Michael Hammer <[email-masked]>
Date: Wed, 22 May 2002 18:38:49 -0400

>'phone. If you try to dial the first variant outside Austria, it's blocked.

I don't understand how you can call the number international if it is 
blocked when dialed outside Austria.  Isn't that an oxymoron of some type?

Mike

---

From: Lawrence Conroy <[email-masked]>
Date: Thu, 23 May 2002 00:07:03 +0100

At 6:38 pm -0400 22/5/02, Michael Hammer wrote:
>I don't understand how you can call the number international if it 
>is blocked when dialed outside Austria.  Isn't that an oxymoron of 
>some type?

Nope.
There are numbers that can be called between several networks and 
within a Group of Countries but are not universally available. Try 
phoning North Korea.
An E.164 number is globally unique, not necessarily globally routable.
=> It's a strange one if 'tis an Oxymoron.

>>Thus, I'm not sure I understand the concern.
I still don't.

atb,
   Lawrence

---

From: Michael Hammer <[email-masked]>
Date: Thu, 23 May 2002 10:02:35 -0400

So what happens if someone dials this "international" number from a 
location outside of Austria and it gets routed through SIP to a GW within 
Austria, is that considered originated inside Austria and therefore 
allowed, or is it considered dialed outside Austria and therefore blocked?

Mike

At 12:07 AM 5/23/2002 +0100, Lawrence Conroy wrote:
>There are numbers that can be called between several networks and within a 
>Group of Countries but are not universally available. Try phoning North Korea.

---

From: Michael Hammer <[email-masked]>
Date: Thu, 23 May 2002 10:04:49 -0400

p.s.  If it is not dial-able outside of Austria, what is the point in 
pre-fixing it with 43?  Wouldn't it be more accurate to leave that off and 
mark it as a national call?

Mike

---

From: Lawrence Conroy <[email-masked]>
Date: Thu, 23 May 2002 15:42:02 +0100

At 10:02 am -0400 23/5/02, Michael Hammer wrote:
>location outside of Austria and it gets routed through SIP to a GW 
>within Austria, is that considered originated inside Austria and 
>therefore allowed, or is it considered dialed outside Austria and 
>therefore blocked?
>
>Mike
>
To which I reply:
Good morning Mike, folks,
   The essential question is whether or not there is a route to the 
destination from your origination point.
The destination address may be unique (as in an E.164 number), 
without a route through to it from your place.

Answering your question as asked - it's allowed, IMHO.
However, whether the call is delivered depends on whether or not the 
Destination network Gateway Exchange through which your "far end" SIP 
MGW connects allows routing to the number it has received or not. It 
probably does.

This is a specific case; we should really generalise. However, for 
your entertainment...

Austria (as does Germany) uses a flexible numbering plan.
The current ITU recommendation on maximum NSN length means that, if 
someone tries to dial (using the old code) a Vienna number that is 
connected via a PBX from another Country (or an interconnect that 
uses a DN within the ISUP message that is in International Format), 
the number could exceed the maximum size allowed for a DN (15 digits, 
I seem to remember).
Remember that Austria has a 2 digit country code, the old code for 
Vienna was 222 (another 3 digits), so that leaves a maximum of 10 
digits for the complete local number, including any extension.

To avoid this truncation risk, the choice was to change the area code 
for Vienna to 1.
However, everyone in Austria is used to dialling 0222 to get Vienna, 
thus the two codes run in parallel.
The only problem is that, if the International Gateway exchange gets 
a number with area code 222, that number may have been truncated. To 
avoid trying to place the call using an incomplete number, it's 
blocked.
The 15 digit limit is not a problem within Austria (as International 
Register length is not an issue), so it passes.

Thus, your question should be - can the destination number I've 
dialled be delivered to the far end gateway without truncation, and 
if so, is that far end MGW connected so that it can avoid using 
(International) ISUP messages when placing the call onwards to the 
destination end point.

This may also address your subsequent question - the reason to have 
this as an E.164 number is that it won't change in the future as 
maximum register size increases; the only thing that will change is 
whether or not a call origination has gone via an ISUP interconnect 
that might have truncated it.

all the best,
   Lawrence