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

From: "Seth, Rajeev" <[email-masked]>
Date: Mon, 1 Oct 2007 15:18:46 +0530

Comments on draft-ietf-sipping-sip-offeranswer-03
Best Regards,

Rajeev Seth/Ganesh Natarajan
Sonus Networks

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

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?

3.	Section 4.3  :
   "If UA1 is first to go off hold it will then send an offer with
"a=sendrecv". The UA2 will respond with its desired state of
"a=sendonly" because that is a permitted response"

Comment :- Here if the UA2 also wants to initiate it's on unhold on
receiving the offer with "a=sendrecv" it can send "a= sendrecv" in the
answer. It is not coming out clearly from the text and the text is
looking restrictive. Could we make it more specific

4. AS per 3264   
"RFC 2543 [10] specified that placing a user on hold was accomplished by
setting the connection address to 0.0.0.0. However, it can be useful in
an    
Initial offer when the offerer knows it wants to use a particular set of
media streams and formats, but doesn't know the addresses and ports at
the time of the offer"

Comment :- RFC 3264 does not specify that the answer should have
"a=sendrecv" media line. So if this SDP is used in an initial INVITE, UA
respond with "a= inactive", treating the initial SDP as an hold SDP,
the call does not go through well. Being an open point, can we try to
address this issue in the draft.

========================================================================
====
-----Original Message-----
From: Mary Barnes [mailto:[email-masked]] 
Sent: Thursday, August 30, 2007 8:58 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; Gonzalo Camarillo
Subject: [Sipping] WGLC: draft-ietf-sipping-sip-offeranswer-03.txt

Hi all,

This is to announce Working Group Last Call on the following document:
http://www.ietf.org/internet-drafts/draft-ietf-sipping-sip-offeranswer-0
3.txt

We have one volunteer for this document (Byron Campen), but would like
at least 2 additional volunteers to commit to reviewing the document.
If interested, please let me know. 

As always, anyone else that gets a chance to review should also send
their feedback to the authors and copy the SIPPING mailing list. 

This WGLC will end on September 30, 2007 (one month to ensure sufficient
feedback from implementers). 

Thanks,
Mary
SIPPING WG co-chair

_______________________________________________
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

_______________________________________________
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: "Seth, Rajeev" <[email-masked]>
Date: Fri, 12 Oct 2007 12:51:38 +0530

Hi Sawada,Christer

Comments inline.

Thanks,

Rajeev

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]] 
Sent: Thursday, October 11, 2007 9:01 PM
To: Takuya Sawada; Seth, Rajeev
Cc: [email-masked]; [email-masked]; [email-masked];
Gonzalo Camarillo
Subject: VS: [Sipping] WGLC: draft-ietf-sipping-sip-offeranswer-03.txt

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.

>>[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 >>P in subsequent responses, etc etc etc.

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

[Rajeev]
I can see this point clearly now.

As the UAC will *ignore* the SDP bodies in 1xx/200 (F6 and F9), It is
implied and understood that it would send the PRACK(F7) and ACK(F10)
without the SDP, if the SDP is received in F6 and F9.

So non-compliant UAS would have to infer the behavior that from the text
and handle not receiving the SDP answers in the PRACK/ACK, which I agree
should not be defined in this draft.

I am fine in not adding the note.
[Rajeev]

 [Rajeev]

Regards,

Christer

---

From: Takuya Sawada <[email-masked]>
Date: Mon, 15 Oct 2007 23:04:48 +0900

Hi Rajeev,

Then now we will not add the text to the note.
Thanks.

Regards,
Takuya

> I am fine in not adding the note.

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

---

From: Takuya Sawada <[email-masked]>
Date: Tue, 16 Oct 2007 14:02:32 +0900

Hi,

Honestly speaking, if it is just a clarification and nothing
more than what the document currently says, I am not against but
reluctant to make a substantial change now.

Well, if someone can show a good change example which all can agree
with, then I will be happy to incorporate it into the draft.

Regards,
Takuya

> 
> Hi,
>  
> If we think something still needs to be added to the document, I think we should 
added - even if it requires some reorganization.
>  
> Otherwise we will at some point have to write another document which clarifies 
this document :)
> Christer
________________________________

Seth,

I believe we all agree on the appropriate behaviors around hold and
resume, and this is no change from what I intended the section to mean.

The only real question is what the document should *say* about it.

Since the questions have been raised I guess that implies that the
document should say something more to be clear. I think to do that it
might be best to reorganize section 4.3 - break it down into different
techniques to indicate hold and resume (the a= way and the c=0 way),
when they should be used, and how they (don't) interact with one another.

That will be a substantial change. How do people think about doing that now?

        Thanks,
        Paul

Seth, Rajeev wrote:

> Hi Paul,
> Please find inline.
> From: Paul Kyzivat [mailto:pkyzivat at cisco.com]
> Sent: Wednesday, October 10, 2007 5:43 AM
> To: Takuya Sawada
> Cc: Seth, Rajeev; mary.barnes at nortel.com;
> Gonzalo.Camarillo at ericsson.com; bnataraju at sonusnet.com; sipping at ietf.org
> Subject: Re: [Sipping] WGLC: draft-ietf-sipping-sip-offeranswer-03.txt
>
>
> Takuya Sawada wrote:
>
>>> 3. Section 4.3  :
>> How about adding the following sentence in the end of this paragraph?
>>
>> ---
>> In the same case, if UA2 also wants to reset its local hold on
> receiving
>> the offer with "a=sendrecv", it can send "a= sendrecv" in the answer.
>> ---
>
>>> I'm way behind in my mail and reading it out of order.
>
>>> I agree the above is a *possibility*, and in that case the behavior is
>
>>> appropriate. But it is a very slim possibility. The decision to go off
>
>>> hold is driven by local actions and so its timing is uncoordinated in
>>> UA1 and UA2. The likelihood of them happening in such a way that the
>>> offer arrives just as UA2 realizes it wants to make the same change is
>
>>> very unlikely. And its even less likely that UA2 would realize this.
> If
>>> it were to happen I think it is more likely that both sides will have
>>> sent offers, and a glare situation will then arise. The winner of the
>>> glare will then make the offer, and the loser can detect that it also
>>> wants to be off hold and so respond in this way. Then, when UA2 gets
> its
>>> turn to retry its offer, it must reevaluate what it was trying to do.
> It
>>> should then realize that there is no longer any need for it to send
> its
>>> offer.
>
>>> I already suggested a modified wording to Takuya:
>
>>> "In the same case, when UA2 receives the offer with "a=sendrecv", if
> it
>>> has decided it wants to reset its local hold but has not yet signaled
>>> the intent, it may send "a=sendrecv" in the answer."
>
>>> 4. AS per 3264  
>> I am sorry but maybe I do not understand the issue here.
>> Could you please elaborate it?
>
>>> I'm not sure either.
>
>>> The 0.0.0.0 technique was used in 2543, before the advent of
> sendonly...
>
>>> To the extent that this technique is being used for backward
>>> compatibility there is clearly no point in using the a-line.
>
>>> However, as Rajeev says, there are other reasons to use 0.0.0.0 even
>>> when everybody is 3261 conformant.
>
>>> Though not specified, this technique can also used by the B2B UA which
> can >>not send an INVITE without an offer but wants to know the codecs
> supported >>by UAS and thus sends an offer with c=0.0.0.0 and gets the
> answer.
>
>>> It is important to remember that neither of these techniques *mean*
>>> LD. They are ways to establish a communication state that may be
>>> lpful when on hold.
>
>>> t to answer your point about addressing this "issue", the behavior you
>
>>> describe is already addressed by section 4.1. Presumably in your case
>>> the answerer *desires* sendrecv, so it should answer as close to that
> as
>>> possible. Since there is no a=sendonly/recvonly/inactive in the offer,
>
>>> the default is a=sendrecv. That means the answer is not constrained.
>>> There is no reason for a=inactive unless that is what it desires.
>
>>> Do we need to state it any more strongly? Do you see anyplace that
>>> c=0.0.0.0 means the recipient should assume it also received an
>>> a=inactive?
>
> The "a=inactive" could be send by the agent due to *reading into* the
> c=0.0.0.0.
>
> Section 8.4 (RFC 3264) says
>    An agent MUST be capable of receiving SDP with a
>    connection address of 0.0.0.0, in which case it means that neither
>    RTP nor RTCP should be sent to the peer.
>
> Now *neither RTP nor RTCP should be sent to the peer* could be
> understood by some agents as akin to "inactive/sendonly" state of the
> offered media stream and the agent sends the answer with the
> "a=inactive" or "a=recvonly" media stream.
>
> I agree with Christer that we should keep the c line separate while
> generating the directionality of media stream in the answer but it is
> not specified clearly in RFC 3264.
>
>       Paul
>

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sip at ietf.org for new developments of core SIP

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sip at ietf.org for new developments of core SIP

--------
Takuya Sawada
KDDI Corporation (KDDI)