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

[Daren FERREIRA]

Hello Bogdan,

Thank you for your clear reply.

I’m happy to see you and I have the same understanding of the RFC.

Since my previous message, I made a point with the upstream provider (Orange) and they consider since the transaction has failed, that’s another dialog and so, Call-ID « MUST » change (like if a transaction failure was a call failure).
I argued that a transaction failure was not a call failure, and, as the caller and callee have no idea / nothing to do with intermediate tries and failures, the call is the same and so Call-ID / To / From, have no reasons to change.
They don’t mind… they stay on their position.

As they don’t mind of branches tag that are RFC compliant in the perspective of uniqueness, I’m pretty sure they won’t mind of CSEQ.
They wan’t the Call-ID to change… and « that’s it ».

We didn’t succeed to agree on RFC contents and rules but we found a kind of « workaround », by stopping to make tries on 5XX.
That’s not really RFC compliant, as 5XX are not definitive failures and allows retries, but these days:
- if a failure happens on an operator gateway, there is very few luck it will succeed at another gateway from the same operator
- making multiple tries with the same operator on failure can lead to a snowball effect / amplification effect when network failures occur, and increase their consequences (already happened in the past)
so main French operators (and the French Telecom Federation) consider as a good practice to stop trying on 5XX replies (and BTW they also advise to rewrite 480 replies to 603 on high-load periods).

Anyway, thank you for your advices and your help.

Best regards


> Le 23 oct. 2023 à 16:29, Bogdan-Andrei Iancu <bogdan at opensips.org> a écrit :
> 
> 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
>