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

From: Takuya Sawada <[email-masked]>
Date: Tue, 9 Oct 2007 13:30:44 +0900

Hi Rajeev and Ganesh,

Thank you for the review and comments.
Responses inline
> 
> 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.
> 
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.
---

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

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

> 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.
> 
I am sorry but maybe I do not understand the issue here.
Could you please elaborate it?

Regards,
Takuya

> ========================================================================
> -----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: Paul Kyzivat <[email-masked]>
Date: Tue, 09 Oct 2007 20:12:55 -0400

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

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

It is important to remember that neither of these techniques *mean* 
HOLD. They are ways to establish a communication state that may be 
helpful when on hold.

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

	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 10 Oct 2007 02:40:04 +0200

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

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

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

[Christer] I don't mind adding the note, but isn't this case already
mentioned in chapter 5.3?

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 10 Oct 2007 02:44:25 +0200

Hi, 

>>>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"
>>>
>>>"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.
>>>
>However, as Rajeev says, there are other reasons to use 
>0.0.0.0 even when everybody is 3261 conformant.
> 
>It is important to remember that neither of these techniques 
>*mean* HOLD. They are ways to establish a communication state 
>that may be helpful when on hold.
> 
>But 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. 
>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?

[Christer] I think we should keep the c- line separate from the
direction attribute. We don't assume a=inactive if we set the m- line
port to zero either, so...

Regards,

Christer