Re: [Sip-implementors] rules for From-tag generation in forking B2BUA

[Andrew Pogrebennyk]

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

Re: [Sip-implementors] rules for From-tag generation in forking B2BUA

[Dale R. Worley]

Andrew Pogrebennyk  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

Re: [Sip-implementors] rules for From-tag generation in forking B2BUA

[M. Ranganathan]

B2BUAs would generally create a single outbound dialog for each arm of the
fork - hence are under no obligation to re-use the incoming From tag.
Indeed, I would suspect the most usual (best?) practice would be to have
distinct From tags for each leg of the outbound Fork.

On the other hand a Forking proxy would indeed use the SAME From tag for
each leg.

On Wed, Oct 4, 2017 at 4:20 PM, Andrew Pogrebennyk  wrote:

> Hi,
> 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?
>
> Thanks,
> Andrew
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>



-- 
M. Ranganathan
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] rules for From-tag generation in forking B2BUA

[Paul Kyzivat]

On 10/4/17 4:20 PM, Andrew Pogrebennyk wrote:

Hi,
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?


ISTM that if the B2BUA is intending to act mostly like a forking proxy, 
then it would make the most sense for it to generate a single new 
from-tag for itself corresponding 1:1 with the incoming from-tag on its 
UAS side and then use that for all outgoing forks. But that is 
technically a violation of UAC behavior, so I can see why some 
implementations might not do this.


Thanks,
Paul
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

[Sip-implementors] rules for From-tag generation in forking B2BUA

[Andrew Pogrebennyk]

Hi,
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?

Thanks,
Andrew
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors