BYE is not send from Asterisk to another SIP address after sbc goes down

[benedito]

Hello. Im trying implement failover using pjsip to make calls hangup correctly when the main SBC goes down in the middle of the call. I’ve note that when the main SBC goes down in the middle of the call, Asterisk tries to send BYE messages to IP address where they receive INVITE, and do not peform failover to another SBC. Im using DNS A record in record-rout headers send by Kamailio to Asterisk, but the failover dont accour. Exists something to do in this particular case to force failover of new transactions of the same dialog to failover (some timers, DNS question, use of sip tcp, etc)?

Flow of the call (INVITE):
Microsip → Kamailio1 (10.0.0.38) → PBX(10.0.0.29)

When the “Kamailio1” goes down (BYE or some other new transaction message):
PBX(10.0.0.29) → Kamailio1(10.0.0.38) → Microsip

But what I need is (BYE or some other new transaction message):
PBX(10.0.0.29) → Kamailio2(10.0.0.37) → Microsip

[jcolp]

You’d need to show the actual SIP traffic, as that is what determines where the request is sent, as well as the PJSIP configuration.

[benedito]

My PJSIP configuration is in realtime.

pjsip.conf:

[global]
type = global
user_agent = pbx_voice

[transport-udp]
type = transport
protocol = udp
bind = 0.0.0.0:5080

PJSIP realtime (1.1.1.1 is just to hide real media server ip):

MySQL [voice]> select id,contact,max_contacts,remove_existing from ps_aors;
+-----+------------------+--------------+-----------------+
| id  | contact          | max_contacts | remove_existing |
+-----+------------------+--------------+-----------------+
| 104 | NULL             |            1 | yes             |
| sbc | sip:sbc-udp:5060 |            1 | yes             |
+-----+------------------+--------------+-----------------+

MySQL [voice]> select id,transport,aors,auth,rewrite_contact,from_user,media_address from ps_endpoints;
+-----+---------------+------+------+-----------------+-----------+---------------+
| id  | transport     | aors | auth | rewrite_contact | from_user | media_address |
+-----+---------------+------+------+-----------------+-----------+---------------+
| 104 | transport-udp | 104  | NULL | yes             | 104       | 1.1.1.1       |
| sbc | transport-udp | sbc  | NULL | yes             | sbc       | 1.1.1.1       |
+-----+---------------+------+------+-----------------+-----------+---------------+

The Microsip auths on Kamailio and Kamailio sends an REGISTER to Asterisk without authentication.

Call Flow:

1 - Microsip call *65 (self test audio)
2 - Kamailio1(10.0.0.43) receives *65 and forward to Asterisk(10.0.0.29)
3 - Asterisk answer the call and play an audio.
4 - While Asterisk is playing, Kamailio1 goes down.
5 - Asterisk stops to play and sends BYE message to Kamailio1, but it not responds and failover is not peformed to Kamailio2(10.0.0.20).

“sip-udp” is an DNS that resolves to two IP address of SBC’s: 10.0.0.43 and 10.0.0.29 (I’ve tried to test too making “sip-udp” name to be an single IP address loadbalancer, that ends traffic to two SBCs IPs, but the same behavior accours).

SIP FLOW (the domain and ip media server was preserved):

[jcolp]

Try disabling rewrite_contact. If that doesn’t work then failover may not occur for BYE, I can’t recall if it would or not. If not then someone would have to look at the code. There would be no time frame on if or when it would occur.

[david551]

I certainly can’t think of any way in which Rewrite-Contact could do anything good in a context that requires late resolution of domain names; it’s all about using the actual source IP address. Did you copy and paste it from somewhere?

[benedito]

Wow, after set rewrite_contact to ‘no’, the route headers keep with the name and the failover accours perfectly!

I don’t understand how this was maked, because the description of the “rewrite_contact” parameter says about the “Contact” header, not the route headers in general.

[david551]

What did you think rewrite contact would do. Whilst the behaviour doesn’t literally fit the description, the literal behaviour would not make sense and what it is actually doing is much more consistent with the reasons the option exists.

[benedito]

I thought only the “Contact” header is affected by this option, not the route headers like “Record-Route” and “Route”.

[jcolp]

It does impact Record-Route and Route as well, that functionality was added afterwards - it basically rewrites things to send it back to the source, regardless.

[benedito]

Thank you for explanation @jcolp.