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

From: Takuya Sawada <[email-masked]>
Date: Tue, 9 Oct 2007 13:28:11 +0900

Hi Byron,

Thank you for the review and comments.

Responses inline.

> 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."
>
OK. I will take it.

>" 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. "
>
I will take it, too.

> "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."
>
OK.
>
> 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.
>
Yes. But we already said as follows.

---
Note that an offer/answer exchange initiated by an INVITE request must
follow exactly one of the patterns 1, 2, 3, 4.
---

Is this not enough?

> 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.
> 
I agree this scenario can happen.
I guess offer/answer exchange initiated from B is valid in both ends.
Is this correct?
Probably I don't understand the point. What is the point here?

> Major technical:
> None
Good. Thanks.

Regards,
Takuya

> 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

---

From: Byron Campen <[email-masked]>
Date: Fri, 12 Oct 2007 11:07:45 -0500

> follow exactly one of the patterns 1, 2, 3, 4.

	This statement doesn't restrict us from using type 4 if we've  
already done a type 3 or 4 in the same INVITE transaction.

> Probably I don't understand the point. What is the point here?

	I anticipate confusion on this issue; if we drew this diagram like  
this instead:

              A          B
              |          |
    ????????  |--------->|
              |          |

	I would bet good money that a significant number of implementors  
will expect that A should send a 491, "because it is a glare  
situation". Basically, B shouldn't abandon its offer until it is  
definitively rejected (ie, it should not be abandoning its offer when  
the other offer comes in).

Best regards,
Byron Campen

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 12 Oct 2007 12:13:39 -0400

Byron Campen wrote:

> I anticipate confusion on this issue; if we drew this diagram like this 
> instead:
> 
>              A          B
>              |          |
> I would bet good money that a significant number of implementors will 
> expect that A should send a 491, "because it is a glare situation". 
> Basically, B shouldn't abandon its offer until it is definitively 
> rejected (ie, it should not be abandoning its offer when the other offer 
> comes in).

Live and learn - it would never have occurred to me that any other 
behavior made sense.

	Paul