search

irontec / itsbc

Irontec Tiny SBC. OpenSIPS & RTPEngine based micro SBC with Web Administration
GNU General Public License v3.0
36 stars 27 forks source link

Attended transfer does not work properly #8

Open ralonsom opened 6 years ago

ralonsom commented 6 years ago

I have three registered users on a pbx behind tinySBC. If I make a call from A to B and try to make an attendant transfer to C, this fails. A stands by on hold and B displays "transfer completed" on the screen but does not "release" the call. C stays in communication with B. If we do the same with an unattended transfer it works properly.

zetagor commented 6 years ago

Hello Ralonsom,

Thanks for reporting! ¿Is it in plain UDP or TLS<>UDP|TCP? If you can test same scenario with UDP<>UDP it would be easier to debug.

¿Could you please attach a pcap file (captured on tinySBC box) ? (something like tcpdump -s 0 -n -v -i any -w file.pcap udp and port 5060)

ralonsom commented 6 years ago

Its a UDP<>UDP. in this example, A is 112 B is 103 and C is 111, i think is loosing one leg in transfer. atttransfer.zip

cruzccl commented 6 years ago

Hi @ralonsom ,

The problem here seems to be that the Replaces param of the Refer-To header in the REFER request is not adapted by OpenSIPS topology_hiding module:

REFER sip:192.168.38.187:4060;did=b84.2671b7a6 SIP/2.0
Accept: application/sdp, message/sipfrag
Via: SIP/2.0/UDP 192.168.38.176:24123;branch=z9hG4bK78a23d451581de4bf;rport
Max-Forwards: 70
From: <sip:555009338147154753@192.168.38.187:4060>;tag=3944666650
To: <sip:112@192.168.38.168>;tag=as0e24b99b
Call-ID: DLGCH_e0dWDDVxYGF4FlNWMStma3lJVltlKzJhfEkBDGN5ZzAPQVxcfXhma2FDXUBif2hpekBTXg--
CSeq: 1428893874 REFER
Allow: ACK, BYE, CANCEL, INVITE, NOTIFY, OPTIONS, REFER, SUBSCRIBE, UPDATE
Allow-Events: hold, talk
Contact: <sip:103@192.168.38.176:24123;transport=udp>
Refer-To: <sip:111@test.com?Replaces=56ae17977e877a97%3bto-tag%3das1dfc9248%3bfrom-tag%3d0a01c2b35b>
Referred-By: <sip:555009338147154753@192.168.38.187:4060>
Supported: eventlist, join, replaces, sdp-anat
User-Agent: Alcatel Temporis IP151 2.0.5.A-0
Content-Length: 0

in converted into:

REFER sip:112@192.168.38.168:5060 SIP/2.0
Accept: application/sdp, message/sipfrag
Via: SIP/2.0/UDP 192.168.38.187:4060;branch=z9hG4bKfcdb.fb765c5.0
Max-Forwards: 69_
From: <sip:555009338147154753@192.168.38.187:4060>;tag=3944666650
To: <sip:112@192.168.38.168>;tag=as0e24b99b
Call-ID: 473bf8027f68bb6869356bb239db007c@192.168.38.168:5060
CSeq: 1428893874 REFER
Allow: ACK, BYE, CANCEL, INVITE, NOTIFY, OPTIONS, REFER, SUBSCRIBE, UPDATE
Allow-Events: hold, talk
Contact: <sip:192.168.38.187:4060;did=b84.2671b7a6>
Refer-To: <sip:111@test.com?Replaces=56ae17977e877a97%3bto-tag%3das1dfc9248%3bfrom-tag%3d0a01c2b35b>
Referred-By: <sip:555009338147154753@192.168.38.187:4060>
Supported: eventlist, join, replaces, sdp-anat
User-Agent: Alcatel Temporis IP151 2.0.5.A-0
Content-Length: 0

R-URI, Via, Call-ID and Contact are mangled, but the Refer-to header keeps equal. To be more specific, the Replaces parameter is not adapted (Replaces=56ae17977e877a97).

When that REFER reaches the PBX behind the itsbc, it indicates in the NOTIFY that it doesn't recognize tha call-ID (SIP/2.0 481 Call leg/transaction does not exist).

You could try removing the C param in topology_hiding() call here to avoid the Call-ID masking. The other (harder) way would be inspecting the code of topology_hiding module code and try to fix.

Regards,

ralonsom commented 6 years ago

effectively, if I remove option C the transfer works correctly.