Yes, I agree with you. This has been discussed before on one of the lists.
You can forget all the B2BUA issues and just view the B2BUA as a UAS
interacting with A, and ask if what it is doing is valid, without regard
to why it is doing it.
In addition to the reasons you have given, if the SDP is simply being
copied from both legs, then the o-lines in the various SDPs won't have
the same session-id, and so will be invalid for that reason.
The B2BUA *could* try to make it right by using PRACK or UPDATE to
initiate different offers for each SDP, but it would then have to
rewrite each SDP to be compatible with the rules for multiple offers and
answers. In general this won't be possible, and its a silly thing to do
in any case.
Its just broken. If the B2BUA wants to be "transparent" then it should
establish a separate early dialog with A corresponding to each early
dialog it has on the other side. If it wants to be less transparent, it
can just hold all the other offers until the call outcome is known and
then reinvite with the winner.
Thanks,
Paul
Iñaki Baz Castillo wrote:
> Hi, I'm reporting a common error in some transparent B2BUA I'm testing. The
> error is:
>
> - The B2BUA receives a request from leg_A and generates a request in leg_B.
>
> - leg_B arrives to a proxy that does parallel forking.
>
> - The B2BUA receives various provisional responses (183) with different
> To_tag
> due to parallel forking.
>
> - The B2BUA generates a 183 response in leg_A for each 183 in leg_B, but it
> uses an *unique and same* To_tag in both 183 responses in leg_A (but they
> have different SDP).
>
>
> I'm trying to demostrate that the above behaviour is incorrect since:
> - There are two different early-dialogs between B2BUA and leg_B.
> - There are just *one* early-dialog between caller (leg_A) and B2BUA (since
> all the replies from B2BUA in leg_A have the same To_tag).
> - The caller (UAC) will ignore any SDP after the first 183 containing a SDP,
> even if a 200 OK arrives with a different SDP (since the To_tag would be the
> same, so just the first SDP would be considered).
>
> I think it's clearly specified in RFC 3261 (well, not so clearly):
>
> -------------------------------------------------------
> 13.2.1 Creating the Initial INVITE
>
> 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.
>
> [...]
>
> 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 [...]
> -------------------------------------------------------
>
>
> Could you please help me by confirming, detailing and explaining it?
> Reall thanks a lot.
>
>
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
