Thanks everybody for the responses! I will get back to you when I get a clear understanding of the involved mechanism.
Best regards, Andrew On 10/05/2017 03:21 AM, Dale R. Worley wrote: > 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
