Subject: RE: [SIP] draft-jfp-sip-isup-header-00.txt - presentation restric ted

From: "Venkatesh Venkataramanan" <[email-masked]>
Date: Thu, 15 Mar 2001 22:32:51 -0800

Hi:

Have a couple of questions/suggestions regarding the same... Was wondering
if we should define a new header for the Charge-Info(could be used by any
intermediate proxies that are responsible for Billing). The BNF could be the
same as that of a SIP URL.

As regards Carrier-Identification, I was wondering if it made sense to
extend caller preferences to pass this information along as against defining
new extensions in an URL. After all carrier identification is a "Callers
Preference"? [unless my understanding of what carrier identification is
totally wrong :-)].

I don't know if we need to have anything special for representing the cause
value in a disconnect. I think an earlier draft by Camarillo, Roach et al
comprehensively maps all cause codes in a REL to appropriate SIP response
codes...

As regards Calling Party Category (mentioned as future item) I was wondering
if it made sense to simply add the same in the From SIP URL (use the
flexibility provided in a SIP URL's other-params)... say, From: <sip:.....
>; cpc=test; or cpc=ordinary?? Would that make sense??

Venkatesh

-----Original Message-----
From: Jean-Francois Mule [mailto:[email-masked]]
Sent: Thursday, March 15, 2001 7:45 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: [SIP] draft-jfp-sip-isup-header-00.txt - presentation
restricted

Another comment:
this draft seems to make a recommendation on how to translate the
presentation indicators into the sip From: address of record at the
far-end gateway only.  It is not clear however, how the indicators are
propagated along the sip entity chain, from the sip ua originating the
session to the far end, passing by multiple sip proxies...
Indeed, within the calling party's domain, some sip proxies may make use
of the ANI or A number to apply some routing rules...
Is this specified somewhere?

Jean-Francois.

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
[email-masked] with "subscribe" in the body.

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
[email-masked] with "subscribe" in the body.

---

From: [email-masked]
Date: Fri, 16 Mar 2001 00:22:51 -0700

Responses below marked up with <JFP>.

Jon Peterson
Level(3) Communications

-----Original Message-----
From: Venkatesh Venkataramanan
[mailto:[email-masked]]
Sent: Thursday, March 15, 2001 11:33 PM
To: Jean-Francois Mule; Peterson, Jon; [email-masked]
Cc: [email-masked]
Subject: RE: [SIP] draft-jfp-sip-isup-header-00.txt - presentation
restric ted

Hi:

<JFP> Well, the general precept of SIP-T translation is that one translates
those only ISUP parameters that are useful in routing the call (although
obviously the preservation of ISUP context for endpoints that cannot
understand ISUP encapsulation is also a factor). Charge-Info is one of those
borderline cases in which the information probably isn't useful for routing
the call, but might be desired by some later endpoint in the routing chain. 

As an alternative to potentially adding new headers, I might suggest either
that entities performing billing have access to the ISUP (there are a few
other parameters they could conceivably be interested in as well - I don't
think the Charge-Info alone would solve all billing problems), or, if that
isn't feasible, that the gateway cut some sort of ISUP-rich record which can
be trivially correlated with downstream SIP signaling. Do you think either
of these options would be sufficient? </JFP>

<JFP> Well, the caller might not actual select the Carrier Identification
Code associated with a call; an 800 number translation, for example, can
associated a carrier identification with a call. The Caller Preferences
specification is an enormously useful extension which doesn't happen to have
much obvious bearing on this problem. Also, note that the cic= mechanism
isn't an extension to SIP, but an extension to the tel URL. </JFP> 

<JFP> Quite. </JFP>

>; cpc=test; or cpc=ordinary?? Would that make sense??

<JFP> Actually, that's rather what I had in mind, with the minor tweak that
I was considering it as an extension to the tel URL. The only real
complication is that there are many national network-specific values for the
CPC that would be difficult to capture. </JFP>

Venkatesh

-----Original Message-----
From: Jean-Francois Mule [mailto:[email-masked]]
Sent: Thursday, March 15, 2001 7:45 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: [SIP] draft-jfp-sip-isup-header-00.txt - presentation
restricted

Another comment:

Jean-Francois.

---

From: "Mark Watson" <[email-masked]>
Date: Fri, 16 Mar 2001 11:38:17 -0000

It would be worth looking at the new privacy draft in this context.

This provides the ability to carry 'restricted' indentity information
between trusted entities. The idea in the new privacy draft is to provide a
common platform for handling identity information which all applications
requiring privacy/authenticity handling can make use of.

This should save us effort in inventing new headers for identity
information, and hence having to re-invent the privacy/authenticity handling
for each new header.

Regards,

Mark Watson

> Sent: 16 March 2001 03:45

---

From: "Venkatesh Venkataramanan" <[email-masked]>
Date: Fri, 16 Mar 2001 10:00:53 -0800

Comments Interspersed...

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, March 15, 2001 11:23 PM
To: [email-masked]; [email-masked];
[email-masked]

Jon Peterson
Level(3) Communications

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

Hi:

<VENKATESH> The above works fine for ISUP-SIP-ISUP scenarios. The reason why
I was kind of inclining towards defining a new header would be that in case
of calls that originate in a SIP network and pass thru' ISUP, this
information could passed down to the gateway by the origination SIP
network/by the outbound proxy that serviced the call. The gateway could use
this information to build the IAM message. </VENKATESH>

<VENKATESH> Why only tel URL's? Don't we envision 800 numbers being hosted
by a SIP network/rather terminating with in a SIP network ??? </VENKATESH> 

<VENKATESH> Again, Why would u want to make this specific to the tel URL?
What about calls that originate from a SIP UA? </VENKATESH>

Venkatesh

---

From: [email-masked]
Date: Fri, 16 Mar 2001 11:10:57 -0700

Just a minor point of clarification; in the 2543bis, the user portion of a
SIP URI (i.e. sip:user@host) can in fact be a tel URL, and therefore can
have recourse to the supplemental parameters of a tel URL. So, the
hypothetical 'cpc' in the tel URL could be used thusly within a SIP URI:

<sip:+17208881000;cpc=[email-masked]>

Jon Peterson
Level(3) Communications

-----Original Message-----
From: Venkatesh Venkataramanan
[mailto:[email-masked]]
Sent: Friday, March 16, 2001 11:01 AM
To: Peterson, Jon; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [SIP] draft-jfp-sip-isup-header-00.txt - presentation
restric ted

Comments Interspersed...

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, March 15, 2001 11:23 PM
To: [email-masked]; [email-masked];
[email-masked]

Jon Peterson
Level(3) Communications

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

Hi:

Venkatesh

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 17 Mar 2001 00:22:36 -0500

> Sent: Friday, March 16, 2001 1:11 PM

To be more precise, the user portion of a sip URI can be a
telephone-subscriber. The BNF for telephone-subscriber is defined by the tel
URL, and is anything that can be after the tel: in the tel URL.

-Jonathan R.
---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: "Venkatesh Venkataramanan" <[email-masked]>
Date: Mon, 26 Mar 2001 12:13:27 -0800

Sorry for getting back late on this one ! Comments Inline......

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, March 15, 2001 11:23 PM
To: [email-masked]; [email-masked];
[email-masked]

Jon Peterson
Level(3) Communications

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

Hi:

<VENKATESH> I think alternative 1 is an overkill (wonder if it would be
worthwhile for
a proxy to be able to parse ISUP content, if all it cares about is billing
information).
I don't quite understand option 2. To the best of my knowledge, the
following are the IE's in an IAM that an application would need to decide
billing, a flag which indicates if a call is to be billed, and if Yes, what
is the number. Think it would make sense putting this in a "Charge-Info"
header, or, if we are reluctant to add a new header for the same, may be try
using Caller-Preferences? Don't know if the usage of caller preferences for
forwarding this piece of information would be ok? 
</VENKATESH>

---

From: Matt Holdrege <[email-masked]>
Date: Mon, 26 Mar 2001 12:49:26 -0800

Comment below...

>forwarding this piece of information would be ok?

I don't see the problem with Jon's first alternative. We have a spec for 
transferring ISUP with SIP, so who cares if a gateway component transfers 
the ISUP to a billing system. All we care about at this stage is that the 
protocol support it. Really, either alternative is pretty much 
implementation specific.