Subject: [SIP] Comments/questions on draft-jfp-sip-isup-header-00

From: "Sam Hoffpauir" <[email-masked]>
Date: Sun, 11 Mar 2001 22:09:01 -0500

If a SIP endpoint makes a call, the number will be the dialed number. If a
gateway receives a dialed number, how does it know the context in which the
number was dialed? Is it an assumption in a "SIP-T" network that a proxy
would have translated the dialed number into an E.164 or national number?

- If present, the generic name field should be translated into the display
name portion of the From/Remote-Party-ID header. This allows a SIP device
receiving an INVITE from a gateway to get the caller's name, if available.

- In the INVITE to IAM mapping, if the INVITE does not contain an IAM then
the forward call indicator should indicate that interworking is encountered.

- In the INVITE to IAM mapping, if the INVITE does not contain an IAM then
the CPC should be set to ordinary sub.

- In the IAM to INVITE mapping, the functionality in
draft-ietf-sip-privacy-01
should be used to include Remote-Party-ID header to pass calling line
identity
presentation indicators. This allows the callilng line identity to be
delivered
to trusted network elements (proxys), but not the endpoint.

Sam

_______________________________________________
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: Mon, 12 Mar 2001 01:36:53 -0700

Thanks for your reading of the draft. A few responses to your comments... 

For most networks, I think it would be very difficult for something like a
gateway to try to figure out the numbering plan and/or context in which a
given phone number in a Request-URI was dialed unless the number is in an
international format. Either the endpoint itself (not unreasonable in some
cases) or some posterior entity like a local outbound proxy would have to
provide that critical context for the dialed digits, yes. Methods will vary
depending on how one's network is architected, and I don't think there's any
particular urgency to standardize any one method for this - however, I think
that if a call is going to leave your administrative domain, some entity
should have put the DN into an international format first. I think this is a
pretty well-accepted notion today.

- On the Generic Name Parameter: True, that should become the name portion
of the From field, if it is available. That will be added.

- On Interworking: Actually, I think this is a slightly more complicated
question than whether or not ISUP is present in the INVITE. One could argue
that 'interworking' refers to pre-SS7 networks which cannot, for example,
express or handle networking information such as cause codes; of course, SIP
has its status codes which can be mapped to cause codes (and have been in an
existing draft) whether or not ISUP is present. Certainly, I agree that if
ISUP is present, it definitely shouldn't be considered interworking. I think
you're probably right that we should consider SIP sans ISUP as interworked,
but I'd be interested in hearing other opinions on this matter: should SIP
networks be considered 'interworking' with SS7 when ISUP encapsulation is
not in use?

- On the default CPC: Well, conceivably that could vary depending on
how/where the gateway is used, but 'ordinary calling subscriber' would
probably be the most common default case.

- On Remote-Party-ID: I don't think the assumptions of the sip-privacy draft
are necessarily compatible with all network architectures, though I feel
their solution is a good one for the sorts of networks they have in mind. In
the SIP-T model, I'm not sure that gateways should necessarily behave as if
there are trusted intermediaries supporting their signaling and overseeing
potential recipients of calls. It's my understanding that using the
sip-privacy mechanism, if an originating network is sending signals to a
potentially untrusted entity, the originating network should process the
Remote-Party-ID and Anonymity headers and modify signaling appropriately,
which will result in something like what we suggest as gateway procedures
for handling presentation or what have you. Of course, in gateway-to-gateway
communication, if ISUP is present in the INVITE then the original calling
party information can be referenced for generating tail-end signaling.

SIP-T primarily addresses the PSTN/SIP interface for switch-to-switch
signaling in the PSTN; it just so happens that SIP allows signaling on the
subscriber stratum as well, and hence there need to be rules that describe
the interface between these two realms, which were truly segregated in the
PSTN. The DCS extensions seem to focus on managing subscriber signaling;
clearly, some SIP endpoints will implement these extensions in networks
where administrators require a certain amount of control over their
endpoints, and some will not (just as some ISUP gateways do not encapsulate
ISUP). SIP-T proposes no extensions to SIP in order to allow PSTN/SIP
exchanges, and mandating that gateways must implement DCS SIP extensions
might not be appropriate for networks that lack the subscriber focus (see
section 9 of sip-privacy-01). If there need to be special ISUP-DCS/SIP
procedures that support the DCS extensions at PSTN gateways, I think they
should most likely be specified in some other document.

Jon Peterson
Level(3) Communications

-----Original Message-----
From: Sam Hoffpauir [mailto:[email-masked]]
Sent: Sunday, March 11, 2001 8:09 PM
To: SIP
Subject: [SIP] Comments/questions on draft-jfp-sip-isup-header-00

Sam

---

From: "Mark Watson" <[email-masked]>
Date: Mon, 12 Mar 2001 11:30:15 -0000

Jon, Sam,

> express or handle networking information such as cause codes; 

This is exactly what 'interworking' means in this context. You have to think
back into the minds of the people who developed SS7. At that time there were
no other systems to interwork to with equivalent or better capabilities that
SS7, so 'interworking' meant interworking with non-SS7 systems.

If you set the interworking bit in the FCI, you reduce the capabilities of
the call, eliminating some capabilities which can quite acceptable be
interworked with the SIP network.

Therefore the Interworking Indicator should *not* be set for SIP->ISUP.

Similar arguments apply to the 'ISDN User Part indicator', which IMO should
be set to 'ISDN User Part used all the way'. All ISUP capabilities will then
be available, and can be interworked to SIP (or not) on a case by case
basis.

Regards,

Mark Watson
Nortel Networks