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

From: "Seth, Rajeev" <[email-masked]>
Date: Thu, 18 Oct 2007 16:46:35 +0530

Hi Takuya,

I propose a section in the draft with the following text

Section 4.4

RFC 3264[3] specifies that 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. 
If a UA generates an answer to the offer received with c=0.0.0.0, the
direction attribute of the accepted media stream in the answer must be
based on direction attribute of the offered stream and rules specified
in RFC 3264 to form the a-line in the answer. c=0.0.0.0 has no special
meaning for the direction attribute of the accepted stream in the
answer.

Thanks,

Rajeev

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

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

> 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

--------
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: Takuya Sawada <[email-masked]>
Date: Fri, 19 Oct 2007 21:37:51 +0900

Hi Rajeev,

Thank you for the proposal.

If no one disagree, I will add it.
Is "Behavior on receiving SDP with c=0.0.0.0" OK for the title of the section?

Regards,
Takuya

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

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 19 Oct 2007 08:57:14 -0400

That text seemed more or less ok, but there have been so many 
suggestions for changes that I have lost track of what the current state 
of the document must be. I expect that after all these patches there may 
be need of some editing to make it all coherent.

	Thanks,
	Paul