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

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Sat, 21 Jul 2007 20:50:53 +0200

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".

ISSUE 2:
-------------

I think chapter 5.1 should say WHICH rules are broken if the 200 OK is
sent without a SDP.

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.

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).

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.

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

---

From: Takuya Sawada <[email-masked]>
Date: Thu, 26 Jul 2007 20:01:19 +0900

Hi, Christer,

> >>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?

How do you think?
> >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."

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.
> 
> >>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?

> 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."?
> >>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?
> 
> 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.
> 
Strictly speaking, when INVITE is reINVITE within the dialog,
UA should terminate the dialog by sending BYE.

Anyway, we can add "OR termintion of dialog" in both pattern 2 and
pattern 5
> >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.
> 
> Regards,
> 
> Christer
> 
--------
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]