Draft: draft-ietf-sipping-sip-offeranswer-03
Reviewer: Byron Campen [bcampen@estacado.net]
Review Date: 28 Sept 2007
Review Deadline: 30 Sept 2007
Status: WGLC

Summary: Right track; minor issues.

NITS/editorial:


In section 6:
"It is not recommended to add new SIP methods for the offer/answer 
       exchange beyond the ways described in this document."


"SIP methods" might be confusing, maybe "This document recommends against the addition of new offer/answer methods using SIP."




" However, it may 
       be requested to have new offer/answer exchange methods as SIP 
       extensions evolve. "


awkward, how about


" However, it may 
       be neccessary to define new offer/answer exchange methods as SIP 
       extensions evolve. "


"In this clause, what should be taken into 
       considerations is noted."


Should probably read:


"In this section, what should be taken into 
       consideration is noted."




Minor technical:


On Table 1:


It seems that 'Early' really means 'The active INVITE transaction has already received a reliable provisional response.' For the initial INVITE transaction, this corresponds to an Early dialog, but for reINVITE, it does not (dialog is already established). As I read the standards, exchanges 1-4 cannot be done once a reliable response has been received, regardless of whether this is the initial INVITE or a reINVITE, correct?


We could also say that 1-4 are not valid unless they are the first offer/answer exchange in a given INVITE transaction.


Section 3.2:


There is a glare case that might be work detailing separately in this section. ("one-sided glare" is how I have described this in the past). This occurs when two UAs send offers at one another (in a reINVITE, UPDATE, whichever), but one of the offers is sufficiently delayed that it arrives after the 491. Here's a diagram.


             A          B
             |          |
INVITE (sdp) |-.       /| INVITE (sdp)
             |  '-.   / |
             |     '-/  |
             |      / ->|
             |     /  .-| 491
             |    /.-'  |
             |<-./'     |
             |  /       |
             | /        |
             |<         |
             |          |
   200 (sdp) |--------->|
             |          |


Just a single dropped UDP packet would be sufficient to cause this scenario.


Major technical:


None