[prev in list] [next in list] [prev in thread] [next in thread] 

List:       sip-implementors
Subject:    Re: [Sip-implementors] SDP (answer_1)
From:       "Arnab Biswas" <arnabbiswas1 () gmail ! com>
Date:       2008-02-20 15:59:58
Message-ID: 18aed6e70802200747j199a164fv7e26a9373acd1d7f () mail ! gmail ! com
[Download RAW message or body]

Geeta,

I feel you are missing one thing. Once the initial offer answer has been
missing one thing. Once the initial offer answer has been done (say through
INVITE - 1XX rel) the 2XX response for the INVITE can not carry a new offer.
If an SDP is present there under such situation that should be ignored.

On the other side, ACK can carry an answer only when 200 OK for the offer
carries an offer. That is possible only when there is no initial offer
answer exchange by INV/1XX-rel/PRACK etc.

May be that's what Brett wants to mean.

For more clarity please check the following draft:

http://www.ietf.org/internet-drafts/draft-ietf-sipping-sip-offeranswer-05.txt

Thanks,
Arnab Biswas

On Wed, Feb 20, 2008 at 3:36 PM, geeta soragavi <sgeeta28@yahoo.co.in>
wrote:

> Hi,
>
>  Yes you are right as per rfc 3261 section 13.2.1.
>  Its as follows ,
>
>    -the offer is in the INVITE, and the answer in the
> 2xx (and possibly in a 1xx as well, with the same
> value), or the offer is in the 2xx, and the answer is
> in the ACK.All user agents that support INVITE MUST
> support these two exchanges.
>
> Thanks Brett for correcting.
>
> Regards,
> Geetha
>
>
> --- Brett Tate <brett@broadsoft.com> wrote:
>
> > > Assume if PRACK is sent in this scnario ,
> > > the offer/answer will be different, as SDP body
> > > in the PRACK is optional , and if a SDP body
> > > is sent in the PRACK then the immediate
> > > response of that PRACK must contain an answer.
> >
> > There is no difference within my answer.  Per
> > rfc3261, the SDP within
> > the INVITE 2xx must be ignored; it is not an offer.
> >
> > Concerning my earlier comment "assuming PRACK used
> > but not shown", I was
> > trying to indicate that SDPs within 18x, UPDATE, and
> > UPDATE 2xx are not
> > offers and answers (or trigger UPDATE failure
> > responses).  This is
> > because of the rfc3261 requirement that 18x with SDP
> > is not an "answer"
> > unless it is sent reliably.
> >
> >
> > > For Eg:
> > >
> > > INVITE (Offer1)
> > > 18x    (Answer1)
> > > PRACK  (Offer)
> > > 2xx PRACK (Answer)
> > > UPDATE (Offer2)
> > > 2xx UPDATE (Answer2)
> > > 2xx INVITE (Offer3) /* This will be a new offer
> > again */
> > > ACK INVITE (Answer3)
> > >
> > > Thanks and Regards,
> > > Geetha
> > > --- Brett Tate <brett@broadsoft.com> wrote:
> > >
> > > > >   To my understanding ,
> > > > >         In the scenario mentioned by you.
> > > > >    INVITE (Offer1)
> > > > >    18x    (Answer1)
> > > > >    UPDATE (Offer2)
> > > > >    2xx UPDATE (Answer2)
> > > > >    2xx INVITE (Offer3) /* This will be a new
> > offer
> > > > again */
> > > > >    ACK INVITE (Answer3)
> > > > >
> > > > > So an answer for offer3 needs to be sent in
> > ACK.
> > > >
> > > > Within your example (assuming PRACK used but not
> > shown), the SDP
> > > > within INVITE 2xx must be ignored.  Thus it is
> > not an
> > > offer; and there
> > > > would not be an answer within the ACK.
> >
> > _______________________________________________
> > Sip-implementors mailing list
> > Sip-implementors@lists.cs.columbia.edu
> >
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
> >
>
>
>
>      DELETE button is history. Unlimited mail storage is just a click
> away. Go to https://edit.india.yahoo.com/config/eval_register
> _______________________________________________
>  Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>

[prev in list] [next in list] [prev in thread] [next in thread]