Subject: Re: [Sipping] WGLC: draft-ietf-sipping-sip-offeranswer-03.txt

From: Takuya Sawada <[email-masked]>
Date: Thu, 11 Oct 2007 22:43:45 +0900

Hi,
> 
> Hi, 
> 
> >>==1. Section 2.1.2 (Invite without SDP)
> >> 
> >>Comment : If the Invite was without an offer, UAS sends the 1xx-rel 
> >>with offer1 and UAC respond with PRACK with answer1. Now if the 
> >>UAS sends the same offer (offer1) in the next 1xx-rel [ As it is a "should" 
> >>condition and UAC behavior is recommended "to ignore" on receiving the
> 
> >>SDP ] UAC will ignore it, but it is no clear if the UAC need to repeat
> >>the SDP answer ( answer1) in the PRACK and may be a problem for the 
> >>UAS, which is expecting the answer SDP in the PRACK. Could  some 
> >>recommendations for the UAC be provided? Similarly if the UAS repeats the offer1 is 200 OK, we 
> >>should specify if there is a need for the UAC to repeat the answer1 in ACK.
> >> 
> >First, I would like to put this paragraph to a 'NOTE'.
> >And as you pointed out, make it clear that UAC is recommended 
> >to repeat the same answer. 
> > 
> >How about the following?
> >---
> >NOTE: UAS should not include SDP in the responses F6 and F9. 
> >However, UAC should prepare to receive the same SDP bodies in 
> >F6 and/or F9 for the case that the peer does not conform to 
> >the recommended implementation. 
> >In this case UAC is recommended to repeat the same SDP in 
> >PRACK and/or ACK.
> 
> [Christer] I don't see why one would need to repeat the answer in
> subsequent PRACKs. Instead I think we could say that the receiver should
> be able to receive "repeated" answers in subsequent PRACKs.
> 
Recommended UAS behavior is not to send repeated SDP in the subsequent
reliable responses. This is the question how UAC react to the non-recommended
UAS behavior. We are not sure what the UAS actually expects.
Here, it is pointed that UAS will expect the same SDP is sent from
UAC in PRACKs. And I tend to agree.

Well, this seems to be problematic.

Of course, this may be one of the strong reasons that UAS should not
include SDP in the subsequent responses.

> >>2. Section 1.1 : 
> >> 
> >>Comment :- Should we also incorporate the recommendation for the UAC, 
> >>which sends out an INVITE without SDP and receives the first 
> >>non-failure reliable response without an Offer due to the UAS not 
> >>conforming to the draft. Does the UAC clear the call or send a PRACK 
> >>and wait for the offer in subsequent reliable responses?
> >> 
> >Well, it is the question how much we should care about the 
> >behaviour not conforming to the RFCs. We can add the sentence 
> >below in 2.1.2.
> > 
> > ---
> >NOTE: UAC, which sends out an INVITE without SDP, may receive 
> >the first non-failure reliable response without an offer, due 
> >to the UAS not conforming to the RFCs. In this case, instead 
> >of just giving up the offer/answer, UAC can send a PRACK and 
> >wait for the offer in subsequent reliable responses, if possible.
> > ---
> > 
> >Or we don't need to say here about such a non-comforming UAS?
> 
> [Christer] I don't mind adding the note, but isn't this case already
> mentioned in chapter 5.3?
> 
Yes, you are right, I think. Then, I prefer not adding the note here.

> Regards,
> Christer
Regards,
Takuya
> 
> 
> _______________________________________________
> 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" <[email-masked]>
Date: Thu, 11 Oct 2007 17:30:38 +0200

Hi,
 
>include SDP in the subsequent responses.

[Christer] The purpose of this document is not to "fix" buggy implementations. No matter what we recommend, a UAC MUST be able to receive SDP in subsequent responses, and it MUST be able to NOT receive SDP in subsequent responses, etc etc etc.

IF we are going to recommend something here, we should base it on experience from the field. Personally I have never seen SDPs sent in PRACK being "repeated" in subsequent PRACKs. But, I have very often seen SDPs sent in a reliable 18x being sent in subsequent 18x/2xx. Maybe this is something Robert can do some studies on at the next SIPit?

Regards,

Christer