prince.philip aricent.com wrote:
> Since in the UAC point of view the behaviour is defined
clearly, whats
> the issue?
> Does anybody see any use case for this additional
answer, from an UAS
> perspective?
From a practical perspective I think that there have been a
lot of
implementors that implemented what they *thought* the spec
said, but got
it wrong. Then others have done what they thought they had
to do to
interoperate.
So there may be some use for this added answer for
interoperation with
certain broken implementations. (But I speak hypothetically
- I don't
have a specific implementation to point to.)
But for those just trying to follow the specs there is no
use for this
added SDP. Nobody should be *using* it. If they are, they
need to change.
Paul
> Prince.
>
>
> -----"Christer Holmberg"
<christer.holmbergericsson.com> wrote: -----
>
> To: "Jonathan Rosenberg" <jdrosencisco.com>, "Paul Kyzivat"
> <pkyzivatcisco.com>
> From: "Christer Holmberg"
<christer.holmbergericsson.com>
> Date: 11/21/2007 12:33AM
> cc: "Sanjay Sinha (sanjsinh)"
<sanjsinhcisco.com>, sip List
> <sipietf.org>
> Subject: RE: [Sip] SIPit21: SDP in a 200OK when
using 100rel
>
> Hi,
>
> An implementation should keep offer/answer state
and simply discard
> the SDP in the 200 OK.
>
> I don't think that is complicated 
>
> Regards,
>
> Christer
>
> ________________________________
>
> From: Jonathan Rosenberg [mailto:jdrosencisco.com]
> Sent: Tue 20/11/2007 17:56
> To: Paul Kyzivat
> Cc: Sanjay Sinha (sanjsinh); sip List
> Subject: Re: [Sip] SIPit21: SDP in a 200OK when
using 100rel
>
>
>
> The intention was that, when reliable provisionals
are used, the answer
> would NOT appear in the 200 OK to the original
INVITE. The paragraph in
> RFC3261 is talking specifically about the case of
an unreliable
> provisional response.
>
> The drawback of sending the answer in the reliable
18x and then
> repeating it in the 200 OK, is what if they are not
the same. It gets
> really complicated if there are multiple O/A
exchanges in UPDATE/PRACK
> prior to the final 200 OK.
>
> -Jonathan R.
>
> Paul Kyzivat wrote:
> >
> >
> > Robert Sparks wrote:
> >> Yes, I did mean 200 INVITE.
> >>
> >> On Nov 19, 2007, at 3:22 PM, Sanjay Sinha
(sanjsinh) wrote:
> >>
> >>> It is not clear from the call flow if
the 200 OK is for PRACK
> or INVITE?
> >>>
> >>> I guess you meant 200 OK for Invite.
If that is the case, I
> think the
> >>> RFC is clear that the answer sdp is
optional in it and if it
> does have
> >>> an answer sdp, it MUST be idential to
answer in 18x.
> >>>
> >>
> >> Really? Point me to where you find this
please.
> >
> > Mostly in 3261 sec 13.2.1. It says:
> >
> > o If the initial offer is in an
INVITE, the answer MUST be
> in a
> > reliable non-failure message from
UAS back to UAC which is
> > correlated to that INVITE. For this
specification, that is
> > only the final 2xx response to that
INVITE. That same exact
> > answer MAY also be placed in any
provisional responses sent
> > prior to the answer. The UAC MUST
treat the first session
> > description it receives as the
answer, and MUST ignore any
> > session descriptions in subsequent
responses to the initial
> > INVITE.
> >
> > The first three sentences are the clearly
normative part. When
> combined
> > with RFC 3262 definition of reliable
provisionals, they say that the
> > reliable provisional contains the answer.
> >
> > The last sentence doesn't really say the UAS
may include sdp in
> > subsequent responses to the invite
transaction, but neither does
> it say
> > you can't. It does say the UAC should ignore
them if present, which
> > implies they can be present, but says nothing
about what value
> they must
> > have if they are present.
> >
> > AFAIK there is nothing that says the answer
may be repeated in
> the 200.
> > However it is seemingly done a lot, so one
had better beware.
> >
> > Paul
> >
> >>> But I think the
> >>> offer-answer draft has clarified it
further that it should not
> have any
> >>> answer sdp. This is probably harsh in
case of one offer-answer
> exchange,
> >>> but makes sense if there are multiple
early dialog offer-answer
> >>> exchanges in say Prack/200 OK or
using UPDATE.
> >
> >
> >
> >>> Sanjay
> >>>
> >>>> -----Original Message-----
> >>>> From: Robert Sparks
[mailto:rjsparksnostrum.com]
> >>>> Sent: Monday, November 19, 2007
4:14 PM
> >>>> To: sip List
> >>>> Subject: [Sip] SIPit21: SDP in a
200OK when using 100rel
> >>>>
> >>>> There was a lot of discussion and
disagreement at SIPit21
> >>>> about whether the following 200
OK is allowed (or should) have
> >>>> SDP in it:
> >>>>
> >>>> INVITE (offer)
> >>>> -------->
> >>>> 18x (with 100rel) (answer)
> >>>> <--------
> >>>> PRACK
> >>>> --------->
> >>>> 200 OK (can this carry SDP?)
> >>>> <---------
> >>>> ACK
> >>>> --------->
> >>>>
> >>>> I couldn't find anything
definitive in RFC form. Paul's
> >>>> offeranswer draft talks about
this I think.
> >>>>
> >>>> If I understand things, the right
answer here is that it's not
> >>>> supposed to carry any SDP and
that you should ignore it if it
> shows up.
> >>>>
> >>>> The question is, other than
waste, what can go wrong if it is
> there?
> >>>> When we end up with clear text
around the requirement, will it
> >>>> say SDP SHOULD NOT, or MUST NOT
appear?
> >>>>
> >>>> Or do I have this wrong?
> >>>>
> >>>> RjS
> >>>>
> >>>>
> >>>>
_______________________________________________
> >>>> Sip mailing list https://ww
w1.ietf.org/mailman/listinfo/sip
> >>>> This list is for NEW development
of the core SIP Protocol Use
> >>>> sip-implementorscs.columbia.edu for questions on current sip
> >>>> Use sippingietf.org for new
developments on the application
> of sip
> >>>>
> >>
> >>
> >>
> >>
_______________________________________________
> >> Sip mailing list https://ww
w1.ietf.org/mailman/listinfo/sip
> >> This list is for NEW development of the
core SIP Protocol
> >> Use sip-implementorscs.columbia.edu for questions on current sip
> >> Use sippingietf.org for new
developments on the application of sip
> >>
> >
> >
> >
_______________________________________________
> > Sip mailing list https://ww
w1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core
SIP Protocol
> > Use sip-implementorscs.columbia.edu for
questions on current sip
> > Use sippingietf.org for new
developments on the application of sip
> >
>
> --
> Jonathan D. Rosenberg, Ph.D. 499
Thornall St.
> Cisco Fellow
Edison, NJ 08837
> Cisco, Voice Technology Group
> jdrosencisco.com
> http://www.jdrosen.net
> <http://www.jdrosen.net/>http://www.jdrosen.net/>
> PHONE: (408) 902-3084
> http://www.cisco.com <ht
tp://www.cisco.com/>http://www.cisco.com/>
>
>
> _______________________________________________
> Sip mailing list https://ww
w1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP
Protocol
> Use sip-implementorscs.columbia.edu for
questions on current sip
> Use sippingietf.org for new developments on the
application of sip
>
>
>
>
> _______________________________________________
> Sip mailing list https://ww
w1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP
Protocol
> Use sip-implementorscs.columbia.edu for
questions on current sip
> Use sippingietf.org for new developments on the
application of sip
>
>
>
> *****Aricent-Restricted *****=
>
> "DISCLAIMER: This message is proprietary to
Aricent and is intended solely for the use of
> the individual to whom it is addressed. It may contain
privileged or confidential information and should not be
> circulated or used for any purpose other than for what
it is intended. If you have received this message in error,
> please notify the originator immediately. If you are
not the intended recipient, you are notified that you are
strictly
> prohibited from using, copying, altering, or disclosing
the contents of this message. Aricent accepts no
responsibility for
> loss or damage arising from the use of the information
transmitted by this email including damage from
virus."
>
_______________________________________________
Sip mailing list https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip
|