Subject: [Sipping] [Fwd: I-D Action:draft-ietf-sipping-sip-offeranswer-09.txt]

From: Paul Kyzivat <[email-masked]>
Date: Mon, 03 Nov 2008 09:57:19 -0500

I just submitted a revised version of the offeranswer draft.
This addresses AD review comments from Jon. Most were superficial. But 
Jon had a lot of difficulty with section 4.1, and he wasn't the only 
one. So I elected to rewrite it completely. Its now so different that it 
needs careful scrutiny technically and editorially.

I intended to address comments by OKUMURA Shinji, but I didn't get to it.

I expect there will be yet another update to capture resolution of the 
remaining issues that will hopefully be negotiated at the upcoming meeting.

	Thanks,
	Paul

-------- Original Message --------
Subject: [Sipping] I-D Action:draft-ietf-sipping-sip-offeranswer-09.txt
Date: Mon,  3 Nov 2008 06:15:01 -0800 (PST)
From: [email-masked]
To: [email-masked]
CC: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Session Initiation Proposal 
Investigation Working Group of the IETF.

	Title           : SIP (Session Initiation Protocol) Usage of the 
Offer/Answer Model
	Author(s)       : P. Kyzivat
	Filename        : draft-ietf-sipping-sip-offeranswer-09.txt
	Pages           : 27
	Date            : 2008-11-03

The Session Initiation Protocol (SIP) utilizes the offer/answer
   model to establish and update multimedia sessions using the Session
   Description Protocol (SDP). The description of the offer/answer
   model in SIP is dispersed across multiple RFCs. This document
   summarizes all the current usages of the offer/answer model in SIP
   communication.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sipping-sip-offeranswer-09.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
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
_______________________________________________
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: OKUMURA Shinji <[email-masked]>
Date: Thu, 06 Nov 2008 19:31:55 +0900

Hi, 

I bring together my ideas.

1. UPDATE Request during the INVITE transaction

RFC:RFC3311/5.1 Sending an UPDATE (AFAIK)
BCP:I think(hope)
o:MAY send UPDATE with new offer
x:MUST NOT send UPDATE with new offer
#:should not send UPDATE with new offer

1.1. initial INVITE with an offer and PRACK without an offer
+---------------------------+---+--------------------------+
|         Caller            |   |           Callee         |
+---+---+-------------------+---+------------------+---+---+
|RFC|BCP|                   |   |                  |BCP|RFC|
+---+---+-------------------+---+------------------+---+---+
| x | x |                   |   |                  | x | x |
+---+---+-------------------+---+------------------+---+---+
|   |   |init-INVITE(offer1)|-->|                  |   |   |
+---+---+-------------------+---+------------------+---+---+
| x | x |                   |   |                  | x | x |
+---+---+-------------------+---+------------------+---+---+
|   |   |                   |<--|1xx-rel(answer1)  |   |   |
+---+---+-------------------+---+------------------+---+---+
| o | # |                   |   |                  | x | x |
+---+---+-------------------+---+------------------+---+---+
|   |   |PRACK(noSDP)       |-->|                  |   |   |
+---+---+-------------------+---+------------------+---+---+
| o | # |                   |   |                  | # | o |
+---+---+-------------------+---+------------------+---+---+
|   |   |                   |<--|2xx-PRACK         |   |   |
+---+---+-------------------+---+------------------+---+---+
| o | o |                   |   |                  | o | o |
+---+---+-------------------+---+------------------+---+---+

1.2. initial INVITE with an offer and PRACK with an offer
+---------------------------+---+--------------------------+
|         Caller            |   |           Callee         |
+---+---+-------------------+---+------------------+---+---+
|RFC|BCP|                   |   |                  |BCP|RFC|
+---+---+-------------------+---+------------------+---+---+
| x | x |                   |   |                  | x | x |
+---+---+-------------------+---+------------------+---+---+
|   |   |init-INVITE(offer1)|-->|                  |   |   |
+---+---+-------------------+---+------------------+---+---+
| x | x |                   |   |                  | x | x |
+---+---+-------------------+---+------------------+---+---+
|   |   |                   |<--|1xx-rel(answer1)  |   |   |
+---+---+-------------------+---+------------------+---+---+
| o | # |                   |   |                  | x | x |
+---+---+-------------------+---+------------------+---+---+
|   |   |PRACK(offer2)      |-->|                  |   |   |
+---+---+-------------------+---+------------------+---+---+
| x | x |                   |   |                  | x | x |
+---+---+-------------------+---+------------------+---+---+
|   |   |                   |<--|2xx-PRACK(answer2)|   |   |
+---+---+-------------------+---+------------------+---+---+
| o | o |                   |   |                  | o | o |
+---+---+-------------------+---+------------------+---+---+

1.3. initial INVITE without an offer
+---------------------------+---+--------------------------+
|         Caller            |   |           Callee         |
+---+---+-------------------+---+------------------+---+---+
|RFC|BCP|                   |   |                  |BCP|RFC|
+---+---+-------------------+---+------------------+---+---+
| x | x |                   |   |                  | x | x |
+---+---+-------------------+---+------------------+---+---+
|   |   |init-INVITE(noSDP) |-->|                  |   |   |
+---+---+-------------------+---+------------------+---+---+
| x | x |                   |   |                  | x | x |
+---+---+-------------------+---+------------------+---+---+
|   |   |                   |<--|1xx-rel(offer1)   |   |   |
+---+---+-------------------+---+------------------+---+---+
| x | x |                   |   |                  | x | x |
+---+---+-------------------+---+------------------+---+---+
|   |   |PRACK(answer1)     |-->|                  |   |   |
+---+---+-------------------+---+------------------+---+---+
| o | # |                   |   |                  | # | o |
+---+---+-------------------+---+------------------+---+---+
|   |   |                   |<--|2xx-PRACK         |   |   |
+---+---+-------------------+---+------------------+---+---+
| o | o |                   |   |                  | o | o |
+---+---+-------------------+---+------------------+---+---+

1.4. re-INVITE with an offer and PRACK without an offer
+---------------------------+---+--------------------------+
|         Caller            |   |           Callee         |
+---+---+-------------------+---+------------------+---+---+
|RFC|BCP|                   |   |                  |BCP|RFC|
+---+---+-------------------+---+------------------+---+---+
| o | o |                   |   |                  | o | o |
+---+---+-------------------+---+------------------+---+---+
|   |   |re-INVITE(offer1)  |-->|                  |   |   |
+---+---+-------------------+---+------------------+---+---+
| x | x |                   |   |                  | x | x |
+---+---+-------------------+---+------------------+---+---+
|   |   |                   |<--|1xx-rel(answer1)  |   |   |
+---+---+-------------------+---+------------------+---+---+
| o | # |                   |   | <see example 1>  | # | o |
+---+---+-------------------+---+------------------+===+===+
|   |   |PRACK(noSDP)       |-->|                  |   |   |
+---+---+-------------------+---+------------------+---+---+
| o | # |                   |   |                  | # | o |
+---+---+-------------------+---+------------------+---+---+
|   |   |                   |<--|2xx-PRACK         |   |   |
+---+---+-------------------+---+------------------+---+---+
| o | o |                   |   |                  | o | o |
+---+---+-------------------+---+------------------+---+---+

1.5. re-INVITE with an offer and PRACK with an offer
+---------------------------+---+--------------------------+
|         Caller            |   |           Callee         |
+---+---+-------------------+---+------------------+---+---+
|RFC|BCP|                   |   |                  |BCP|RFC|
+---+---+-------------------+---+------------------+---+---+
| o | o |                   |   |                  | o | o |
+---+---+-------------------+---+------------------+---+---+
|   |   |re-INVITE(offer1)  |-->|                  |   |   |
+---+---+-------------------+---+------------------+---+---+
| x | x |                   |   |                  | x | x |
+---+---+-------------------+---+------------------+---+---+
|   |   |                   |<--|1xx-rel(answer1)  |   |   |
+---+---+-------------------+---+------------------+---+---+
| o | # |                   |   | <see example 1>  | # | o |
+---+---+-------------------+---+------------------+===+===+
|   |   |PRACK(offer2)      |-->|                  |   |   |
+---+---+-------------------+---+------------------+---+---+
| x | x |                   |   |                  | x | x |
+---+---+-------------------+---+------------------+---+---+
|   |   |                   |<--|2xx-PRACK(answer2)|   |   |
+---+---+-------------------+---+------------------+---+---+
| o | o |                   |   |                  | o | o |
+---+---+-------------------+---+------------------+---+---+

1.6. re-INVITE without an offer
+---------------------------+---+--------------------------+
|         Caller            |   |           Callee         |
+---+---+-------------------+---+------------------+---+---+
|RFC|BCP|                   |   |                  |BCP|RFC|
+---+---+-------------------+---+------------------+---+---+
| o | o |                   |   |                  | o | o |
+---+---+-------------------+---+------------------+---+---+
|   |   |re-INVITE(noSDP)   |-->|                  |   |   |
+---+---+-------------------+---+------------------+---+---+
| o | # | <see example 2>   |   | <see example 3>  | # | o |
+===+===+-------------------+---+------------------+===+===+
|   |   |                   |<--|1xx-rel(offer1)   |   |   |
+---+---+-------------------+---+------------------+---+---+
| x | x |                   |   |                  | x | x |
+---+---+-------------------+---+------------------+---+---+
|   |   |PRACK(answer1)     |-->|                  |   |   |
+---+---+-------------------+---+------------------+---+---+
| o | # |                   |   |                  | # | o |
+---+---+-------------------+---+------------------+---+---+
|   |   |                   |<--|2xx-PRACK         |   |   |
+---+---+-------------------+---+------------------+---+---+
| o | o |                   |   |                  | o | o |
+---+---+-------------------+---+------------------+---+---+

I correct the prior ideas of mine.

I think, ua should not send the UPDATE request with new offer
at the time of x or #, and ua should reply 491(Request Pending)
for the UPDATE. It is the simplest, I think.
Of course,  other idea is smarter for several scenario, but
it might be complex.

example 1.
                    A                               B
                    |                               |
                    |re-INVITE(offer1)              |
                    |------------------------------>|
                    |                               |
                    |               1xx-rel(answer1)|
                    |<------------------------------|
                    |                               |
                    |                 UPDATE(offer2)|
                    |<==============================| <- should not send
                    |                               |
                    |491-UPDATE                     |
should reply 491 -> |==============================>|
                    |                               |
                    |PRACK(offer3)                  |
Wait until 491 ->   |------------------------------>|
                    |                               |
                    |             2xx-PRACK(answer3)|
                    |<------------------------------|
                    |                               |

example 2.
                    A                               B
                    |                               |
                    |re-INVITE(noSDP)               |
                    |------------------------------>|
                    |                               |
                    |UPDATE(offer1)                 |
should not send ->  |==============================>|
                    |                               |
                    |                     491-UPDATE|
                    |<==============================| <- should reply 491
                    |                               |
                    |                1xx-rel(offer2)|
                    |<------------------------------| <- Wait until 491
                    |                               |
                    |PRACK(answer2)                 |
                    |------------------------------>|
                    |                               |

example 3.
                    A                               B
                    |                               |
                    |re-INVITE(noSDP)               |
                    |------------------------------>|
                    |                               |
                    |                 UPDATE(offer1)|
                    |<==============================| <- should not send
                    |                               |
                    |491-UPDATE                     |
should reply 491 -> |==============================>|
                    |                               |
                    |                1xx-rel(offer2)| is offer2 equal to offer1 ?
                    |<------------------------------|(<- Wait until 491)
                    |                               |
                    |PRACK(answer2)                 |
                    |------------------------------>|
                    |                               |

2. re-INVITE Request during the UPDATE transaction
it seems a similar case but I think it's another issue.
I think 491 for re-INVITE is the simplest, but wait-until-2xx
is not bad.

example 4.
                    A                               B
                    |                               |
                    |UPDATE(offer1)                 |
                    |==============================>|
                    |                               |
should not send ->  |re-INVITE(noSDP)               |
                    |------------------------------>| 491 is the simplest ...?
                    |                               |
                    |            2xx-UPDATE(answer1)|
                    |<==============================|
                    |                               |
                    |                1xx-rel(offer2)| offer2 should include answer1
                    |<------------------------------| <- Wait until 2xx-UPDATE
                    |                               |
                    |PRACK(answer2)                 |
                    |------------------------------>|
                    |                               |

example 5.
                    A                               B
                    |                               |
                    |                 UPDATE(offer1)|
                    |<==============================|
                    |                               |
should not send ->  |re-INVITE(noSDP)               |
                    |------------------------------>| 491 is the simplest ...?
                    |                               |
                    |2xx-UPDATE(answer1)            |
                    |==============================>| <- should prepare to 491
                    |                               |
                    |                1xx-rel(offer2)|
                    |<------------------------------| <- Wait until 2xx-UPDATE
                    |                               |
                    |PRACK(answer2)                 |
                    |------------------------------>|
                    |                               |

example 6. Glare Case for exsample 5

                    A                               B
                    |                               |
                    |                 UPDATE(offer1)|
                    |                  /============|
should not send ->  |re-INVITE(noSDP) /             |
                    |----------------/------------->|
                    |               /               |
                    |<=============/                |
                    |                               |
                    |491-UPDATE                     |
                    |==============================>| <- should prepare to 2xx
                    |                               |
                    |                1xx-rel(offer2)|
                    |<------------------------------| <- Wait until 491-UPDATE
                    |                               |
                    |PRACK(answer2)                 |
                    |------------------------------>|
                    |                               |

Regards,
Shinji

Paul Kyzivat <[email-masked]>
>	Title           : SIP (Session Initiation Protocol) Usage of the Offer/Answer Model
>	Author(s)       : P. Kyzivat

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 06 Nov 2008 10:40:07 -0500

> I bring together my ideas.

There is a lot here that I need to study. So I will not comment 
immediately.

Will you be attending the upcoming ietf meeting?

	Thanks,
	Paul

---

From: OKUMURA Shinji <[email-masked]>
Date: Fri, 07 Nov 2008 15:53:31 +0900

Hi, Mr. Kyzivat,

I'm sorry to say that it is not scheduled to attend the
meeting.

>1. UPDATE Request during the INVITE transaction

My tables will be a summary of RFC3311/5.1 Sending an
UPDATE. The point of my ideas is as follows. 

1.An UPDATE request with new offer should not be sent until the
  PRACK transaction related to the offer-answer is completed. 

2.UA should respond 491 when such UPDATE is received.

3.for this respect, there are no basic differences between
  init-INVITE and re-INVITE.
  I think, RFC3311 are too generous to re-INVITE.

> 2. re-INVITE Request during the UPDATE transaction

Obviously such INVITE should not be sent, but glare case
can't be avoided.

3. another issue about Modifying an Existing Session

Though it is not referred in draft.

RFC3261/14.2 UAS Behavior
   A UAS providing an offer in a 2xx (because the INVITE did not contain
   an offer)                  [Snipping]                    The UAS MUST
   ensure that the session description overlaps with its previous
   session description in media formats, transports, or other parameters
   that require support from the peer.  This is to avoid the need for
   the peer to reject the session description.

This rule should adjust to not only 200-OK but also 1xx-rel and PRACK.

Regards,
Shinji

---

From: Hendrik Scholz <[email-masked]>
Date: Sat, 15 Nov 2008 21:58:15 +0100

Hi!

I noticed this in section 3.1:

   o To avoid receiving media from undesired sources, some User
      Agents assume symmetric RTP will be used, ignore all incoming
      media packets until an address/port has been received from the
      other end, and then use that address/port to filter incoming
      media packets.

Should a UA silently drop/ignore the packets or is it OK to
send ICMP port unreachables?
If the UA does not follow RFC3261 ("start accepting RTP once
it sends the SDP offer") the remote endpoint would have to
be able to deal with ICMP errors.

Thanks,
  Hendrik

-- 
Hendrik Scholz <[email-masked]>