Andrew Pogrebennyk <apogreben...@sipwise.com> writes: > I understand that there is no normative document for a B2BUA but in > general as common sense dictates should the B2BUAs that generate > multiple outgoing requests on their UAC side for a single incoming > request due to parallel forking create unique From-tags or reuse the > same From tag in every request (INVITE)? I have concerns over a SBC > vendor that requires same From tag (else some overload prevention kicks > in) because it looks like re-using From-tag (but having different Via > branches of course) might trigger a loop detected response with some > endpoints as per https://tools.ietf.org/html/rfc3261#section-8.2.2.2 > What is the best practice here?
There is at least this consideration: The B2BUA can generate multiple outgoing *dialogs* from one incoming request, acting as a UAC generating multiple dialogs. In that case, each outgoing request, each dialog, has to have a unique Call-Id. Each dialog has to have its own from-tag, and taken collectively, the from tags have to be statistically random. In particular, you can't just use the same from-tag on each outgoing dialog. Alternatively, the B2BUA can (in principle) generate one outgoing dialog (with its unique Call-Id and its from-tag) and then (as UACs are allowed) immediately fork it to multiple destinations. So what you see on the wire is multiple outgoing requests with the same Call-Id, the same from-tag, and different Vias. In the second case, any UA downstream can recognize that if it receives requests coming from more than one of these forks, it can reject all but the first. But that shouldn't cause any problems in practice. So the only thing that shows up as a rule is that the B2BUA has to be consistent whether its outgoing requests are forks of one dialog, or separate dialogs; that is, if the Call-Ids are the same, the from-tags must be the same, and if the Call-Ids are different, the from-tags should be randomized. There is a third case, the B2BUA which is trying to pretend it is a proxy, or "quasi-proxy". But those always use the same Call-Id and from-tag on their outgoing requests as was present on the incoming request. Now it's possible that the downstream equipment you are referring to has some narrow rules that interact badly with one of these modes of operation. I suggest you get a clear description of the mechanism that is involved and report back about that. Then we might be able to clarify the choices. Dale _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
