Subject: [Sipping] Next draft (-03) of P-Charge-Info now out

From: Dan York <[email-masked]>
Date: Tue, 13 May 2008 19:48:27 -0400

FYI, based on the feedback on this list (thanks!) Tolga Asveren and I  
have expanded/clarified the text in our draft on the P-Charge-Info  
header and version -03 is now out at:

http://www.ietf.org/internet-drafts/draft-york-sipping-p-charge-info-03.txt

The diff between this version and -02 can be seen at:

http://www.tools.ietf.org/rfcdiff?url1=http://tools.ietf.org/internet-drafts/draft-york-sipping-p-charge-info-02.txt&url2=http://www.ietf.org/internet-drafts/draft-york-sipping-p-charge-info-03.txt

or  http://tinyurl.com/6k7gwn  if that long URL doesn't work for you.

Major changes in this version:

- Provided more in the way of semantics about why this header would be  
used.
- Included a use case showing how this is being used to deal with the  
intersection of US PSTN tariffs and SIP networks.
- Expanded the security section.

I also wrote about the P-header and the rationale for it in Voxeo's  
weblog at:  http://tinyurl.com/5u6wxv

Comments and feedback are definitely welcome as we would like to head  
along the path toward requesting expert review.

Thank you,
Dan

-- 
Dan York, CISSP, Director of Emerging Communication Technology
Office of the CTO    Voxeo Corporation     [email-masked]
Phone: +1-407-455-5859  Skype: danyork  http://www.voxeo.com
Blogs: http://blogs.voxeo.com  http://www.disruptivetelephony.com

Build voice applications based on open standards.
Find out how at http://www.voxeo.com/free

_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: [email-masked] (Juha Heinanen)
Date: Wed, 14 May 2008 08:54:54 +0300

is this example in the draft correct:

P-Charge-Info: <sip:6835555555;npi=[email-masked]>

i.e., can addr-spec in <> really contain such param?

-- juha

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 14 May 2008 08:12:11 +0200

Ok, when reading the ABNF in the draft I now see that the npi parameter
is defined as a header parameter, NOT as a TEL-URI parameter.

In that case I guess Juha is correct, and the correct example would look
something like:

P-Charge-Info: <sip:[email-masked]>;npi=ISDN

Regards,

Christer

-----Original Message-----
From: Christer Holmberg 
Sent: 14. toukokuuta 2008 9:08
To: 'Juha Heinanen'; Dan York
Cc: sipping List
Subject: RE: [Sipping] Next draft (-03) of P-Charge-Info now out

Hi,

If the userpart is encoded as a telephone-number (in which user=phone
should also be added) parameters are allowed.

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Juha Heinanen
Sent: 14. toukokuuta 2008 8:55
To: Dan York
Cc: sipping List
Subject: [Sipping] Next draft (-03) of P-Charge-Info now out

-- juha
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP Use
[email-masked] for questions on current sip Use
[email-masked] for new developments of core SIP
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: [email-masked] (Juha Heinanen)
Date: Wed, 14 May 2008 09:13:29 +0300

> should also be added) parameters are allowed.

i asked if the example is correct or not.  is it?

-- juha

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 14 May 2008 08:19:38 +0200

Hi,

Subclause 6.2.2. says:

"An edge proxy supporting this extension SHOULD remove the P-Charge-Info
header before send a request to a non-gateway UA."

I think you need to define what you mean by edge proxy. Is it related to
the trust relationship procedures in subclauses 9.2.1 and 9.2.2, or do
you refer to some other "edge"?

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Dan York
Sent: 14. toukokuuta 2008 2:48
To: sipping List
Subject: [Sipping] Next draft (-03) of P-Charge-Info now out

http://www.ietf.org/internet-drafts/draft-york-sipping-p-charge-info-03.
txt

http://www.tools.ietf.org/rfcdiff?url1=http://tools.ietf.org/internet-dr
afts/draft-york-sipping-p-charge-info-02.txt&url2=http://www.ietf.org/in
ternet-drafts/draft-york-sipping-p-charge-info-03.txt

Thank you,
Dan

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 14 May 2008 08:08:17 +0200

Hi,

Regards,

Christer

-----Original Message-----

-- juha

---

From: [email-masked] (Juha Heinanen)
Date: Wed, 14 May 2008 09:25:58 +0300

Christer Holmberg writes:

 > "An edge proxy supporting this extension SHOULD remove the
 > P-Charge-Info header before send a request to a non-gateway UA."

also, i haven't heard the term "non-gw UA" before. sip only has UAs,
registrars and proxies.

-- juha

---

From: Miguel Garcia <[email-masked]>
Date: Wed, 14 May 2008 10:54:25 +0300

Hi:

Notice I had the same comment back in February:

http://www.ietf.org/mail-archive/web/sipping/current/msg15204.html

In my opinion, there is an implementation error that has been transposed 
to the draft.

/Miguel

-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Siemens Networks     Espoo, Finland

---

From: Dan York <[email-masked]>
Date: Wed, 14 May 2008 05:11:45 -0400

Miguel,

Sigh..... I thought I had gone through every comment received and  
addressed it in some manner. My apologies for missing this comment of  
yours.  I'm not personally familiar with the usage of the parameter  
(we (Voxeo) don't use the parameter) but I'll get with Tolga and we'll  
sort this out.  ABNF is admittedly an area I'm still learning.

Thanks for the comments,  (and thanks to Christer and Juha as well)
Dan

On May 14, 2008, at 3:54 AM, Miguel Garcia wrote:

> In my opinion, there is an implementation error that has been  
> transposed to the draft.
>
> /Miguel
>
> Christer Holmberg wrote:
>> From: Christer Holmberg Sent: 14. toukokuuta 2008 9:08

---

From: Dan York <[email-masked]>
Date: Wed, 14 May 2008 05:35:02 -0400

Christer and Juha,

Responses inline prefixed by "DY>"

> you refer to some other "edge"?

DY> Good catch (and I note the sentence also has a grammatical error  
in it).  I agree we need to define/change our usage there as this is  
really referring to the SIP proxy at the edge of a cloud of SIP  
proxies that is communicating to UAs. It's not the network edge as in  
9.2.x as it is still within the trust domain. I think I'll just remove  
the word "edge".

> also, i haven't heard the term "non-gw UA" before. sip only has UAs,

DY> Good point, but perhaps this is where we get into a bit of a  
wording dilemma.  As noted in 6.2.1, there are some PSTN gateways that  
represent themselves in the world of SIP as UAs.  To the other SIP  
entities it appears as a UA, but in fact it is a gateway to the PSTN.

DY> Here's the text of that section:
--------------------------------------------------
6.2.1.  Procedures at the UA

    The P-Charge-Info header may be inserted by PSTN gateways acting  
as a
    SIP UA, either through local policy or as a result of information
    received via PSTN signaling, e.g. the charge parameter in an ISUP  
IAM
    message.

    The P-Charge-Info header is not used/interpreted by a regular (i.e.
    non-gateway) UA and should not normally be seen by such a UA.  If  
the
    header is transmitted to such a UA, the UA SHOULD ignore the header.

    A gateway UA MAY use the content of the P-Charge-Info header present
    in an INVITE request it received for billing related procedures,  
e.g.
    in a billing record or during interaction with another entity
    generating billing records, as the identity of the party to be
    charged for the session.  A gateway UA MAY use the content of the
    P-Charge-Info header to populate information about the identity of
    the party to charge in another type of signaling, e.g.  ISUP.
--------------------------------------------------

DY> So for those "UAs that are really PSTN gateways", this P-Charge- 
Info header has relevance. For "regular UAs that are not PSTN  
gateways", the P-Charge-Info header has no relevance and should  
ideally be removed before being sent to such a UA.

DY> Is there a better way to be describing these "PSTN gateway UAs"? a  
better term to use?

Thanks for the comments,
Dan

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 14 May 2008 09:56:47 +0200

Hi,

It would be possible to use:

...but then you would need to define npi as a TEL-URI parameter.

Regards,

Christer

-----Original Message-----
From: Miguel Garcia [mailto:[email-masked]] 
Sent: 14. toukokuuta 2008 10:54
To: Christer Holmberg
Cc: Juha Heinanen; Dan York; sipping List
Subject: Re: [Sipping] Next draft (-03) of P-Charge-Info now out

Hi:

/Miguel

Christer Holmberg wrote:
>  
> Ok, when reading the ABNF in the draft I now see that the npi 
> parameter is defined as a header parameter, NOT as a TEL-URI
parameter.
> 
> In that case I guess Juha is correct, and the correct example would 
> look something like:
>

---

From: "Ian Elz" <[email-masked]>
Date: Wed, 14 May 2008 13:27:18 +0200

Christer, Miguel,

If you are to make npi a Tel-URI parameter as Christer suggests then it
all becomes a little meaningless. At present RFC 3966 only specifies
E.164 numbers, i.e. no support for Data X.121, Telex F.69, or E.212.

In fact including "npi=isdn" in Tel is superfluous as npi=isdn means
E.164 numbering plan.

What is missing from the proposed format is the "+" which is used by the
TEL-URI as a NoA (Nature of Address). RFC 3966 of course refers to this
as the global form and then associates this global form with E.164. All
of the other forms may also be E.164.

Ian Elz

System Manager
DUCI LDC UK
(Lucid Duck)

Office: + 44 24 764 35256
gsm: +44 7801723668
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Christer Holmberg
Sent: 14 May 2008 08:57
To: Miguel Garcia
Cc: sipping List
Subject: Re: [Sipping] Next draft (-03) of P-Charge-Info now out

Hi,

Regards,

Christer

-----Original Message-----
From: Miguel Garcia [mailto:[email-masked]] 
Sent: 14. toukokuuta 2008 10:54
To: Christer Holmberg
Cc: Juha Heinanen; Dan York; sipping List
Subject: Re: [Sipping] Next draft (-03) of P-Charge-Info now out

Hi:

/Miguel

parameter.

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 14 May 2008 13:47:08 +0200

Hi,

I am not suggesting to make a TEL-URI parameter. I just said that, if he
wants to use it as in the example, it has to be a TEL-URI parameter :)

Regards,

Christer

-----Original Message-----
From: Ian Elz 
Sent: 14. toukokuuta 2008 14:27
To: Christer Holmberg; Miguel Garcia
Cc: sipping List
Subject: RE: [Sipping] Next draft (-03) of P-Charge-Info now out

Christer, Miguel,

Ian Elz

System Manager
DUCI LDC UK
(Lucid Duck)

-----Original Message-----

Hi,

Regards,

Christer

-----Original Message-----
From: Miguel Garcia [mailto:[email-masked]]
Sent: 14. toukokuuta 2008 10:54
To: Christer Holmberg
Cc: Juha Heinanen; Dan York; sipping List
Subject: Re: [Sipping] Next draft (-03) of P-Charge-Info now out

Hi:

/Miguel

parameter.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 14 May 2008 14:16:31 -0400

> you refer to some other "edge"?

I think the issue is more severe than that. In general a node cannot 
know what the properties are of a node it is sending to - whether it is 
a proxy, UA, B2BUA, Gateway, etc. And it may not know if it is at the 
"edge", whatever that is.

About all I think you can say with certainty is that a node (any kind) 
should remove this header if it is sending the request to a node it does 
not trust.

	Paul

---

From: Dan York <[email-masked]>
Date: Tue, 20 May 2008 14:38:38 -0400

Christer, Juha & Miguel,

You all are correct. The example in the draft is wrong. I confirmed  
with Tolga (as my own usage does not involve the parameter) and it  
should be as Christer (and earlier Miguel) indicated:

I'll rev the draft accordingly.  Not sure why I missed that part of  
your comments back in February, Miguel, as I know I did incorporate  
your comments related to the ABNF.  In any event, the correction will  
now be made.

Thank you all for the catch,
Dan

On May 14, 2008, at 3:54 AM, Miguel Garcia wrote:

>> parameter
>> look