Subject: [Sipping] I-D ACTION:draft-ietf-sipping-isup-04.txt

From: [email-masked]
Date: Wed, 24 Jul 2002 08:09:39 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Proposal Investigation Working Group of the IETF.

	Title		: ISUP to SIP Mapping
	Author(s)	: G. Camarillo et al.
	Filename	: draft-ietf-sipping-isup-04.txt
	Pages		: 65
	Date		: 23-Jul-02
	
This document describes a way to perform the mapping between two
signaling protocols: the Session Initiation Protocol (SIP) and the
ISDN User Part (ISUP) of SS7. This mechanism might be implemented
when using SIP in an environment where part of the call involves
interworking with the Public Switched Telephone Network (PSTN).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sipping-isup-04.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sipping-isup-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sipping-isup-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Mark Watson" <[email-masked]>
Date: Mon, 29 Jul 2002 13:05:23 +0100

I am confused by the change to the text on FCI setting in this version.

Version 03 of the draft said:

"If usable encapsulated ISUP is not present in an INVITE received by the
gateway, it may set the 'interworking encountered' bit as appropriate."

Version 04 of the draft says:

"If usable encapsulated ISUP is not present in an INVITE received by the
gateway, it may set the 'interworking encountered' bit as indicated by the
encapsulated ISUP."

This seems to describe a case where 'usable encapsulated ISUP' is NOT
present in the message, but 'encapsulated ISUP' IS (otherwise how could it
indicate how to set the bit?). Presumably this is 'unusable' ISUP. The term
'unusable' is not explicitly defined, but it is nevertheless peculiar that
we should 'use' something which is 'unusable'.

The setting of this indicator in the case where no ISUP is present at all is
then undefined.

As noted in previous mails to the list, setting this indicator to
'interworking encountered' causes problems for some ISDN services which can
easily be interworked between SIP and ISDN (e.g. G.722 codec). The general
issue is described in the previous paragraph, but we could perhaps be
explicit about how one might decide how to set this indicator. I suggest
replacing the sentence quoted above with:

"If usable encapsulated ISUP is not present in a INVITE received by the
gateway, then the setting of the Interworking indicator should be based on
the service set which the gateway is able to interwork. If the gateway is
able to interwork ISDN services which are not supported for the PSTN, and
can correctly handle requests for ISDN services from the ISUP side, it may
set the Interworking indicator to 'no interworking encountered', the ISDN
User Part indicator to 'ISUP used all the way' and the ISDN Access indicator
to 'Originating Access ISDN'. Otherwise, the Interworking indicator should
be set to 'Interworking Encountered', the ISDN User Part indicator to 'ISUP
not used all the way' and the Originating Access indicator to 'Originating
Access non-ISDN'."

Further, if there is 'usable' encapsulated ISUP, I think the indicators
should all be set as received in the ISUP. This requires minor modification
of the preceeding paragraph.

Regards...Mark

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: 24 July 2002 13:10
> Cc: [email-masked]
> Subject: [Sipping] I-D ACTION:draft-ietf-sipping-isup-04.txt
> 
>

---

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 29 Jul 2002 14:36:51 -0400

Yes, I had noted that defect before. The text on both FCI and BCI is
improved in the -05 release to more or less this effect. The -05 release is
also 2119-ified, and it thus can RECOMMEND that in the absence of usable
ISUP the 'interworking encountered' bit (and the other two ISDN access
related bits in the ?CI) should be set, but it can also note that gateway
vendors MAY enable service providers to configure gateways to set these bits
otherwis in accordance with the local policy. The language about how the
bits will be set when usable ISUP is actually present has also been
corrected.
 
On this matter of what really constitutes interworking, I hesitate to defer
this matter to configurable policy but it may merit further study. It does
not sound like we really have a good picture of the effects of setting these
bits. While I'm sure that there are some features that are unnecessarily
disabled by setting these indicators to 'interworking encountered'
conservatively, I suspect there are other features that won't function
properly if the bits are liberally set to 'no interworking'. It's tough to
choose one or the other. 
 
Jon Peterson
NeuStar, Inc.

-----Original Message-----
From: Mark Watson [mailto:[email-masked]]
Sent: Monday, July 29, 2002 5:05 AM
To: [email-masked]
Subject: RE: [Sipping] I-D ACTION:draft-ietf-sipping-isup-04.txt

Regards...Mark 

> From: [email-masked] [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> http://www.ietf.org/internet-drafts/draft-ietf-sipping-isup-04.txt
<http://www.ietf.org/internet-drafts/draft-ietf-sipping-isup-04.txt>  
> http://www.ietf.org/shadow.html <http://www.ietf.org/shadow.html>  
<ftp://ftp.ietf.org/ietf/1shadow-sites.txt>

---

From: "Mark Watson" <[email-masked]>
Date: Tue, 30 Jul 2002 10:45:57 +0100

Jon,
 
Yes, I agree that the effect of setting the indicators - what services are
enable/disabled by the setting - warrants further study. Hopefully we'll be
looking at this in SG11.
 
Given this, I don't think we should 'recommend' one setting or the other at
this stage. We already know of one service which is broken by claiming
'interworking' - G.722 codec - and there is no reason why this service
should be difficult to interwork between SIP and ISDN. Equally we could look
at ISDN Videotelephony interworking with SIP.
 
Setting the bits to 'interworking' in principle reduces you to the PSTN
service set. I think we should have the ambition of interworking with the
ISDN service set, where that makes sense. I think in practice, some aspects
of ISDN services will still work even with the indicators set, but it is
often difficult to find specifications to back this up.
 
Regards...Mark

-----Original Message-----
From: Peterson, Jon [mailto:[email-masked]]
Sent: 29 July 2002 19:37
To: Watson, Mark [MOP:EP10:EXCH]; [email-masked]
Subject: RE: [Sipping] I-D ACTION:draft-ietf-sipping-isup-04.txt

 
Jon Peterson
NeuStar, Inc.

-----Original Message-----
From: Mark Watson [mailto:[email-masked]]
Sent: Monday, July 29, 2002 5:05 AM
To: [email-masked]
Subject: RE: [Sipping] I-D ACTION:draft-ietf-sipping-isup-04.txt

Regards...Mark