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

From: "Seth, Rajeev" <[email-masked]>
Date: Thu, 11 Oct 2007 18:39:00 +0530

Hi Paul,

Please find inline.

Thanks,

Rajeev

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Wednesday, October 10, 2007 5:43 AM
To: Takuya Sawada
Cc: Seth, Rajeev; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Subject: Re: [Sipping] WGLC: draft-ietf-sipping-sip-offeranswer-03.txt

Takuya Sawada wrote:

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

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

>>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 [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 11 Oct 2007 09:25:01 -0400

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

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 11 Oct 2007 17:19:01 +0200

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 :)
 
Regards,
 
Christer

________________________________

Lähettäjä: Paul Kyzivat [mailto:[email-masked]]
Lähetetty: to 11.10.2007 15:25
Vastaanottaja: Seth, Rajeev
Kopio: Takuya Sawada; [email-masked]; [email-masked]; [email-masked]; Gonzalo Camarillo
Aihe: Re: [Sipping] WGLC: draft-ietf-sipping-sip-offeranswer-03.txt

Seth,

        Thanks,
        Paul