Andrea - see inline.
Andrea Rizzi wrote:
> Trying to properly manage interworking with PSTN with early media, and
> pre-connect free call announcements, I would ask if someone can clarify my
> doubts.
>
>
>
> According to RFC3261:
>
> 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.
>
>
>
> Considering this RFC only, and assuming the SDP offer is within the INVITE
> request, it is not clear if the SDP answer MUST be present in the 2xx
> response also in the case the SDP answer has already been provided to the
> UAC in a provisional response (such as a 183 Session Progress).
>
> In case it
> is mandatory, it appears the UAC must ignore the "duplicated" answers,
> behaving as they are missing.
>
> When using PRACK, it is not clear if provisional responses may be considered
> as a "reliable non-failure message" in the sense reported above. If so, it
> appears the UAS would no longer be needed to put the "duplicated" answer in
> the 2xx response. Is my assumption correct?
If the provisional containing the answer was unreliable then the answer
must also be in the 2xx. If the provisional containing the answer was
reliable, then the answer need not be repeated in the 2xx, but it may
be. If it is, it should be ignored by the UAC.
So your assumption is correct.
> Finally, things get more complex when media changes before 200 OK by using
> the UPDATE method. Consider the following sequence:
>
>
>
> INVITE (SDP Offer A) ->
>
> <- 183 Session progress (SDP Answer A)
>
> PRACK ->
>
> <- 200 PRACK
>
> <- UPDATE (SDP Offer B)
>
> 200 UPDATE (SDP Answer B) ->
>
> <- 200 INVITE (SDP ???)
>
> -> ACK (SDP ???)
>
> This is a quite common scenario to manage free call announcements before
> 3PCC-based redirection to the final destination. In this case, I'd like to
> understand if the SDP in the 200 response to the INVITE is mandatory or not,
> and if it is, how the SDP has to be filled and how the UAC has to consider
> this new SDP (a new offer, or ignore it as RFC3261 says for the basic
> scenario?
The SDP is not mandatory in the 200 in this case, and in fact would be
quite confusing if present. It seems that if it is present it must be
Answer A even though that is not the "current" answer.
You should read draft-sawada-sipping-sip-offeranswer. It discusses all
of this.
Thanks,
Paul
> Regards
>
>
>
> Andrea
>
>
>
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
