Subject: [Sipping] Comments on draft-ietf-sipping-sip-offeranswer-03

From: Byron Campen <[email-masked]>
Date: Fri, 28 Sep 2007 12:08:37 -0500

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

Best regards,
Byron Campen

_______________________________________________
Sipping mailing list  https://www1.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