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

From: Takuya Sawada <[email-masked]>
Date: Mon, 23 Jul 2007 22:22:01 +0900

Hi Christer,

Thank you for the review.

Comments inline.

> Hi,
> 
> ISSUE 1:
> -------------
> 
> One issue which we have discussed, and I think should be added to
> chapter 5, is regarding the case when an INVITE is sent without and
> offer, and the first reliable response MUST contain an offer.
> 
> The question has been why a reliable PROVISIONAL response would be
> required to carry an offer in this case, and nobody has really given any
> good explanation. So, I think we should say that one remaing issue is
> whether that requirement could be "loosen up".
> 
I do not know why RFC 3261 defines that the first reliable response
must carry an offer, neither.

Now my question is "are there any needs to loose it up?"

If yes, then we ask whether that requirement could be "loosen up".
If no, we can leave it as it is.

> ISSUE 2:
> -------------
> 
> I think chapter 5.1 should say WHICH rules are broken if the 200 OK is
> sent without a SDP.
> 
The rule 5 in Table 1, right?

I think we can add some text for it.

> 
> ISSUE 3:
> -------------
> 
> I think it is important to document the alternatives we have discussed,
> and one alternative that has been discussed, and which I want to add to
> chapter 5.1, is to send an SDP answer with the o- line unchanged.
> 
> Because, if we don't document what we have discussed it is difficult for
> people to start thinking and developing the proposed solutions.
> 
Well, I have a slight memory but I am not sure if it is o- line unchanged.
Isn't it to decrease o- line ver.?
Not to change o- line seems to be the normal case.

Anyway I think we can list the alternatives.
> 
> ISSUE 4:
> -------------
> 
> In the table in chapter 1.2, I propose:
> 
> "5. PRACK Req. (*)       200 PRACK Resp. followed by new offer OR
> rejection of dialog"
> 
> ...to be compliant with the text above, and avoid confusion about what
> to do it if not possible to send a new update (e.g. if the UPDATE method
> is not supported).
> 
The draft already says;

  When a UA receives a PRACK request with an offer which it can not 
  accept, it may respond with a 200 response with a syntactically 
  correct session description followed by an UPDATE request possibly to 
  rearrange the session parameters if both ends support UPDATE method. 
  A UA may simply give up continuing the dialog and send an error 
  response to the INVITE request. (Pattern 5) 

Isn't it enough?

If we add "OR rejection of dialog" to the pattern 5 in the Table 2,
we should add the same words to the pattern 2 for the same reason.

> 
> ISSUE 5:
> -------------
> 
> To my understanding, only the FIRST PRACK can contain an offer, so if
> the first answer comes for example in the second reliable provisional
> response PRACK can no longer be used to send a new offer.
> 
> I think that should be made clear in the draft.
> 
Is this true?

RFC 3262 only says;

  If the UAC receives
  a reliable provisional response with an answer, it MAY generate an
  additional offer in the PRACK.

I think that if the first reliable response does not contain an answer
and the second one contains an answer, the PRACK to the second reliable
response can still contain a new offer.

Regards,
Takuya

> 
> Regards,
> 
> Christer
> 
> 
> _______________________________________________
> 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
> 

--------
Takuya Sawada
KDDI Corporation (KDDI)
Garden Air Tower, 3-10-10, Iidabashi, 
Chiyoda-ku, Tokyo 102-8460, Japan
Tel: +81-3-6678-2997
Fax: +81-3-6678-0286
[email-masked]

_______________________________________________
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: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Mon, 23 Jul 2007 21:29:36 +0200

Hi, 

>>required to carry an offer in this case, and nobody has really given 
>>any good explanation. So, I think we should say that one remaing issue

>>is whether that requirement could be "loosen up".
>> 
>If no, we can leave it as it is.

I don't think there is any "requirement" to loose it up. But, it has
been discussed, and that it would be useful to loose it up, so therefor
I think it would be good to document it.

>I think we can add some text for it.
 
I was more thinking about refering to text in RFC3262.

>>ISSUE 3:
>>-------------
>> 
>>I think it is important to document the alternatives we have 
>>discussed, and one alternative that has been discussed, and which I 
>>want to add to chapter 5.1, is to send an SDP answer with the o- line
unchanged.
>> 
>>Because, if we don't document what we have discussed it is difficult 
>>for people to start thinking and developing the proposed solutions.
>> 

Yes, I am talking about the version parameter of the o- line. I don't
think the value needs to be decreased, but simply kept unchanged from
the previous SDP sent by the same client.

A third alternative, which has also been discussed and should be
documented, is to not allow SDP in PRACK at all.

rejection of dialog"

>>to do it if not possible to send a new update (e.g. if the UPDATE 
>>method is not supported).
>> 
>The draft already says;
> 
> correct session description followed by an UPDATE request 
> possibly to rearrange the session parameters if both ends support 
> UPDATE method. 

I think it would be good if the table reflects everthing said in the
text. 

>If we add "OR rejection of dialog" to the pattern 5 in the 
>Table 2, we should add the same words to the pattern 2 for 
>the same reason.

Yes, I guess so. But, in pattern 2 the UAC will terminate the session
(send ACK + BYE), but in pattern 5 the UAS terminates the session by
sending an error response to the INVITE.

>If the UAC receives a reliable provisional response with an answer, it
MAY generate an
>I think that if the first reliable response does not contain 
>an answer and the second one contains an answer, the PRACK to 
>the second reliable response can still contain a new offer.

I will double check it.

Regards,

Christer