Hi Daren,
I hear you, dinosaurs are .... just dinosaurs :)
Now, the 5xx indicates a error on the upper server level, but IMHO the
RFC does not enforce anything in terms of behavior, or what how to react
on it. The best practice here is to consider the replying entity
(server) as faulty and to skip it. So do not try it again on the spot.
In your case, moving to another carrier (or other server of the same
carrier) may be the right thing to do. But do not retry to the same
server for the same call.
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
https://www.opensips-solutions.com
https://www.siphub.com
On 10/23/23 6:34 PM, Daren FERREIRA wrote:
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 <[email protected]> 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
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
