3GPP CN1-SA2 SIP joint meeting 7.-8. February 2001, New Jersey, USA

The meeting was hosted by AT&T in Hotel Hilton, East Brunswick, NJ, USA
3GPP CN1 (Core Network WG1) and SA2 (System Architecture WG2) were invited
The meeting was chaired by Hannu Hietalahti(Nokia), chairman of CN1
Executive summary of the decisions in the meeting
Documents for information:

N1-010235, IP multimedia (IM) Subsystem – stage 2
The latest version of TS 23.228, V.1.7.0 provided for information.

N1-010237, Summary of current IETF documents on SIP
Provided for information

N1-010238, Summary of current IETF documents on MMUSIC
Provided for information

Input liaison statements from other groups:

N1-010252, Removal of Visited Control S-CSCF option from the Rel 5 architecture
SA2 inform the other WGs that they have removed the visited control option from Rel-5 version of 23.228

Documents for decision:

N1-010233, Feedback from IETF interim SIP working group meeting
Summary of IETF discussions on 3GPP originated SIP contributions. So far there has not been too much contribution from 3GPP to IETF SIP work. The reason is that despite the SIP call flows have been discussed in the 3GPP meetings the main decisions within 3GPP have been related with the service requirements and the architecture. 
CN1 has also reviewed the SIP functionality and found out that significant amount of the features are already provided by the protocol and therefore very few candidates 3GPP originated enhancements have been identified.
Prioritisation of the IETF SIP work from 3GPP viewpoint is difficult as all the necessary procedures will be needed for a complete system and are therefore essential for completeness of 3GPP Rel-5
Decisions:
Chairman to distribute the summary of CN1 SIP related discussions and decisions to IETF SIP mailing list
The IETF SIP specifications which will be referred to by 3GPP will be listed on the 3GPP WI description and this information will be provided to IETF by the rapporteur
24.228 signalling flow summary to be provided to IETF SIP group by a drafting group of interested CN1/SA2 delegates.
3GPP related comments to the IETF SIP drafts which are referred to by 3GPP will be needed.
Call flows defining the 3GPP related enhancements need to be contributed to IETF by 3GPP members

N1-010229, Subscriber registration with public user identifier
Agreed that it must be possible to register public identities one by one. The use of the private ID in the TO field to associate it with multiple public identities was questioned as this also needs to be compliant with the existing SIP. Also security should be considered.
SA2 has agreed that there will be one private ID and one or more public identities.
The private identifier is assigned by the home network operator and takes the form of a Network Access Identifier (NAI) as defined in RFC2486

N1-010230, Individual registration of subscribers' public user identifiers
Many aspects of this contribution are already covered by the discussion and decisions on the previous tdoc. One outstanding issue is the possibility to indicate different contact point for different public addresses?
Both 3rd party registration and registering different contact points for different public addresses was seen as depending on SA2 decision on the principle before CN1 can proceed with the proposal. It will be up to SA2 to decide whether they wish to talk to SA1 about the service requirement first.
This issue can not be completely separated from authentication (e.g. 3rd party registration authority)
The originator was invited to provide a contribution in this area to the next SA2.

N1-010231 -> N1-010262, Network initiated de-registration (revised to N1-010262)
The UE needs to know if it needs to re-register and it also needs to know that it will not be possible to access IMS services because of subscription related reasons.
Proposal to use NOTIFY and 200 OK to inform the UE about de-registration 
Proposal to indicate in REGISTER that the UE expects this notification of de-registration.
Proposal to use Allow-Event in REGISTER for subscribing to this notification
Is the support of NOTIFY mandatory for the UE or not? How to handle de-registration when NOTIFY is not supported?
The originator was invited to provide a contribution based on these assumptions.

N1-010253 -> N1-010261 -> N1-010267, Alternative mechanisms to support "hiding" (revised to N1-010261, then to N1-010267)
Discussion on the requirements for network topology hiding. Decision that the architecture and security requirements are up to SA2 and SA3 to define but still decided to change the current text which is talking specifically about "encryption". This could be misleading as the requirement in some cases may be also fulfilled by means of some other address conversion such as using a token instead of address.

N1-010256 -> N1-010263, N1-010257 -> N1-010274, N1-010258, N1-010241 -> N1-010265, N1-010242-244, N1-010247, N1-010260
Several changes on signalling flows agreed to be added to 24.228. These will be covered in the summary of signalling flows in 24.228.

N1-010266, The usage of SIP headers in REGISTER message
Some delegations are concerned about the usage of private ID in From field but this was taken as working assumption for now in the absence of other alternatives. CN1 can not proceed with this issue until SA1-2-3 have clarified the service aspects and security requirements. To ensure that they are aware of this dependency a liaison statement (N1-010275) was sent to the other groups prompting for a rapid decision. Those SA2 delegates who intended to participate the next SA2-SA3 joint session will make sure that this matter is brought up in that meeting.

N1-010232, Routing of session initiation with called public user ID in E.164 format
The proposed principle was agreed and the originator is invited to propose changes to 24.228 based on this. It was commented that ENUM could be the primary addressing mechanism but the support of ENUM should not be made mandatory as some operators may wish to use other mechanism.

N1-010271, Outline internet draft to present 24.228 material to IETF
This version of the document was an early draft. More details will be added as indicated before distribution.

N1-010273, Work Item Description: SIP call control protocol for the IM CN subsystem
This is the 3GPP IM work item. The WI has been revised again. There is not so much deviations from the original plan but more details like the referenced IETF RFCs are being added to the WID as the work progresses. 

N1-010254, Removal of I-CSCR acting as "firewall"
The discussion on this contribution was more about the terminology rather than on the technical requirements on the I-CSCF. It was agreed that the adopted term "firewall" was less than perfect because it does not describe the functional behaviour very well. It was also agreed that an improvement can only be proposed if one that is applicable to both 23.228 and 24.228 can be found.

The meeting agreed in principle on THIG = Topology Hiding Internetwork Gateway. The originator was asked to raise appropriate contributions to SA2 and CN1.

A liaison statement on this topic in N1-010268 was also agreed.