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

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Mon, 13 Aug 2007 12:12:01 +0200

Hi Takuya,

I appologize that it took a while to reply (I went for vacation after
IETF).

Comments inline.
  
>>>>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.
>> 
>>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.
>> 
>Well, it may be useful.
>One big issue to loose it up is the backward compatibility.
>We can document it, but I feel it is unrealistic to change 
>the rule if there is clear and strong need to do it.
>I feel it is really hard even if there is a need.
>I agree that it is important to record the discussion in the draft.
>However, if it is unrealistic, should we still document it as 
>an option?

I think we should. We don't know how unrealistic a change is before we
see how people have implemented it :)

And, maybe we will never change the rule, but I still think it is
important as one issue that has been discussed.

>>>>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.
>> 
>>I was more thinking about refering to text in RFC3262.
>> 
>Maybe, we can refer to the section 5 of RFC 3262:
>"If the UAS receives a PRACK with an offer, it MUST place  
>the answer in the 2xx to the PRACK."

Yes.
 
>If we refer to the exact text in RFCs, I think we should do 
>it in the section 1.1. But I am afraid that to refer to the 
>original text for every rules in the draft will reduce the 
>readability.
>Actually, I do not want do it now.

I don't think we need to copy the text, we can simply say something like
"see section 5 of RFC3262", or something...

>>>>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.
>> 
>>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.
>> 
>I think to keep o- line unchange is normal behaiviour when 
>the answerer does not need to change its session parameters 
>in the answerer's side even it accepts the change in the 
>offerer's side.
> 
>Am I wrong?

You are right :) The version value should be decreased. We could also
document the possibility to e.g. use a zero value to reject.

>>A third alternative, which has also been discussed and should be 
>>documented, is to not allow SDP in PRACK at all.
>> 
>Yes, we discussed it.
>I think that some call sequence in IMS uses SDP in PRACK and 
>requires it for efficiency. So it is difficult to disallow 
>SDP in PRACK in general. If we can not say "it is not allowed 
>in any situation", then is it the same thing as to say "UA 
>should only use PRACK to send an offer when it has strong 
>reasons to assume the receiver will accept."?

Yes.

But, I still think we should document the option to not allow SDP in
PRACK at all. Of course, we MAY have the backward compability issue, so
it may not ever happen, but it is still one option which we have
discussed.

I think it is very important to document everything we have discussed

>>>>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.
>> 
>>I will double check it.

I double checked it, and could not find text saying that only the first
PRACK can contain an offer, so I guess I was wrong.

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