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

From: "Seth, Rajeev" <[email-masked]>
Date: Tue, 16 Oct 2007 11:18:53 +0530

Hi Sawada,

This issue does not relate to the hold and resume section. RFC 3264
suggest the use of the SDP offer with the c=0.0.0.0 in the initial offer
but NOT for the hold and resume (Section 8.4). In a way the draft does
not say anything about this.

We could add a new section to clarify the behavior of the UAS on
receiving an initial INVITE with c=0.0.0.0.  I could try to send you
some text, if you think that a section can be added at this point of
time in the draft.

Thanks,

Rajeev

-----Original Message-----
From: Takuya Sawada [mailto:[email-masked]] 
Sent: Tuesday, October 16, 2007 10:33 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: Re: VS: [Sipping] WGLC:
draft-ietf-sipping-sip-offeranswer-03.txt

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 :)
> Regards,
> 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.
>
> Thanks,
>
> Rajeev
>
> -----Original Message-----
> 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  :
>>>   "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 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)
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

_______________________________________________
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: Tue, 16 Oct 2007 15:39:24 +0900

Hi Rajeev,

We have already had a lot of text to be added or to be modified
in the next version. I think it is no problem to add on more text.
I can wait for soem text from you.
Anyway I think we need updated draft and at least one more iteration.

Regards,
Takuya

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