Documents for CN1 – SA2 joint meeting on SIP	Cyan cells indicate an allocated but not available tdoc	Yellow cells indicate an available but not yet treated tdoc	
Agenda item	Agenda item title (tdoc presedence in red)	Tdoc 3GPP N1-00	Title	Spec.	Source	Result	
1	Opening
tuesday 28.11.2000					The meeting was opened at 9:15	
	1.	1051	Make calls for IPRs		MCC	IPR question was done by reference to the tdoc N1-001054	
	2.	1442	Agenda		Chairman	Noted.	
							
2	Reports
tuesday 28.11.2000						
	3.		SA2 meeting report		MCC	
Only SIP related decisions to be presented for information for the meeting.	
	3.	1443	CN1 #14 meeting report		MCC	
Only SIP related decisions to be presented for information for the meeting.	
							
3	Input Liaison statements
tuesday 28.11.2000		Only SIP & IM subsystem related LSs are provided for this meeting				
	6. 
(see CN1 specs & WI descriptions first!)	1360	LS for "IM Subsystem Address Storage on USIM "		SA2	Noted.
Discussion on the proposal and reply is needed
Forwarded to the SA2 – CN1 SIP joint meeting 28.11.2000
Proposal to put SIP URL to USIM.
N1-001345, N1-001360, N1-001441 are linked.	
		1289	Response to LS on RTCP responsibility		TSG CN WG3	Noted.
CN3 is proposing CN1 a joint meeting (on RTCP) issues during CN1 #15 in January 2001.
Action point for Hannu to agree about this with the CN3 chairman.
Forwarded to the next meeting from CN1 #14	
		1317			Sunil	Noted.
CN1 is saying to SA1 and CN4 that 23.cde is needed.
Agreed in CN1 #14.
Reply to 1156	
		1450	LS on the Work Item “Cx Interface specification”		CN4	Noted.
New WI proposal from CN4 to define the data flows at Cx interface.	
							
4 	SIP Work Plan for TSGN WG1
tuesday 28.11.2000		

Please note the new proposed CN1 – SA2 SIP joint meeting date!		

---------------->	2000:
CN1 SIP ad-hoc 17.-19.10.2000 (Sophia Antipolis)
TSGN1 #14 20.11 – 24.11.2000 (Cardiff, UK/Lucent) 
CN1-SA2 SIP joint meeting on SIP 28.11.2000 with possibility to extend to 29.11.2000 in a smaller CN1 drafting meeting (New Jersey / USA)
TSGN#10  6.-8.12.2000

2001:
CN1 #15 15.-19.1.2001 (Host needed) 
    (N4 is at the same time)
CN1 – SA2 SIP joint meeting 13.-15.2.2001 (host needed)
CN1 #16 27.2.-1.3.2001 (Host needed)
    (N4 is at the same time)
CN #11 14.-16.3.2001 (US)
CN1 – SA2 SIP ad hoc 3.-4.4.2001 (Nokia candidate host)
CN1 #17 14.-18.5.2001 (Host needed)
    (N4 is at the same time)
CN #12 13.-15.6.2001 (Europe)
CN1 #18 27.-31.8.2001 (Host needed)
CN #13 19.-21.9.2001 (China)
CN1 #19 22.-26.10.2001 (Host needed)
CN1 #20 20.-23.11.2001 (Host needed)
CN #14 12.-14.12.2001 (Japan)	
	4.	1349	Proposed revisions to SIP call control protocol for the IM subsystem		 CN1	Revised to 1454 due to changed title of 23.cde
•	Agreed in CN1 #14 and will be forwarded to TSGN #10 for approval.
•	Joint SIP meeting was given a mandate to treat CN1 related LSs and SIP call control protocol for the IM subsystem project planning 	
	4.	1351	PS based Emergency Call in R5		CN1	Noted.
•	23.228 should cover emergency calls also -> does USIMless emergency call impact the architecture in 23.228?
•	There are other cases like not registered, expired prepaid USIM and no roaming agreement to be considered also.
•	The (Home vs. Visited) control of emergency calls may not be possible to decide the same way as the control of normal calls.
•	The QoS for emergency calls must be as good as that of normal VoIP calls.
•	SA1 – SA2 joint meeting 29.11.2001 to define which meeting will need to include this requirement in their specification. No CN1 impact is foreseen. Stage 1 / SA1?
•	The requirements for interaction of emergency call and other services such as CW needs to be asked from SA1.	
		1454	Proposed revisions to SIP call control protocol for the IM subsystem		 CN1	Agreed.
This document needs to be added to CN1 input to TSGN #10 to replace N1-001349.
•	Agreed in CN1 #14 and will be forwarded to TSGN #10 for approval.
•	Joint SIP meeting was given a mandate to treat CN1 related LSs and SIP call control protocol for the IM subsystem project planning 
Revision of N1-001349	
						Comment on the work plan document: ID 1998 and 1278 are subtasks under CN1 WT "SIP Call Control protocol for the IM Subsystem" which should be added as an umbrella to cover both subtasks.
The addition of the third new CN1 specification IM call model is subject to TSGN decision on the ownership etc.	
							
5	Technical issues
tuesday 28.11.2000					•	Is it P-CSCF or S-CSCF which stores the confidential information like R-R, Via, CLI,...?
•	indication of network initiated de-registration to UE?
•	Interaction of SIP signalling and QoS negotiation and RAB establishment for user data?
•	Public and private identities are a ? SA2 must define what MAGNUS is. The usage and storing, i.e. logical significance is more important to start with as the coding can be derived from that.
•	How to recover from a (P-)CSCF failure?
•	Can 23.228 be stable enough for final approval in TSGS #10?
•	Network initiated de-registration ?

CN1 SIP ad hoc #1 decided that 3 new CN1 specifiations will be needed:
•	Detailed IP multimedia signalling flows, proposed specification number 24.228
•	Stage 3 for the multimedia call control based on SIP with proposed specification number 24.229.
•	Call model specification the scope of which has not been defined yet but understood to be the IM variant of 23.018.
•	The latest versions of the CN1 specfications 24.228, 24.229 and 23.cde are provided as an output from CN1 #14	
5.1	Storing confidential information in UE / P-CSCF / S-CSCF					CN1 SIP ad hoc #1 made a working assumption that sending encrypted information on call path, caller identity, etc to UE is not very practical and instead we should study whether P-CSCF or S-CSCF would be more appropriate entity to store the information.	
		1429	Routing of SIP requests in call flows	24.228	Nokia / Gabor Bajko	The principle was agreed.
•	Intended for 23.228 but has not been seen by SA2 yet.
•	Proposal that P-CSCF should store some of the call route information.
•	The intention is that P-CSCF serving UE B should store the Record-Route between UE A and itself from the INVITE. Any subsequent modification or termination of the session from UE B should take the same route.
•	P-CSCF serving UE A should store the Record-Route headers between UE B and itself from the first response to the initial INVITE. Any subsequent call or session modification or termination from UE A should take the same route.
•	Both general principle and detailed call flows are proposed.
•	How to handle the P-CSCF failure? (related with other cases too, not just this contribution)
•	Route and Via headers should not be removed but the contents is modified by a P-CSCF
•	The procedure should cover not just call clearing and modification but all SIP procedures.
•	It was agreed that a third item need to be added to section 4 Proposal: "the path information needs to be stored in the S-CSCF also"
•	The principle presented in the document was agreed with the addition of the third item above. 
•	The detailed call flows in this contribution were not reviewed and they are noted.
•	The originator is asked to provide contribution against 23.228 to the SA2 meeting later this week. 
•	Related contribution on 24.228 should be brought to CN1 also.	
		1446	Routing of SIP requests in call flows	23.228	Nokia	Withdrawn	

5.2	SIP REGISTER related call flows						
		1445	Indication of network initiated de-registration to UE	23.228	Nokia	The meeting agreed the principle and the originator is invited to raise a CR against 23.228.
•	Proposal to add DL indication to UE to network initiated de-registration procedure
•	All registrations from a given terminal or just a specific one? -> the intention is to be able to de-register a specific registration (related with one private ID)
•	Different categories of de-registration for temporary or permanent failures should be considered.	
		1449	Registration Information Elements	24.228/
24.229	Ericsson	Noted. There was no objection against the proposed principle but the proposal can not be copied to 24.228 or 24.229 as such. So detailed contributions are invited.
•	The usage, storing and coding of the MAGNUS needs to be defined by SA2	
							
5.3	SIP INVITE related call flows						
		1207	Detailed INVITE call flows based on 23.228 Annex B.2	24.228	Lucent Technologies / Stinson Mathai	Noted.	
		1430	Signaling Flows for Session Initiation – MO-MT-SS	24.228	AT&T/Bill Marshall	This contribution conflicts in some places with the existing 24.228 Annex A/section 8. CN1 SIP ad hoc to start the merging of the two 29.11.2001.
•	Is it better to define the end-to-end call flows as in 23.228 or to structure 24.228 by different interfaces?
•	The mandatory requirements should be in normative part of the specification while the end-to-end SIP message signalling examples may be left in an informative annex.	
		1431	Signaling Procedures for UE	24.228	AT&T/Bill Marshall	Rejected.	
		1432	End-end Call Flow Example	24.228	AT&T/Bill Marshall	Rejected.
The proposal was seen as useful approach but premature at this stage due to the level of details it contains is more than in the Annex A of 24.228. Additionally it builds on some assumed decisions which are not yet reflected in the reference specifications.
•	The proposal to have this kind of tutorial was supported but the next question is where to write it?
•	There was reservations because the informative and normative part of the spec may end up being inconsistend leading to incompatible implementations.	
		1440	PCSCF functionality in IM		BT/S2- Nigel Lobley	Noted. SA2 to decide in their meeting.
•	Comments were invited before the next SA2 meeting.
•	The document was distributed but not discussed in the latest SA2 meeting.
•	Proposal to start defining P-CSCF functionality. The P-CSCF may modify the request URI it received but it is proposed that in roaming case any modifications should be made known to the home network S-CSCF.
•	Only the principle is covered, no procedure is proposed in this document.	
		1444	Signaling Procedures for I-CSCF	24.228	AT&T/Bill Marshall	Rejected.	
							
5.4	Other call flows						
		1436	Detailed session release call flows based on 23.228	24.228	Lucent Technologies / Keith Drage	Rejected.
•	It was agreed that the network initiated call clearing procedure should be specified.	
		1437	Identification of the user required by different services	24.228	Lucent Technologies / Keith Drage	Noted.	
		1438	Implications of SIP session timer on 3GPP IM CN subsystem		Lucent Technologies / Stinson Mathai	Noted.	
		1439	IM and GGSN interconnectivity		BT/S2- Nigel Lobley	Noted.
•	The document was discussed and rejected in SA2
•	Proposal that MGW and P-CSCF may interface with different GGSN. Intended for 23.228.
•	What does it mean to SIP and GPRS if C-plane and U-plane relate to different GGSN? 
•	Separate IP addresses for the user plane and control plane for the same call	
		1447	Ungraceful session termination	23.228	Nokia	Noted.
To be presented by the originator in SA2 meeting.	

							

5.5	Other technical issues					The split between 24.228, 24.229 and 23.cde to be defined by CN1 ad hoc 29.11.2001.	
	6.	1345	IM identity of users		BT/Sunil	Noted.
•	Public user identity is known by the users while Private user identities would be needed in home network. Only the home network can relate the private ID to a particular subscriber profile. Visited NW can use the ID for registration, charging and security procedures.
•	Both are needed, but the definition and use of private ID still needs more discussion. 
•	MAGNUS -> Multimedia Application Generic Network User's Subscriber identity. It is not supposed to be used for routing but just to identify the subscriber. 
•	Private ID should be used in accordance with AAA (Authentication, Authorisation, Accounting)
•	Proposal from AT&T that private ID should be independent from the access technology
•	MAGNUS could be an IP V6 identity or some other format. Depending on the chosen naming scheme some common administration to allocate the identities may or may not be needed.
•	The private ID can not be present in all charging records as CS domain will not be impacted but only the ones in IM subsystem would be relevant (proxies, CSCFs). 
•	Does GPRS need to know about private ID at all? -> billing system would be complicated if this association is not available. 
•	As billing seems to be one of the key drivers for the proposal SA5 needs to be involved in the discussion.
•	Discussion on private IDs between {SA1 - SA2 – SA3 - SA5 – maybe CN1} is needed.
•	The UE needs private ID only for registration and possible authentication and identity request procedure, if needed.
•	A subscriber porting from one PLMN to another will be assigned a new private ID.
•	The scheme was seen as applicable for GSM also.
N1-001345, N1-001360, N1-001441 are linked.	
	5.	1378	Proposed scope and contents for IP multimedia subsystem signalling flows	24.228	Lucent Technologies / Keith Drage	Noted.
Rapporteurship is shared between Ericsson, Motorola and Nortel.	
	5.	1379	Proposed scope and contents for IP multimedia subsystem stage 3	24.229	Lucent Technologies / Keith Drage	Noted.
Rapporteur Keith Drage, Lucent.
Proposal that the 3GPP initiated changes to IETF SIP should be clearly indicated in this document, maybe separated to a subclause or section of their own. This can be done in Annex A of 24.229.	
	5.	1386	Proposed scope and contents for TS on IP Multimedia (IM) Session Handling	NEW proposedTS	BT/Sunil	Revised to N1-001448
Rapporteur Sunil Chotai, BT
Close co-operation between CN1 and CN2 is needed when developing this specification.
Proposal to clarify the title to align it with the scope of the document ("IM call model")
1, 2 or 3 alternative architectures? 	
		1433	Header Field Summary for TS 24.229	TS 24.229	Motorola /Steve Magee	Noted.	
	5.	1434	Summary of current IETF documents on SIP		Lucent Technologies / Keith Drage	Noted.
Provided for information	
	5.	1435	Summary of current IETF documents on MMUSIC		Lucent Technologies / Keith Drage	Noted.
Provided for information	
	6.	1441	IM identity of users		BT/S2 Drafting group- Nigel Lobley	Withdrawn
•	Was this tdoc agreed in SA2?
•	Public and private user identities for the IM subsystem intended for 23.228. 
N1-001345, N1-001360, N1-001441 are linked.	
		1448	Proposed scope and contents for TS on IP Multimedia (IM) Session Handling	NEW proposedTS	BT/Sunil	Noted.
Rapporteur Sunil Chotai, BT
Close co-operation between CN1 and CN2 is needed when developing this specification.
Proposal to clarify the title to align it with the scope of the document ("IM call model")
1, 2 or 3 alternative architectures?
Revision of N1-001386 	
		1451	Responsibility split for TS 24.228	24.228	Motorola/ John O’Hare	Noted.	
		1452	TS 23.228 V1.4.0	23.228	Lucent/Thomas Towle	Noted.
Presented for information	

							
							
6	A.O.B.
Evening session on tuesday 28.11.2000 and short wrapup wednesday morning (29.11.2000) is possible if needed.						
		1453	LS for "IM Subsystem Address Storage on USIM "			Withdrawn
Proposed LS out
Reply to N1-001360