El Viernes, 28 de Noviembre de 2008, Maxim Sobolev escribió:
> Victor Pascual Ávila wrote:
> > (auto-reply)
> >
> > On Fri, Nov 28, 2008 at 5:21 PM, Victor Pascual Ávila
> >
> > <[EMAIL PROTECTED]> wrote:
> >> On Fri, Nov 28, 2008 at 4:28 PM, Iñaki Baz Castillo <[EMAIL PROTECTED]>
wrote:
> >>> El Viernes, 28 de Noviembre de 2008, Klaus Darilion escribió:
> >>>> Hi Inaki!
> >>>>
> >>>> Where is it defined that the SDP must not be changed during a
> >>>> transaction (of course it may be changed during a dialog (reINVITE))?
> >>>
> >>> I can sure 1000% that an SDP cannot be changed during the same early
> >>> dialog. This is, provional responses containing the same To tag cannot
> >>> contain different SDP. If so, the UAC MUST discard them.
> >>
> >> I wouldn't say 1000%, just 999 :-)
> >> AFAIU they must contain the same SDP but I think there's no normative
> >> behavior for cases when the SDP is different.
> >>
> >>> This is: after UAC has received an SDP in an early-dialog (specific
> >>> To_tag) it dones't need to parse future SDP in the same early-dialog.
> >>> In fact, if the UAC receives a 183 (To_tag=AAA) with an SDP and later
> >>> receives a 200 OK with same To_tag=AAA and different SDP, UAC MUST
> >>> ignore this second SDP.
> >>
> >> Why should the former be of higher preference than the latter?
> >>
> >>> It appears in RFC 3261 sure, but don't remember now where exactly. I'll
> >>> look for it, but I also remember this subject in SIP-implementors.
> >>
> >> Any pointer would be appreciated-- specially about the "UAC MUST
> >> ignore this second SDP" statement.
> >
> > http://tools.ietf.org/html/rfc3261#section-13.2.1 - Second rule for
> > the initial INVITE transaction
> >
> > "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."
> >
> > I think Iñaki is right here-- once again.
>
> The full text reads:
>
> 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.
>
> To me it looks like SDP in provisional response cannot be considered as
> the "final answer" and consequently, the answer in 200 OK may differ
> from anything UAS seen in provisional responses.
I think it says clearly:
"That same exact answer MAY also be placed in any **provisional** responses
sent prior to the answer."
> I think this paragraph
> is specifically for the cases when call forks and UAS receives multiple
> 200 OK, in which case it should take the first one and end the rest with
> BYE.
Sincerelly I don't think the above text says that:
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.
It just talks about SDP, not about whole 200 responses.
Anyway, it's clearly specified in same section (13.2.1), at the end:
Concretely, the above rules specify two exchanges for UAs compliant
to this specification alone - 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 [...]
--
Iñaki Baz Castillo
_______________________________________________
Semsdev mailing list
Semsdev@lists.iptel.org
http://lists.iptel.org/mailman/listinfo/semsdev
