Subject: [Sipping] draft-ietf-sipping-isup-05 - P-ASS-ID, Q.767

From: "Jesske, R" <[email-masked]>
Date: Fri, 16 Aug 2002 13:23:53 +0200

Dear all,
regarding the last draft 05 I have some comments.

1. In the Scope of the document it is stated that the document is based on Q.767 and in some mentioned paragraphs there are some special aspects regarding the mapping of  ANSI or TTC ISUP are mentioned.
Within the section  "4. Scenarios" the segmentation mechanism and message is mentioned. From my knowledge the segmentation mechanism was introduced with ISUP92. The same belong to the Generic Number or Transit Network Selection mentioned within Section 7.2.1.1 INVITE to IAM procedures and some other Parameters mentioned within this document.
For the unknown reader (implementer ?) it is not easy to distinguish between Q.767 parameters , ANSI, TTC or ISUP (92/99) parameters.
But in knowledge of your goal to finish the mapping I let it to you how to handle this issue. (perhaps you can mention it in the Scope)

2. With the definition of the P-Asserted-ID and the Privacy Header there are two new SIP elements that are very useful for the SIP-ISUP mapping. For (some) network operators/ service providers it is important to have an trusted calling party number (regulatory aspects, service aspects, billing aspects). Therefore it could be useful to extend the mapping of the calling party number to the P-Asserted-ID. 
 
Best Regards 

Roland

Deutsche Telekom AG
T Com Zentrale
Section T38; Signalling, Gateways and Switching Systems 
Roland Jesske, T38a12
Am Kavalleriesand 3, 64295 Darmstadt, Germany
Phone:  +49 6151 83-5940 
Fax:    +49 6151 83-4577 
mailto: [email-masked] <mailto:[email-masked]>

_______________________________________________
Sipping mailing list  https://www1.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: "Peterson, Jon" <[email-masked]>
Date: Fri, 16 Aug 2002 16:55:57 -0400

The first of these comments I believe we have gotten before (from you?),
essentially that over time our draft has become less and less Q.767-based,
as we've introduced more and more material from later ITU-T standards and
national variants, and that therefore the scope seems a bit like false
advertising. That may be true, but I'm not sure what perils this really
poses for implementers as such. The instances where parameters like the
Generic Digits are used are already surrounded by a lot of apologetic
material (phrases like "this is what you do if your variants supports this
parameter"). I think implementers of gateways will not have much trouble
identifying when their variant does or does not support these parameters -
after all, we're not writing this doc to teach switch vendors about their
ISUP variants, just to provide some mappings.

On the second point, I agree completely that this work needs to be done, but
I don't think this should appear in the main SIPPING-ISUP draft. Note that
sipping-isup-05 already motivates a need for an external privacy/identity
system (in section 5.7); I don't think we need anything in the main draft
beyond the basic treatment of anonymity in 12.1. Incidentally, I feel that a
good SIP-ISUP mapping for privacy/identity should deal with both
cryptographic and trust-based identity.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Jesske, R [mailto:[email-masked]]
> Sent: Friday, August 16, 2002 4:24 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: draft-ietf-sipping-isup-05 - P-ASS-ID, Q.767
> 
> 
> Dear all,
> 1. In the Scope of the document it is stated that the 
> document is based on Q.767 and in some mentioned paragraphs 
> there are some special aspects regarding the mapping of  ANSI 
> or TTC ISUP are mentioned.
> Within the section  "4. Scenarios" the segmentation mechanism 
> and message is mentioned. From my knowledge the segmentation 
> mechanism was introduced with ISUP92. The same belong to the 
> Generic Number or Transit Network Selection mentioned within 
> Section 7.2.1.1 INVITE to IAM procedures and some other 
> Parameters mentioned within this document.
> For the unknown reader (implementer ?) it is not easy to 
> distinguish between Q.767 parameters , ANSI, TTC or ISUP 
> (92/99) parameters.
> But in knowledge of your goal to finish the mapping I let it 
> to you how to handle this issue. (perhaps you can mention it 
> in the Scope)
> 
> 2. With the definition of the P-Asserted-ID and the Privacy 
> Header there are two new SIP elements that are very useful 
> for the SIP-ISUP mapping. For (some) network operators/ 
> service providers it is important to have an trusted calling 
> party number (regulatory aspects, service aspects, billing 
> aspects). Therefore it could be useful to extend the mapping 
> of the calling party number to the P-Asserted-ID. 
>  
> Best Regards 
> 
> Roland
> 
> 
> Deutsche Telekom AG
> T Com Zentrale