15 Mar
2023
15 Mar
'23
1:40 p.m.
Hello,
We have an issue which appears when TOPOH module is enabled, call is made from WebRTC,
then transferred by calee:
Mar 15 11:55:27 ap07stvp.xxxxxxx.xxx docker[2062]: 29(35) INFO: {2 2 INVITE
g2rgvnioadg8m7l6i7k6} <script>: RTPENGINE branch_id:0 ruri: <null>,
method:INVITE, status:200, extra_id: z9hG4bK66807520, rtpengine_answer: replace-origin
replace-session-connection SIP-source-address direction=priv1 direction=pub1
SIP-source-address via-branch=extra rtcp-mux-offer generate-mid DTLS=passive SDES-off
ICE=force RTP/SAVPF
Mar 15 11:55:27 ap07stvp.xxxxxxx.xxx docker[2062]: 29(35) NOTICE: {2 2 INVITE
g2rgvnioadg8m7l6i7k6} acc [acc.c:287]: acc_log_request(): ACC: transaction answered:
timestamp=1678881327;method=INVITE;from_tag=p9qqi7hrua;to_tag=ea7d2850-3e76-4c11-821c-a0d1e3cbb011;call_id=g2rgvnioadg8m7l6i7k6;code=200;reason=OK;src_user=92010;src_domain=10.181.0.1;src_ip=10.5.0.145;dst_ouser=27221;dst_user=27221;dst_domain=10.181.0.1
Mar 15 11:55:38 ap07stvp.xxxxxxx.xxx docker[2062]: 31(37) INFO: {1 27689 BYE
e034a187-0e4d-4c4e-ab4b-f2e5f1281330} <script>: RTPENGINE branch_id:0 ruri:
sip:97093@10.128.150.67:46058;rinstance=d403efb922420649;transport=UDP, method:BYE,
status:<null>, extra_id: <null>, rtpengine_delete
Mar 15 11:55:38 ap07stvp.xxxxxxx.xxx docker[2062]: 28(34) NOTICE: {2 27689 BYE
e034a187-0e4d-4c4e-ab4b-f2e5f1281330} acc [acc.c:287]: acc_log_request(): ACC: transaction
answered:
timestamp=1678881338;method=BYE;from_tag=0c29be45-6aff-4d4e-8503-650893a5a5ac;to_tag=b1a8a401;call_id=e034a187-0e4d-4c4e-ab4b-f2e5f1281330;code=200;reason=OK;src_user=22628;src_domain=10.5.2.192;src_ip=10.5.2.192;dst_ouser=97093;dst_user=97093;dst_domain=10.128.150.67
Mar 15 11:55:39 ap07stvp.xxxxxxx.net docker[2062]: 32(38) INFO: {1 27798 INVITE
g2rgvnioadg8m7l6i7k6} <script>: RTPENGINE branch_id:0 ruri:
sip:jgqtuev6@2idi5cucan2v.invalid;transport=ws;ob, method:INVITE, status:<null>,
extra_id: <null>, rtpengine_offer: replace-origin replace-session-connection
SIP-source-address direction=priv1 direction=pub1 SIP-source-address direction=priv1
direction=pub1 rtcp-mux-offer generate-mid DTLS=passive SDES-off ICE=force RTP/SAVPF
Mar 15 11:55:39 ap07stvp.xxxxxxx.xxx docker[2062]: 27(33) INFO: {1 4728 INVITE
133ccd4c-031b-4d10-b073-745f35433132} <script>: RTPENGINE branch_id:0 ruri:
sip:0037126048570@193.138.189.220, method:INVITE, status:<null>, extra_id:
z9hG4bKPjedcf2d96-01cd-43fd-bed0-4e601e3e542f0, rtpengine_offer: replace-origin
replace-session-connection SIP-source-address direction=priv1 direction=pub1
via-branch=extra
Mar 15 11:55:39 ap07stvp.xxxxxxx.xxx docker[2062]: 50(56) INFO: {2 27798 INVITE
g2rgvnioadg8m7l6i7k6} <script>: RTPENGINE branch_id:0 ruri: <null>,
method:INVITE, status:200, extra_id: z9hG4bKPj1cd87bda-7862-4ca9-8475-ac6b342c45ef0,
rtpengine_answer: replace-origin replace-session-connection SIP-source-address
direction=pub1 direction=priv1 SIP-source-address via-branch=extra rtcp-mux-demux DTLS=off
SDES-off ICE=remove RTP/AVP
Mar 15 11:55:39 ap07stvp.xxxxxxx.xxx docker[2062]: 25(31) ERROR: {1 27798 ACK
g2rgvnioadg8m7l6i7k6} <core> [core/resolve.c:1730]: sip_hostport2su(): could not
resolve hostname: "2idi5cucan2v.invalid"
Mar 15 11:55:39 ap07stvp.xxxxxxx.xxx docker[2062]: 25(31) ERROR: {1 27798 ACK
g2rgvnioadg8m7l6i7k6} <core> [core/forward.c:516]: forward_request(): bad host name
2idi5cucan2v.invalid, dropping packet
Mar 15 11:55:39 ap07stvp.xxxxxxx.xxx docker[2062]: 25(31) ERROR: {1 27798 ACK
g2rgvnioadg8m7l6i7k6} sl [sl_funcs.c:418]: sl_reply_error(): stateless error reply used:
Unresolvable destination (478/SL)
We have the following setup:
WebRTC client behind load-balanser -> kamailio -> asterisk.
When call is transferred, asterisk makes re-invite.
If TOPOH is disabled, it happens this way and issue is not present:
asterisk INVITE -> kamailio -> WebRTC
WebRTC 200 -> kamailio -> asterisk
asterisk ACK -> kamailio -> WebRTC
ACK example:
03/09/2023 09:35:48.126 +02:00: 10.5.2.192:5060 -> 10.181.0.1:5060
ACK sip:98dn3met@0j62ln34srjn.invalid;transport=ws;ob;alias=10.5.0.145~27562~6 SIP/2.0
Via: SIP/2.0/UDP
10.5.2.192:5060;rport;branch=z9hG4bKPj1d11dae2-10bf-466e-9221-5710f801d725
From: <sip:27221@10.181.0.1>;tag=b6b73135-efe1-4d86-bbc8-bf4313130eb5
To: <sip:92010@10.181.0.1>;tag=namgu127j9
Call-ID: t0hmmk50h5i4ok88asjj
CSeq: 28632 ACK
Route:
<sip:10.181.0.1:5060;lr;r2=on;ftag=namgu127j9;did=aaa.7b92;rtp=bridge;rtp=ws>
Route:
<sip:10.181.0.1:4444;transport=ws;lr;r2=on;ftag=namgu127j9;did=aaa.7b92;rtp=bridge;rtp=ws>
Max-Forwards: 70
User-Agent: Asterisk PBX 18.16.0
Content-Length: 0
If TOPOH is enabled, kamailio doesn't pass this ACK to WebRTC:
asterisk INVITE -> kamailio -> WebRTC
WebRTC 200 -> kamailio -> asterisk
asterisk ACK -> kamailio -> -> ->
ACK example:
03/09/2023 09:33:03.544 +02:00: 10.5.2.192:5060 -> 10.181.0.1:5060
ACK sip:10.0.0.1;line=Bn7Ipzh8eb8DxMSFyk.rWzitxzVFBoirxRG5xYeOxb7hpoXTlMGDBbuTCk3oBDAqlH**
SIP/2.0
Via: SIP/2.0/UDP
10.5.2.192:5060;rport;branch=z9hG4bKPjf00fc541-f011-4e52-b63a-2c569478ca39
From: <sip:27221@10.181.0.1>;tag=7d402872-7355-4269-b912-e52ee28ed415
To: <sip:92010@10.181.0.1>;tag=t0q4g9am9g
Call-ID: t0hmmetickvlvn5k7nco
CSeq: 25565 ACK
Route:
<sip:10.181.0.1:5060;lr;r2=on;ftag=t0q4g9am9g;did=4c8.a182;rtp=bridge;rtp=ws>
Route:
<sip:10.0.0.1;line=Bn7IpzdIwzd8Vf8Iwzd9WkyFWkAFBELJBo.qBYyuCoVgBz1uxn8gx61uxn8geYXOeD3FV6dFeD7Oxj7YpnX5ekFFlDHJljd8VzATC60ulYi5ebC7poiFBk3oBI**>
Max-Forwards: 70
User-Agent: Asterisk PBX 18.16.0
Content-Length: 0
We have an assumption that issue might be related to the way how TOPOH handles alias in
contact.
Did someone have encountered something like this?