[OpenSIPS-Users] Dispatcher ds_next_dst, Call-ID/Tags uniqueness and RFC

[Bogdan-Andrei Iancu]

HI Daren,

In SIP there are transactional and dialog layers. Indeed, from dialog 
level perspective, the Call-ID and the To/FROM tags are uniquely 
identifying the dialog. But before having a dialog, you need to have a 
transaction for an initial request creating the dialog. This is the 
INVITE transaction (when comes to calls).
And at the transactional layer, the uniqueness is given by the 
VIA-branch parameter (see the RFC when comes to transaction matching).

Bottom line, during SIP forking, OpenSIPS creates different VIA-branches 
for each branch, so they further (on the next hop) create different 
transactions. So there should be no conflict at all - a new incoming 
branch will create a new transaction (initial one), creating a new dialog.

Nevertheless, there is a lot of confusion in this grey area when comes 
to the SIP stack. To try to address this you may try to change the cseq 
number for each branch, so they will have different values and not 
confuse the next hop, like this 
https://opensips.org/html/docs/modules/3.5.x/uac.html#func_uac_inc_cseq

Best regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   https://www.opensips-solutions.com
   https://www.siphub.com

On 10/10/23 5:19 PM, Daren FERREIRA wrote:
> Hello,
>
> I successfully implemented OpenSIPS with dispatcher and failover routes but an upstream provider complains about duplicates requests they receive.
>
> After investigations, when a gateway reports an error, like 402, the failure route is triggered and ds_next_dst is used in order to find another gateway and try it.
>
> Doing this work as expected, but, for the provider, because none of Call-ID/To Tag/From Tag change, they consider the requests as dupes.
>
> My reading of RFC3261 is that it is compliant as the call is always the same and so, there is no need to change anything in none of these parameters.
>
> RFC says the cases (401, 413, 415, 416 and 420) where these 3 parameters MUST not change, but nothing tells they have to change in any other 4XX cases.
>
> I made many searches on this subject, nothing helped me on this issue.
>
> I made searches in OpenSIPS code to find what can eventually trigger changes on any of these parameters, without success.
>
> I found some other implementations of failover routes:
> - using AVP containing several gateways, and calls to append_branch() and serialize_branches()
> - carrier route module request append_branch
> but according to my readings, dispatcher already internally implements append_branch and other requested calls and so, they shouldn’t be called manually in script
>
>
> What are your thinkings about the RFC rules about failover requests and Call-ID/To tag/From tag uniqueness requirement?
>
> What would you do in order requests not to be identical when trying upstream routes with dispatcher module?
>
>
> Thank you for your comments.
>
>
> Regards
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users