However, my reading of the early media RFC (3960)'s discussion of forking is that it's generally just not considered a good idea to do 183+SDP with forking. Am I wrong?
Alex Balashov wrote: > > Iñaki, > > It would seem to me that it is incumbent upon the proxy to insulate the > B2BUA from the consequences of parallel forking by not creating such a > condition, since forking behaviour is a feature that is a defined and > specified as a characteristic of proxies rather than B2BUAs. The RFC > does not speak to "forking B2BUAs." :-) > > In other words, it seems to me that the best solution from an abstract > standpoint would be to say that the proxy shouldn't be forwarding the > second 183 and should CANCEL that branch on its side, since the early > state is also a kind of "answer." That way the B2BUA gets only one > 183+SDP. > > The trouble is that this idea is not supported by the RFC because a 183 > is still a provisional response, not a final one, and the governing rule > regarding provisional responses is that they must be forwarded to the > originator. > > RFC 3261 says nothing about a special status of a 183. > > I think one of the things Paul Kyzivat said is probably the most > reasonable conclusion: "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." This sounds like something that should > be up to the proxy - same as 200 OK - but is expressly and very much not > up to the proxy per the RFC's model. > > 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. >> >> > > -- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599 _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
