Subject: [sipcore] WGLC comments on draft-ietf-sipcore-reinvite-01

From: "Elwell, John" <[email-masked]>
Date: Tue, 2 Mar 2010 18:45:08 +0100

I read this document again and didn't find anything to prevent it progressing (although I would not claim to have done a thorough review).

Minor comments and nits:

- Section 1:
"A UAC willing to
   act the offerer"
Change "act" to "act as".

- Section 2: Where "UAC" and "UAS" expanded, it would probably be worth stating that the terms are used with respect to INVITE and re-INVITE transactions only. Other transactions within an INVITE or re-INVITE transaction can be in the reverse direction and the roles are reversed.

- Section 3.1:
"SDP4:
            m=audio 31000 RTP/AVP 0
            c=IN IP4 192.0.2.5
            m=video 0 RTP/AVP 31
            c=IN IP4 192.0.2.2" 
It seems unreasonable to include in an answer, below a rejected m-line, a c-line echoing the c-line in the offer.

- In the last example in 3.1, it should perhaps be pointed out that SDP5 (in the UPDATE request) is an offer. Also the contents of SDP6 (SDP answer) should perhaps also be shown for completeness.

- In section 3.3:
"During a session establishment, the UAS can wait for
   using the media parameters until "
Change "wait for" to "wait before" (or alternatively "delay").

- In section 3.7:
"The proxy relays the UPDATE request (9) to UA1.  The UPDATE request
   (9) arrives at UA1 before the 4xx response (7) that had been
   previously sent.  UA2 accepts the changes in the UPDATE request and
   returns a 200 (OK) response (10) to it ."
I think the last sentence should begin "UA1 accepts the changes..."

- "   SDP4: m=audio 20000 RTP/AVP 0 a=sendonly m=video 30002 RTP/AVP 31
   a=inactive"
Line breaks missing (c.f., the other examples).

- In section 4.4:
"In this document, reliable provisional responses are
      those that use the mechanism defined in RFC 3262 [RFC3262] on any
      other SIP-based mechanism that may be specified in the future."
Change "on" to "or".

- Change "If instead sending" to "If instead of sending"

John

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 04 Mar 2010 11:00:35 +0200

Hi John,

thanks for your comments. Answers inline:

> Change "act" to "act as".

Fixed.

> - Section 2: Where "UAC" and "UAS" expanded, it would probably be worth stating that the terms are used with respect to INVITE and re-INVITE transactions only. Other transactions within an INVITE o…

I have added the following paragraph:

"Note that the terms UAC and UAS apply to a transaction, not to a
dialog. For example, the UAC of a re-INVITE transaction can be the UAS
of an UPDATE transaction within the re-INVITE."

> It seems unreasonable to include in an answer, below a rejected m-line, a c-line echoing the c-line in the offer.

Fixed.

> - In the last example in 3.1, it should perhaps be pointed out that SDP5 (in the UPDATE request) is an offer. Also the contents of SDP6 (SDP answer) should perhaps also be shown for completeness.

I have clarified SDP5 is an offer and added SDP6.

> Change "wait for" to "wait before" (or alternatively "delay").

I have used "wait before".

> I think the last sentence should begin "UA1 accepts the changes..."

Fixed.

> Line breaks missing (c.f., the other examples).

Fixed.

>       other SIP-based mechanism that may be specified in the future."

Fixed.

> - Change "If instead sending" to "If instead of sending"

Fixed.

Thanks!

Gonzalo

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 4 Mar 2010 10:58:41 +0100

Gonzalo,

Thanks - I still have a concern, see below. 

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:[email-masked]] 
> Sent: 04 March 2010 09:01
> To: Elwell, John
> Cc: [email-masked]
> Subject: Re: [sipcore] WGLC comments on draft-ietf-sipcore-reinvite-01
> 
> Hi John,
> 
> > I read this document again and didn't find anything to 
> prevent it progressing (although I would not claim to have 
> done a thorough review).
> > 
> > Minor comments and nits:
> > 
> > - Section 1:
> > "A UAC willing to
> >    act the offerer"
> > - Section 2: Where "UAC" and "UAS" expanded, it would 
> probably be worth stating that the terms are used with 
> respect to INVITE and re-INVITE transactions only. Other 
> transactions within an INVITE or re-INVITE transaction can be 
> in the reverse direction and the roles are reversed.
> 
[JRE] I got the impression that the terms UAC and UAS were always used with respect to the re-INVITE transaction, even though there might also be an UPDATE transaction in the reverse direction. For example, if I look at figure 3, the entire left hand column is labelled "UAC", even though that entity is the UAS for the received UPDATE request ((6). I was looking for text more along the lines of:
"Note that the terms UAC and UAS are used with respect to an INVITE or re-INVITE transaction, and do not necessarily reflect the role of the UA concerned with respect to any other transaction, such as an UPDATE transaction occurring during the INVITE transaction."

John

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 04 Mar 2010 12:34:57 +0200

Hi John,

I have added your text (I replaced "during" with "within").

Thanks,

Gonzalo