Subject: [sipcore] I-D Action: draft-ietf-sipcore-reason-q850-loc-00.txt

From: "Jesske, Roland" <[email-masked]>
Date: Wed, 20 Sep 2017 05:24:49 +0000

Dear all,
since the draft was published there were no more comments on the draft.
My opinion is that the draft is ready for further proceeding.
So I would like to ask if we could proceed with a WGLC.

Or do we need any additional discussion?

Thank you and Best Regards

Roland

> -----Ursprüngliche Nachricht-----
> Von: sipcore [mailto:[email-masked]] Im Auftrag von internet-
> [email-masked]
> Gesendet: Dienstag, 16. Mai 2017 19:10
> An: [email-masked]
> Cc: [email-masked]
> Betreff: [sipcore] I-D Action: draft-ietf-sipcore-reason-q850-loc-00.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Session Initiation Protocol Core of the IETF.
> 
>         Title           : ISUP Cause Location Parameter for the SIP Reason Header
> Field
>         Author          : Roland Jesske
> 	Filename        : draft-ietf-sipcore-reason-q850-loc-00.txt
> 	Pages           : 5
> 	Date            : 2017-05-16
> 
> Abstract:
>    The SIP Reason header field is defined for carrying ISUP cause values
>    as well as SIP response codes.  Some services in SIP networks may
>    need to know the ISUP location where the call was released in the
>    PSTN network to correctly interpret the reason of release.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-sipcore-reason-q850-loc/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-sipcore-reason-q850-loc-00
> https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-reason-q850-loc-00
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 20 Sep 2017 14:22:08 -0400

Roland,

> Or do we need any additional discussion?

I don't have major problems with this. My only question is about how the 
location values are defined, and whether other values might be valid now 
or in the future.

I looked at Q.850 and found what seems to be the definition of these 
values in section 2.2.3. That section associates these labels with 
specific four-bit values, and marks four other values as "reserved for 
national use". It also says that "all other values are spare". (There 
are four of those.)

IMO it would make sense to include some provision for specifying those 
other eight values, or a mechanism for including them in the future.

	Thanks,
	Paul

---

From: "Jesske, Roland" <[email-masked]>
Date: Thu, 21 Sep 2017 10:23:14 +0000

Hi Paul,
thank you for your comment.
The last change of Q.850 was 16 Years ago within ITU-T.
And when I remember correctly the last proposal of adding locations within Q.850 (US/ATT proposal) was also around 15 years ago and was not accepted by ITU-T.

Since nobody will invest not any longer in ISUP networks I see the chance of a new ISUP parameter at 0%.
But if people feel better I could add an token for adding further values.

Something like:
reason-extension =/ isup-cause-location
   isup-cause-location =  "location" EQUAL string/token

Token may be used by operators using national coding or an future extention of the location value by ITU-T.

What do you think.

Roland 

> Von: sipcore [mailto:[email-masked]] Im Auftrag von Paul Kyzivat
> Gesendet: Mittwoch, 20. September 2017 20:22
> An: [email-masked]
> Betreff: Re: [sipcore] I-D Action: draft-ietf-sipcore-reason-q850-loc-00.txt
> 
> Roland,
> 
> location values are defined, and whether other values might be valid now or
> in the future.
> 
> I looked at Q.850 and found what seems to be the definition of these values
> in section 2.2.3. That section associates these labels with specific four-bit
> values, and marks four other values as "reserved for national use". It also
> says that "all other values are spare". (There are four of those.)
> 
> >> Von: sipcore [mailto:[email-masked]] Im Auftrag von
> >> internet- [email-masked]
> >> Betreff: [sipcore] I-D Action:
> >> draft-ietf-sipcore-reason-q850-loc-00.txt
> >>
> >>
> >> Please note that it may take a couple of minutes from the time of
> >> submission until the htmlized version and diff are available at
> tools.ietf.org.
> >>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 21 Sep 2017 11:51:58 -0400

> Since nobody will invest not any longer in ISUP networks I see the chance of a new ISUP parameter at 0%.

Yes, I understand. But it is conceivable that the other values 
(especially the ones for national use) might be in use somewhere.

> Token may be used by operators using national coding or an future extention of the location value by ITU-T.

Instead of that, how about just defining some tokens now for all the 
other code points. (E.g. NATIONAL-1, NATIONOAL-2, ... , RESERVED-1, 
RESERVED-2, ... *or* values that correspond directly to the binary 
coding, such as LOC-12, LOC-13, LOC-14, LOC-15). That way, if 
interworking comes across one of those it can be mapped bidirectionally 
to SIP.

	Thanks,
	Paul

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 22 Sep 2017 22:27:06 -0400

> interworking comes across one of those it can be mapped bidirectionally 

I can see the advantage of providing tokens for all of the Q.850 values,
because as Paul says, somebody might be using them within a network.  As
Roland says, the Q.850 *system* is unlikely to be changed in the future,
so we can provide a complete set of translations of all possible values.
If somebody is using these values, they can interwork with SIP without
asking either ITU-T or the IETF to provide a mapping.

Dale

---

From: "Jesske, Roland" <[email-masked]>
Date: Mon, 25 Sep 2017 06:30:44 +0000

Hi Dale and Paul,
You are right with the addition of such values, everybody has the possibilities to interwork it's own parameters for national/operator use.
So I will change the table to:

The following values shall be used as location:
U    for user 
LPN  for private network serving the local user
LN   for public network serving the local user 
TN        for transit network 
RLN  for public network serving the remote user 
RPN  for private network serving the remote user 
INTL for international network 
BI   for network beyond interworking point
LOC-12  Q.850 value reserved for national use
LOC-13  Q.850 value reserved for national use
LOC-14  Q.850 value reserved for national use
LOC-15  Q.850 value reserved for national use

Are You OK with that?

Best Regards

Roland

> Von: sipcore [mailto:[email-masked]] Im Auftrag von Dale R.
> Worley
> Gesendet: Samstag, 23. September 2017 04:27
> An: Paul Kyzivat <[email-masked]>
> Cc: [email-masked]; Jesske, Roland <[email-masked]>
> > interworking comes across one of those it can be mapped
> > bidirectionally to SIP.
> 
> Roland says, the Q.850 *system* is unlikely to be changed in the future, so
> we can provide a complete set of translations of all possible values.
> If somebody is using these values, they can interwork with SIP without asking
> either ITU-T or the IETF to provide a mapping.
> 
> Dale
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 25 Sep 2017 08:56:23 -0400

> LOC-15  Q.850 value reserved for national use

There are still 4 other values. I recommend covering them as well.

	Thanks,
	Paul

---

From: "Jesske, Roland" <[email-masked]>
Date: Mon, 25 Sep 2017 13:56:37 +0000

Hi Paul,
yes you are right.
I was to lazy in looking into Q.850 which does not write out the spare values.

0 0 0 0 user (U)
0 0 0 1 private network serving the local user (LPN)
0 0 1 0 public network serving the local user (LN)
0 0 1 1 transit network (TN)
0 1 0 0 public network serving the remote user (RLN)
0 1 0 1 private network serving the remote user (RPN)
0 1 1 1 international network (INTL)
1 0 1 0 network beyond interworking point (BI)
1 1 0 0 reserved for national use
1 1 0 1 reserved for national use
1 1 1 0 reserved for national use
1 1 1 1 reserved for national use

So I was missing the Bit values 
0110
1000
1001

Ok I will rewrite a little like:

U    for user 
LPN  for private network serving the local user
LN   for public network serving the local user 
TN        for transit network 
RLN  for public network serving the remote user 
RPN  for private network serving the remote user 
Spare-1 reflecting Q850 binary value 0 1 1 0
INTL for international network 
Spare-2 reflecting Q850 binary value 1 0 0 0
Spare-3 reflecting Q850 binary value 1 0 0 1
BI   for network beyond interworking point
LOC-12  Q.850 value reserved for national use reflecting Q850 binary value 1 0 1 0
LOC-13  Q.850 value reserved for national use reflecting Q850 binary value 1 0 1 1
LOC-14  Q.850 value reserved for national use use reflecting Q850 binary value 1 1 1 0
LOC-15  Q.850 value reserved for national use use reflecting Q850 binary value 1 1 1 1

So I propose to use the values Spare-1, -2 and -3.
I hope I did not miss any more.

Best Regards

Roland
> Von: Paul Kyzivat [mailto:[email-masked]]
> Gesendet: Montag, 25. September 2017 14:56
> An: Jesske, Roland <[email-masked]>; Dale R. Worley
> <[email-masked]>
> Cc: [email-masked]
> Betreff: Re: AW: [sipcore] I-D Action: draft-ietf-sipcore-reason-q850-loc-
> 00.txt
> 
> > You are right with the addition of such values, everybody has the
> possibilities to interwork it's own parameters for national/operator use.
> > RLN  for public network serving the remote user RPN  for private
> > network serving the remote user INTL for international network
> >> Betreff: Re: [sipcore] I-D Action:
> >> I can see the advantage of providing tokens for all of the Q.850
> >> values, because as Paul says, somebody might be using them within a
> >> network.  As Roland says, the Q.850 *system* is unlikely to be
> >> changed in the future, so we can provide a complete set of translations of
> all possible values.
> >> If somebody is using these values, they can interwork with SIP
> >> without asking either ITU-T or the IETF to provide a mapping.
> >>
> >> Dale
> >>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 25 Sep 2017 11:05:29 -0400

> I hope I did not miss any more.

Just count the values. If there aren't 16 then some are missing.

You are still missing 1011. :-)  Spare-4.

You might want to make those upper case for consistency.

	Thanks,
	Paul

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 25 Sep 2017 22:23:10 -0400

I'd favor naming all of the "extra" codes after their bit combinations:

0 0 0 0 user (U)
0 1 1 0 LOC-6
1 0 0 0 LOC-8
1 0 0 1 LOC-9
1 0 1 1 LOC-11
1 1 0 0 LOC-12
1 1 0 1 LOC-13
1 1 1 0 LOC-14
1 1 1 1 LOC-15

That makes the meaning of the extra codes obvious to users who don't
regularly use them.  (I assume people who understand ISUP will know the
codes for U, LPN, etc.)  But possibly that isn't compatible with the
style by which ITU-T describes these codes.

Dale

---

From: "Jesske, Roland" <[email-masked]>
Date: Tue, 26 Sep 2017 11:56:46 +0000

Hi Dale,
for me it is no problem to go with that approach.
So I will add an table within the draft the looks like:

The following values shall be used as location:
U       for 0 0 0 0 user 
LPN     for 0 0 0 1 private network serving the local user
LN      for 0 0 1 0 public network serving the local user 
TN      for 0 0 1 1 transit network 
RLN     for 0 1 0 0 public network serving the remote user 
RPN     for 0 1 0 1 private network serving the remote user 
LOC-6   for 0 1 1 0 Spare
INTL    for 0 1 1 1 international network 
LOC-8   for 1 0 0 0 Spare
LOC-9   for 1 0 0 1 Spare
BI      for 1 0 1 0 network beyond interworking point
LOC-11  for 1 0 1 1 Spare
LOC-12  for 1 1 0 0 Spare
LOC-13  for 1 1 0 1 Spare
LOC-14  for 1 1 1 0 Spare
LOC-15  for 1 1 1 0 Spare

Best Regards

Roland

> Von: Dale R. Worley [mailto:[email-masked]]
> Gesendet: Dienstag, 26. September 2017 04:23
> An: Jesske, Roland <[email-masked]>
> Cc: [email-masked]; [email-masked]
> codes for U, LPN, etc.)  But possibly that isn't compatible with the style by
> which ITU-T describes these codes.
> 
> Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 26 Sep 2017 10:41:29 -0400

WFM

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 26 Sep 2017 20:44:17 -0400

> BI      for 1 0 1 0 network beyond interworking point

I don't want to push for this approach too hard -- if the ITU-T
recommendations have any sort of names for these values, I would favor
those.  But if there are no pre-existing names or designations, naming
them after the bit combinations seems the easiest to understand.

Dale

---

From: "Jesske, Roland" <[email-masked]>
Date: Wed, 27 Sep 2017 06:56:32 +0000

Hi Dale,
I think in such a case the naming is not very important for interworking purposes.
I made a failure. The last 4 are reserved for national use.
> > LOC-12  for 1 1 0 0 reserved for national use
> > LOC-13  for 1 1 0 1 reserved for national use
> > LOC-14  for 1 1 1 0 reserved for national use
> > LOC-15  for 1 1 1 0 reserved for national use

If nobody is against I will use the LOC values.

Best Regards

Roland

> Gesendet: Mittwoch, 27. September 2017 02:44
> those.  But if there are no pre-existing names or designations, naming them
> after the bit combinations seems the easiest to understand.
> 
> Dale

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 27 Sep 2017 21:53:46 -0400

> them after the bit combinations seems the easiest to understand.

My fault -- I forgot that I have a copy of Q.850 and can look up ITU-T's
description/names for the location codes (clause 2.2.3).  And while
ITU-T does label codes 1100 through 1111 "reserved for national use", it
does not provide distinguished names for them, not even "reserved for
national use 1", "reserved for national use 2", etc.

Dale