Subject: [MMUSIC] FYI: New Liaison Statement, "LS on offer/answer procedures"

From: "Jean-Francois Mule" <[email-masked]>
Date: Mon, 21 Apr 2008 06:46:30 -0600

All,

   This was just sent to SIPPING, cc: to MMUSIC (fyi for mmusic I guess). The URL below points to a word document; I paste the text below.  Christer Holmberg is copied on this email and may provide more info to the appropriate list.

Regards,
Jean-Francois.

------
1. Overall Description:

3GPP CT1 has discussed the "Commit/Rollback of Offer/Answer on Unsuccessful re-INVITE Transaction" issue in draft-ietf-sipping-sip-offeranswer-06.txt.

A typical example of where subsequent offer/answer transactions may take place before a final answer to the re-INVITE request is received is when new media streams are added during an ongoing session, and those media streams require pre-condition procedures due to network/radio resource reasons. 

CT1 has identified the importance of a solution to the matter, in order to specify and implement interoperable procedures, and to avoid SDP state misalignments in cases where re-INVITE requests are rejected.

CT1 aims to be able to find a solution to the issue within the 3GPP Release 8 timeframe, which is scheduled to be frozen in December 2008.

----
2. Actions:
To IETF SIPPING WG
ACTION: 	CT1 asks SIPPING to take the importance of the issue into considerations in their work, and to provide guidance how to proceed on the matter.

3. Date of Next CT1 Meetings:
[snipped]

-----Original Message-----
From: Susanna Kooistra(3GPP) [mailto:[email-masked]] 
Sent: Monday, April 21, 2008 6:16 AM
To: [email-masked]; Jean-Francois Mule
Cc: [email-masked]
Subject: New Liaison Statement, "LS on offer/answer procedures" 

Title: LS on offer/answer procedures
Submission Date: 2008-04-21
URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=444 
Please reply by 2008-05-09

From: Susanna Kooistra(3GPP) <[email-masked]>
To: IETF MMUSIC WG,IETF SIPPING WG([email-masked],[email-masked])
Cc: [email-masked]
Reponse Contact: 
Technical Contact: 
Purpose: For action 
Body: 3GPP TSG CT WG1 Meeting #52	C1-081428
Jeju Island, KOREA, 7th � 11th April 2008

Title:	LS on offer/answer procedures
Response to:	-
Release:	-
Work Item:	-

Source:	CT1
To:	IETF SIPPING WG
Cc:	IETF MMUSIC WG
Cc:	3GPP/IETF and 3GPP/ITU-T Co-ordinator
Hannu HIETALAHTI (3GPP TSG CT Chair ([email-masked])
Contact Person:	
Name:	Christer HOLMBERG
E-mail Address:	[email-masked]

Attachments:	None

1. Overall Description:

3GPP CT1 has discussed the "Commit/Rollback of Offer/Answer on Unsuccessful re-INVITE Transaction" issue in draft-ietf-sipping-sip-offeranswer-06.txt.

A typical example of where subsequent offer/answer transactions may take place before a final answer to the re-INVITE request is received is when new media streams are added during an ongoing session, and those media streams require pre-condition procedures due to network/radio resource reasons. 

CT1 has identified the importance of a solution to the matter, in order to specify and implement interoperable procedures, and to avoid SDP state misalignments in cases where re-INVITE requests are rejected.

CT1 aims to be able to find a solution to the issue within the 3GPP Release 8 timeframe, which is scheduled to be frozen in December 2008.

2. Actions:
To IETF SIPPING WG
ACTION: 	CT1 asks SIPPING to take the importance of the issue into considerations in their work, and to provide guidance how to proceed on the matter.

3. Date of Next CT1 Meetings:
TITLE 	DATES 	LOCATION 	CTRY 
3GPPCT1#52 
7 - 11 Apr 2008    	Jeju Island  	KR  
3GPPCT1#53 
5 - 9 May 2008    	Cape Town  	ZA  
3GPPCT1#54 
23 - 27 Jun 2008    	Zagreb  	HR  
3GPPCT1#55 
18 - 22 Aug 2008    	Budapest  	HU  
3GPPCT1#56 
10 - 14 Nov 2008    	Shanghai  	CN
Attachment(s):
     LS on offer/answer procedures (https://datatracker.ietf.org/documents/LIAISON/file551.zip)

_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 21 Apr 2008 10:15:54 -0400

IMO this is a real, if obscure, issue. In the offeranswer draft we 
explicitly avoided making normative changes, opting to only bring 
together guidance on behavior that seemed to be mandated by existing 
RFCs, though often it took some subtle reasoning to dig out all the 
inferences.

We could find nothing that clearly suggested a particular answer to this 
case - it seems to be completely unspecified or ambiguous.

The good news is that there are only a couple of possible answers, and 
it is simply a matter of getting consensus on which is the best answer.

One procedural issue that needs to be sorted out is what WG is 
appropriate for doing this. Its clearly related to O/A, which has been 
worked on in mmusic. But the failure that results in the question about 
rollback typically is carried in the signaling, which in this case would 
be dealt with by the sip WG. OTOH, I think there is a very large overlap 
in participants between the two groups, so perhaps we should just 
discuss it somewhere and decide where to take action once we decide what 
result we want.

IMO, when it takes multiple O/A exchanges to resolve a set of 
preconditions the whole set should succeed or fail as a unit. Failing 
one o/a and rolling back to the prior one in the sequence makes little 
sense. However that is without regard for the transport of the O/A. It 
is possible that the message(s) carrying an o/a may fail. (E.g. because 
of a credentials challenge.) In that case it makes sense to retry the 
latest o/a exchange even if it is part of an extended preconditions 
negotiation.

The bottom line here is a need to carefully distinguish a failure of the 
o/a negotiation from a failure of the transport carrying the o/a exchange.

	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 22 Apr 2008 11:20:09 +0200

Hi,

As Paul said, there are basically two alternatives on the table. We have
been discussing the pros and cons of both, and I think there most people
agree there are good justifications for both alternatives.

So, maybe the way forward is simply to make a hum and pick one
alternative. Having it unspecified is bad, both for 3GPP and SIP in
general.

As seen from the LS, 3GPP thinks it's important to find a solution
(there is no official 3GPP view on which alternative is chosen, and my
feeling when discussing this was that most people could live with
whatever alternative - as long as one is chosen), and personally I think
finding a solution is important also from a generic SIP perspective.

RFC3261 currently says:

"However, the failure of the re-INVITE does not cause the existing call
to fail - the session continues using the previously negotiated
characteristics."

Now, IF we would choose to go with that text straight ahead, and say
that all o/a transactions taking place "during" the re-INVITE
transaction would also be ignored, I think we could document it in the
offer/answer draft as a clarification. We wouldn't need a new draft
specifying normative procedures.

IF we want to say that intermediate o/a transactions shall NOT be
ignored, we may need new normative text somewhere.

Regards,

Christer

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: 21. huhtikuuta 2008 17:16
To: Jean-Francois Mule
Cc: [email-masked]; Christer Holmberg
Subject: Re: [MMUSIC] FYI: New Liaison Statement, "LS on offer/answer
procedures"

The bottom line here is a need to carefully distinguish a failure of the
o/a negotiation from a failure of the transport carrying the o/a
exchange.

	Paul

Jean-Francois Mule wrote:
> All,
> 
>    This was just sent to SIPPING, cc: to MMUSIC (fyi for mmusic I
guess). The URL below points to a word document; I paste the text below.
Christer Holmberg is copied on this email and may provide more info to
the appropriate list.
> 
> Regards,
> Jean-Francois.
> 
> ------
> 1. Overall Description:
> 
> 3GPP CT1 has discussed the "Commit/Rollback of Offer/Answer on
Unsuccessful re-INVITE Transaction" issue in
draft-ietf-sipping-sip-offeranswer-06.txt.
> 
> A typical example of where subsequent offer/answer transactions may
take place before a final answer to the re-INVITE request is received is
when new media streams are added during an ongoing session, and those
media streams require pre-condition procedures due to network/radio
resource reasons. 
> 
> CT1 has identified the importance of a solution to the matter, in
order to specify and implement interoperable procedures, and to avoid
SDP state misalignments in cases where re-INVITE requests are rejected.
> 
> CT1 aims to be able to find a solution to the issue within the 3GPP
Release 8 timeframe, which is scheduled to be frozen in December 2008.
> 
> ----
> 2. Actions:
> To IETF SIPPING WG
> ACTION: 	CT1 asks SIPPING to take the importance of the issue
into considerations in their work, and to provide guidance how to
proceed on the matter.
> URL of the IETF Web page: 
> https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=444
> To: IETF MMUSIC WG,IETF SIPPING 
> WG([email-masked],[email-masked])
> Jeju Island, KOREA, 7th   11th April 2008
> 
> 3GPP CT1 has discussed the "Commit/Rollback of Offer/Answer on
Unsuccessful re-INVITE Transaction" issue in
draft-ietf-sipping-sip-offeranswer-06.txt.
> 
> A typical example of where subsequent offer/answer transactions may
take place before a final answer to the re-INVITE request is received is
when new media streams are added during an ongoing session, and those
media streams require pre-condition procedures due to network/radio
resource reasons. 
> 
> CT1 has identified the importance of a solution to the matter, in
order to specify and implement interoperable procedures, and to avoid
SDP state misalignments in cases where re-INVITE requests are rejected.
> 
> CT1 aims to be able to find a solution to the issue within the 3GPP
Release 8 timeframe, which is scheduled to be frozen in December 2008.
> 
> 2. Actions:
> To IETF SIPPING WG
> ACTION: 	CT1 asks SIPPING to take the importance of the issue
into considerations in their work, and to provide guidance how to
proceed on the matter.
>      LS on offer/answer procedures 
> (https://datatracker.ietf.org/documents/LIAISON/file551.zip)
> 
> 
>