Subject: [Sipping] FW: Communication re: SIP - BICC/ISUP Interworking

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 15 Jul 2002 20:15:03 -0400

COMMUNICATION STATEMENT
TO:	IETF SIP WG and IETF SIPPING WG
APPROVAL:	APPROVED BY ITU-T Study Group 11 Rapporteurs meeting of
BICC/SIP interworking and AAL2/IP interworking (Newbury, June 2002)

FOR:	INFORMATION AND ACTION

CONTACT:	   Steve Norreys   
Tel: +44 20 7843 5189                       
BT                      
Angel Centre                      
403 St Johns Street                      
London  UK                             
email: [email-masked]

This message was agreed to at the ITU-T Study Group 11 Rapporteurs meeting
on BICC/SIP interworking and AAL2/IP interworking (Newbury, June 2002).

As you know, ITU-T Study Group 11 has initiated a work program to define
detailed signalling procedures for the interworking of SIP with BICC (Bearer
Independent Call Control) and with ISUP (ISDN User Part of Signalling System
7).  The work done by the IETF on this topic has served as input to our own
work.  We are basing our work on BICC CS2 (2001), ISUP (2000), and the
recently approved version of SIP (2543bis-09).  The output documents consist
of a SIP profile specification (draft Recommendation Q.sipprof) and the
interworking specification itself (draft Recommendation Q.1912.sip).  The
latest versions of these drafts are available on the informal SIPPING web
page (or will be shortly).

The SG 11 BICC group invites the IETF SIP and SIPPING WGs to send comments
on the interworking to the above contact in time for the next BICC
Rapporteurs meeting in Ottawa (Canada), 9-13 September 2002. 

A strong consensus exists among the participants of the BICC Rapporteurs
meeting that the first interworking recommendations on SIP- ISUP/BICC
interworking will be finished in November 2002 for the approval at the SG11
meeting.  We have scheduled one more interim meeting to work toward this
objective, in Ottawa, Canada, in September 2002.  Interested IETF
participants are invited to contact Steve Norreys at the address given above
for further information.

During the Rapporteurs' meeting in Newbury the following inconsistencies
emerged between draft Q.1912.SIP and IETF documents.

1.	The use of ISUP Timer T10 for SIP procedures in
draft-ietf-sipping-overlap-00.txt is questionable, because this timer is
part of the state machine on the ISUP side of the interworking point and
using it might have unintended consequences.  It is recommended that a timer
be defined specific to the interworking process instead. 

2.	The mapping of FCI and BCI within the IETF draft
draft-ietf-sipping-isup-02.txt is different from what the SG11 experts have
seen proper to use within Q.1912.SIP.  The setting of the FCI in the
interworking case (INVITE - IAM) is "no end-to-end method available,
interworking encountered, ISDN not used all the way, originating access
non-ISDN". The Setting of the BCI in the interworking Case (180-ACM) is "no
end-to-end method available, interworking encountered, ISDN not used all the
way, originating access non-ISDN". In the SIP-T case the FCI and BCI will be
taken from the encapsulated ISUP.  It is not yet clear how to set the FCI
and BCI if there is some updating of the received ISUP message using the
contents of the SIP header mapping. 

3.	Cut through in the backward direction for tones and announcements
from the SIP network can be misused as there is a bearer path potentially
available from the user equipment without charging.  (The called UA could
send back a 180 Ringing, then send back its own media without bothering to
send a 200 OK INVITE.)  We are currently taking a conservative approach and
not cutting through until answer.  This is an issue of whether the SIP
network can be trusted. 

4.	Regarding the SIP Status Code to ISDN Cause Code Mapping, some
changes to your proposed mappings will be integrated in the ITU Q.1912.SIP.
The final mapping will be decided at the next meeting in Ottawa.  We have
simplified the mappings a bit because the ISUP/BICC network won't be able to
make good use of the information.  The general rule is that
non-service-related responses will be mapped to "interworking, non-specific"
unless the alternative is obvious.

Due to the lack of the meeting time, ITU wasn't able to make a complete
review of the IETF interworking document. It was agreed that comments
regarding this interworking document would be made directly by the
individual experts and forward it to the IETF lists.

The SG 11 BICC group looks forward to further communications as this study
progresses. 

Tom Taylor
[email-masked]
Ph. +1 613 736 0961 (ESN 396 1490)

_______________________________________________
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: Rohan Mahy <[email-masked]>
Date: Tue, 16 Jul 2002 23:40:29 +0900

On Tuesday, July 16, 2002, at 09:15 AM, Rosen, Brian wrote:

> [snip]
the setting in draft-ietf-sipping-isup?  or the ITU docs

> not cutting through until answer.  This is an issue of whether the SIP
The PSTN allows this functionality today.  Whether the PSTN GW allows 
bidirectional early media, and how it records this request for 
accounting purposes seem like a policy decision on the gateway.

thanks,
-rohan

> [snip]