Subject: [Sipping] New version posted: draft-ietf-sipping-sip-offeranswer-11.txt

From: Paul Kyzivat <[email-masked]>
Date: Mon, 18 Jan 2010 12:48:44 -0500

I just posted a new version of the offeranswer draft.
This version is intended to resolve all outstanding issues.

Here is a summary of substantial changes made:

- the open issues that were previously in section 6 were
   removed. The doc has been updated as needed to be consistent
   with conclusions about how to deal with those issues.
   Specifically:

   - Rejecting PRACK offer has simply been dropped.
     There has been no ongoing interest in no normative work
     to support doing that.

   - Commit/Rollback of Offer/Answer on Unsuccessful re-INVITE	 		 
Transaction has been resolved by reference to
     draft-camarillo-sipcore-reinvite-01. New text referencing
     that has been added at multiple places in the document.

   - Loosening requirement for Offer in a Reliable Response:
     Again there has been no indication of intent to do anything
     in this space, so the topic has simply been dropped.

   - Requesting Hold while already on Hold:
     This was already addressed in the main body of the document.
     The issue was whether this was appropriate, since it rests on
     the interpretation of certain text in 3261 being non-normative.
     That assumption has been restated in the main body.
     I'm unaware of any argument to that in over two years.

- The recommendations for addition of new o/a usage in sip
   (prior section 7) has also been dropped. While these may have
   been helpful during discussion of the draft, they aren't
   helpful after it is finalized.

- I rearranged the order of authors since Takuya has been unavailable
   to work on it for some time. However I have retained him as an author
   because the preponderance of the text is still his.

In addition there hare assorted miscellaneous minor cleanups.

	Thanks,
	Paul

[email-masked] wrote:
> New version (-11) has been submitted for draft-ietf-sipping-sip-offeranswer-11.txt.
> http://www.ietf.org/internet-drafts/draft-ietf-sipping-sip-offeranswer-11.txt
> Sub state has been changed to AD Follow up from New Id Needed
> 
> Diff from previous version:
> http://tools.ietf.org/rfcdiff?url2=draft-ietf-sipping-sip-offeranswer-11
> 
> IETF Secretariat.
>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 18 Jan 2010 20:12:54 +0100

Hi,

The rejecting PRACK offer is still "ongoing", but unfortuantely I have not had time to do much onit lately - mostly due to INFO.

Regards,

Christer

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Paul Kyzivat [[email-masked]]
Sent: Monday, January 18, 2010 7:48 PM
To: [email-masked]
Cc: sipping
Subject: [Sipping] New version posted:  draft-ietf-sipping-sip-offeranswer-11.txt

        Thanks,
        Paul

> http://tools.ietf.org/rfcdiff?url2=draft-ietf-sipping-sip-offeranswer-11
_______________________________________________
Sipping mailing list  https://www.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: [email-masked]
Date: Tue, 19 Jan 2010 09:06:34 +0800

I know that there are many sip-developers learn a lot from this text. And 
I use it as manual years ago.

Thank you, Paul.

===================================
 Zip    : 210012
 Tel    : 87211
 Tel2   :(+86)-025-52877211
 e_mail : [email-masked]
===================================

Paul Kyzivat <[email-masked]> 
发件人:  [email-masked]
2010-01-19 01:48

收件人
[email-masked]
抄送
sipping <[email-masked]>
主题
[Sipping] New version posted:   draft-ietf-sipping-sip-offeranswer-11.txt

                 Thanks,
                 Paul

[email-masked] wrote:
> New version (-11) has been submitted for 
draft-ietf-sipping-sip-offeranswer-11.txt.

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: [email-masked]
Date: Tue, 19 Jan 2010 09:21:15 +0800

By current normative definition, UAS of PRACK MUST send 2xx when recv 
1xx(100rel).

RFC3262:
If the PRACK does match an
   unacknowledged reliable provisional response, it MUST be responded to
   with a 2xx response. 

So, UAC of PRACK should make sure UAS of PRACK will accept the offer in 
PRACK. 

If UAC of PRACK is not careful enough, UAS still MUST send Answer in 2xx 
of PRACK(RFC3262 defines:If the UAS receives a PRACK with an offer, it 
MUST place the answer in the 2xx to the PRACK.).

UAS can reject the Offer by setting streams' ports as zero. If it is not 
enough, UAS can send another Offer in UPDTAE.

I think the process is clear and effective for all cases.

Thanks,

Gao

Christer Holmberg <[email-masked]> 
发件人:  [email-masked]
2010-01-19 03:12

收件人
Paul Kyzivat <[email-masked]>, "[email-masked]" 
<[email-masked]>
抄送
sipping <[email-masked]>
主题
Re: [Sipping] New version       posted: 
draft-ietf-sipping-sip-offeranswer-11.txt

Hi,

The rejecting PRACK offer is still "ongoing", but unfortuantely I have not 
had time to do much onit lately - mostly due to INFO.

Regards,

Christer

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of 
Paul Kyzivat [[email-masked]]
Sent: Monday, January 18, 2010 7:48 PM
To: [email-masked]
Cc: sipping
Subject: [Sipping] New version posted: 
draft-ietf-sipping-sip-offeranswer-11.txt

        Thanks,
        Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 19 Jan 2010 07:32:02 +0100

Hi, 

>	By current normative definition, UAS of PRACK MUST send 2xx when recv 1xx(100rel). 
>	
>	RFC3262: 

And, that text is the background for the whole issue.

>	So, UAC of PRACK should make sure UAS of PRACK will accept the offer in PRACK. 

Please tell me how the UAC does that... I think we in previous discussions have concluded that it is not possible to specify such thing.

Even if the offer is very "simple" (doesn't change much since the previous offer etc), the UAS may have to reject it simply because of resource issues.

>	If UAC of PRACK is not careful enough, UAS still MUST send Answer in 2xx of PRACK(RFC3262 defines:If the UAS receives a PRACK with an offer, it MUST place the answer in the 2xx to the PRACK.). 

I know what the text says.

>	UAS can reject the Offer by setting streams' ports as zero. If it is not enough, UAS can send another Offer in UPDTAE. 

Port zero indicates that the streams have been removed, which in most cases is probably not the case.

>	I think the process is clear and effective for all cases. 

Whatever the solution is, we have a long time ago decided that we are going to write some clarification text about it.

But, in any case, it's probably a good idea to start by going back and checking previous discussions.

Regards,

Christer

	2010-01-19 03:12 

		收件人
		Paul Kyzivat <[email-masked]>, "[email-masked]" <[email-masked]> 
		抄送
		sipping <[email-masked]> 
		主题
		Re: [Sipping] New version        posted:        draft-ietf-sipping-sip-offeranswer-11.txt

	Hi,

	Regards,
	
	Christer

	

	

	

	
	       Thanks,
	       Paul

---

From: [email-masked]
Date: Tue, 19 Jan 2010 15:04:37 +0800

Hi,

inlines.

Thanks,

Gao

Christer Holmberg <[email-masked]> 写于 2010-01-19 

> And, that text is the background for the whole issue.

[Gao] That's why I paste it here.

> Please tell me how the UAC does that... I think we in previous 
> discussions have concluded that it is not possible to specify such 
thing.

[Gao] I just insist that we should not change the current normative 
definition if current rule is clear(under ratiocination) and effective.
If someone can do some BCP text about which can be in PRACK's Offer, I 
think it would be better.

> 
> Even if the offer is very "simple" (doesn't change much since the 
> previous offer etc), the UAS may have to reject it simply because of
> resource issues.

[Gao] Codec refine is the case in which UAC use the subset of codecs from 
previous O/A. If UAS would reject it, I think it should reject the Offer 
in previous O/A.
And changing of IP, port is also the case.

And we really have reserved the right for UAS rejecting the Offer by next 
UPDATE.

> 
> 
> >   If UAC of PRACK is not careful enough, UAS still MUST send 
> Answer in 2xx of PRACK(RFC3262 defines:If the UAS receives a PRACK 
> with an offer, it MUST place the answer in the 2xx to the PRACK.). 
> 
> >   UAS can reject the Offer by setting streams' ports as zero. If 
> it is not enough, UAS can send another Offer in UPDTAE. 
> 
> Whatever the solution is, we have a long time ago decided that we 
> are going to write some clarification text about it.
>

[Gao] By my self, I just do not prefer to handle non-2xx response of 
PRACK. 

I think one BCP text as I mentioned previous is welcome.

>    The rejecting PRACK offer is still "ongoing", but unfortuantely I
> have not had time to do much onit lately - mostly due to INFO.
> 
>    Regards,
> 
>    Christer
> 
>    From: [email-masked] [[email-masked]] On 
> Behalf Of Paul Kyzivat [[email-masked]]
>    ZTE Information Security Notice: The information contained in 
> this mail is solely property of the sender's organization. This mail
> communication is confidential. Recipients named above are obligated 
> to maintain secrecy and are not permitted to disclose the contents 
> of this communication to others.
>    This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom they
> are addressed. If you have received this email in error please 
> notify the originator of the message. Any views expressed in this 
> message are those of the individual sender.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 19 Jan 2010 10:13:34 -0500

Gao,

Is your message below requesting additional changes to the draft?

While I think what you say can work in *most* cases, there will continue
to be (unlikely) cases that demand an error response. For example:

- The UAS requires credentials in all requests, and the credentials
  are either not present in the PRACK, or are wrong.

- The request contains an offer that is syntactically incorrect,
  and so cannot be parsed by the UAS.

- The request contains an incorrect (too small) CSeq.

	Thanks,
	Paul

[email-masked] wrote:
> *Christer Holmberg <[email-masked]>*
> The rejecting PRACK offer is still "ongoing", but unfortuantely I have 
> not had time to do much onit lately - mostly due to INFO.
> 
> Regards,
> 
> Christer
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 19 Jan 2010 10:13:34 -0500

Gao,

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 19 Jan 2010 10:18:38 -0500

Christer,

Certainly there is no problem with continuing to discuss that.
But I didn't see any reason to mention it in this draft any longer.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 19 Jan 2010 18:17:53 +0100

Hi,

>But I didn't see any reason to mention it in this draft any longer.

Wouldn't it be good to still describe the problem, but maybe indicate that the solution is outside the scope of the document?

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 19 Jan 2010 12:43:13 -0500

> Wouldn't it be good to still describe the problem, but maybe indicate that the solution is outside the scope of the document?

IMO, such a statement in an RFC tends to get stale with time.

What do others think? Do you want this document to go to RFC containing 
statements of work we might want to do in the future?

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 19 Jan 2010 19:05:46 +0100

Hi,

>statements of work we might want to do in the future?

In my experience it is not unusual to state that something is outside the scope of a document.

We don't need to say what may, and may not, be done in the future, simply say that it is outside the scope of THIS document.

Regards,

Christer

        Thanks,
        Paul

---

From: OKUMURA Shinji <[email-masked]>
Date: Wed, 20 Jan 2010 17:21:13 +0900

Hi,

I have some comments about section 4.
These comments are almost the same as my comments for draft-08
in last September.

>4.1.  Message Crossing Case Handling
>
>   When message packets cross in the transport network, an offer may be
>   received before the answer for the previous offer/answer exchange, as
>   shown in Figure 3.  In such a case, UA A must detect that the session
>   description SDP-2 is not the answer to offer1.
>
>
>         A                  B
>         |SDP-1     (offer1)|
>      M1 |----------------->|
>         |SDP-2    (answer1)|
>      M2 |<------\  /-------|
>         |        \/        |
>         |SDP-3   /\(offer2)|
>      M3 |<------/  \-------|
>
>                      Figure 3 Message Crossing Case
>
>   Because of the restrictions on placement of offers and answers
>   (summarized in Table 1) there are a limited number of valid exchanges
>   of messages that may lead to this message crossing case.  These are
>   enumerated in Table 3.  (This table only shows messages containing
>   offers or answers.  There could be other messages, without session
>   descriptions, which are not shown.)
>
>   There is a variant, shown in Figure 4, which is dependent on an
>   INVITE (Mx) that contains no offer.  This case should be extremely
>   rare - it is easily avoided by delaying Mx until answer1 is received.
>   It adds another possibility to Table 3.
>
>         A                               B
>         |                               |
>         |SDP-1              offer1(UPD) |
>      M1 |==============================>|
>         |re-INV              (no offer) |
>      Mx |------------------------------>| --+
>         |SDP-2         answer1 (2xx-UPD)|   |
>      M2 |<===========\  /===============|   | first reliable
>         |             \/          offer2|   | response
>         |SDP-3        /\   (1xx-rel/2xx)|   |
>      M3 |<===========/  \===============| <-+
>         |SDP-4       answer2 (PRACK/ACK)|
>      My |------------------------------>| Wait until answer1
>         |                               |
>
>      Figure 4 Reliable response as a message with offer2 in message
>                               crossing case

re-INVITE without SDP must cause new offer-answer exchange,
so that I think UA A should not send re-INVITE, until answer1
is received. It is simpler.

And in section 4.2
>   To avoid a glare condition involving an offer in a response, when UA
>   A has sent a (re)INVITE request without session description, it
>   should not send an offer until it has received an offer in a reliable
>   response to the (re)INVITE, and sent an answer to that offer.

I think the same rule should be adjusted.
A should delay sending the re-INV(no offer) until M3.
B is recommended to respond 491 for this re-INV.

>         | M1     | M3       | M2      |
>         |--------+----------+---------|
>         | INVITE | 1xx-rel  | UPDATE  | <-- not happen
>         |--------+----------+---------|
>         | PRACK  | 200-PRA  | UPDATE  |
>         |--------+----------+---------|
>         | UPDATE | 200-UPD  | UPDATE  |
>         |        |          |---------|
>         |        |          | INVITE  | (no INV in progress)
>         |        |          |---------|
>         |        |          | 2xx-INV | (INV in progress)
>         |        |          |---------|
>         |        |          | 1xx-rel | (from Figure 4)
>         |-----------------------------|
>
>            Table 3. Offer / Answer Crossing Message Sequences

1st case is not happen.
Probably RFC3311(UPDATE) prohibits this signaling.

I revise the table 3.

         | M1     | M3       | M2      |
         +--------+----------+---------+
         | UPDATE | 2xx-UPD  | UPDATE  |  491
         |        |          +---------|
         |        |          | INVITE  |  491
         |        |          +---------+
         |        |          | 2xx-INV |  A SHOULD Delay re-INV until M3
         |        |          +---------+
         |        |          | 1xx-INV |  B is RECOMMENDED to respond 491 for this re-INV
         +--------+----------+---------+
         | INVITE | 1xx-rel  | --      |
         |--------+----------+---------+
         | INVITE | 2xx-INV  | --      |
         +--------+----------+---------+
         | PRACK  | 2xx-PRA  | UPDATE  |  491
         +--------+----------+---------+
         | 1xx-rel| PRACK    | --      |
         +--------+----------+---------+
         | 2xx-INV| ACK      | UPDATE  |  491
         |        |          +---------+
         |        |          | INVITE  |  491
         +--------+----------+---------+

         --:not happen

After all, necessary rules are just three.

While offer-answer exchange is not completed,
	UA MUST reject reINVITE and UPDATE with offer by 491.
	UA should not send reINVITE without offer.
	UA is recommended to reject reINVITE without offer by 491.

>4.2.  Glare Case Handling
>
>   When both ends in a dialog send a new offer at nearly the same time,
>   as described in Figure 5, a UA may receive a new offer before it
>   receives the answer to the offer it sent.  This case is usually
>   called a 'glare' case.
>
>
>      A                  B
>      |offer1      offer2|
>      |-------\  /-------|
>      |        \/        |
>      |        /\        |
>      |<------/  \------>|
>
>                            Figure 5 Glare Case

Possible case I think.

   | offer1   | offer2   |
   +----------+----------+
   | reINVITE | reINVITE |
   |          +----------+
   |          | UPDATE   |
   +----------+----------+
   | UPDATE   | UPDATE   |
   |          +----------+
   |          | 1xx-rel  |
   |          +----------+
   |          | 2xx-INV  |
   +----------+----------+
   | PRACK    | --       |
   +----------+----------+

>   When offer2 is in a PRACK request (within the current rules, only
>   possible if offer1 is in an UPDATE request), the PRACK may be
>   accepted with 200 or may be rejected with a 491 response.  A 491
>   response is valid to satisfy the offer/answer model but it may delay
>   the completion of the reliable response transfer mechanism or, in
>   worst case, may result in the failure to complete the SIP transaction
>   because there is no clear retry rule when a PRACK request is rejected
>   with a 491 response.  To avoid this glare condition, UA A should not
>   send an offer if it has already sent a reliable provisional response
>   containing an answer to a previous offer and has not received the
>   corresponding PRACK request.

In my understanding, the following figure summarizes
the above description.

    A                               B
    |                               |
    |                   INV (offer0)|
    |<------------------------------|
    | 1xx-rel (answer0)             |
    |------------------------------>| --+
    |                               |   | Acknowledge
    | offer1(UPD)        offer2(PRA)|   |
    |============\  /===============| <-+
    |             \/                |
    |             /\                |
    |<===========/  \==============>|
    |                               |

I think that the offer1 is a protocol violation as PRACK case in 4.1.
Probably RFC3311(UPDATE) prohibits this operation.

>   To avoid a glare condition involving an offer in a response, when UA
>   A has sent a (re)INVITE request without session description, it
>   should not send an offer until it has received an offer in a reliable
>   response to the (re)INVITE, and sent an answer to that offer.

the following figure summarizes the above.

    A                               B
    |                               |
    |re-INV (no offer)              |
    |------------------------------>| --+
    |                        offer2 |   |
    |offer1(UPD)       (1xx-rel/2xx)|   |
    |============\  /===============| <-+ The 1st reliable response
    |             \/                |
    |             /\                |
    |<===========/  \==============>|
    |                               |

In conclusion, I think as follows.

  offer2 |  Actions to take (UA A)
  -------+---------------------------
  INVITE |  491 response
  UPDATE |  with Retry-After
  -------+---------------------------
  PRACK  |  This case not happens
         |  under the current rules.
  -------+---------------------------
  1xx-rel|  should not send UPDATE
  2xx    |  until answer2 is sent
         | (B reject UPDATE by 491)
  -------+---------------------------

And these rules are almost the same as 4.1.

Regards,
Shinji

---

From: [email-masked]
Date: Wed, 20 Jan 2010 21:39:15 +0800

Hi Paul,

I am not sure could I giving a rigorous answer. To be honest, I think it 
is a balance between cutting down PRACK's usages and allowing non-2xx of 
PRACK.

Allowing non-2xx of PRACK means re-acknowledgement of the 1xx of 100-rel, 
and the soultion is too complex for sip-stack developers. And compatible 
*war* would be lighted up while people do interoperability testing.

So, I prefer cutting down PRACK's usages to make thing simple if we can 
handle/elude all the issues well for PRACK. 

For the example, I have some suggestion/feeling(just for discussion). 
Please see inlines.

Thanks,

Gao

>   are either not present in the PRACK, or are wrong.

We usually use INVITE/REGISTER to establish IPSec channel to elude 
subsequent requests' authorization. But when the equipment do not support 
IPSec or they just need authorization for PRACK, we still neet to handle 
this issue.
UAS can add WWW-Authenticate header in 1xx(100-rel) if it need UAC's 
credential  for PRACK(this handling may need normative extension), and UAC 
can send credential in PRACK's Authorization header.(By doing this, UAS 
can elude sending 401 for PRACK).

But there isn't the proper guide for UAS to handle PRACK without 
credential while it has challenged the UAC. Can the UAS just terminate the 
dialog and session?

>   and so cannot be parsed by the UAS.

UAS can just terminate the dialog and session or send a new Offer in 
UPDATE.

> - The request contains an incorrect (too small) CSeq.

I am not under condition, will "too samll CSeq" can reduce "does not match 
any unacknowledged reliable provisional response".
If it is, then UAS can send 481, then terminate the dialog and session.

> > ZTE Information Security Notice: The information contained in this
> mail is solely property of the sender's organization. This mail

---

From: OKUMURA Shinji <[email-masked]>
Date: Thu, 21 Jan 2010 15:45:37 +0900

Hi,

The offer in 1xx-rel and 2xx (for reINVITE) also have the same
problem as PRACK offer. Even if UAC is not possible to accept
the offer, UAC must send ACK/PRACK.

Even though my suggestion violates RFCs, I think that UA may
be allowed to send ACK/PRACK without SDP for these cases.

Regards,
Shinji

>Hi,
>
>The rejecting PRACK offer is still "ongoing", but unfortuantely
>I have not had time to do much onit lately - mostly due to INFO.
>
>Regards,
>
>Christer
>

---

From: [email-masked]
Date: Thu, 21 Jan 2010 15:06:38 +0800

Hi Shinji,

Please see inlines. 

Thanks,

Gao

> the offer, UAC must send ACK/PRACK.

I think UAC must send ACK/PRACK in such condition. And the Answer must be 
in ACK/PRACK too, if the UAC want to maintain the established session.

Or, if the UAC do not want to mantain this session any more, it can/may 
send ACK/PRACK without SDP for these cases as you suggested below. I just 
want to emphasize that if UAC want to maintain the established session, it 
MUST NOT do anything violating current normative defintion. Because in 
interoperating texting, such neglect may cause UAS to send BYE.

Paul 
> >Kyzivat [[email-masked]]
> >Subject: [Sipping] New version posted:  draft-ietf-sipping-sip-
> offeranswer-11.
> >txt
> >
> >> New version (-11) has been submitted for draft-ietf-sipping-sip-
> offeranswer-11.
> >> txt.