I'm having some trouble with kamailio that uses the topology hider module and an incoming call being put onhold by the caller. The INVITE containing the sdp a=sendonly is to the 172.19.162.1 (the topoh mask_ip) contact header from the 200 OK to the initial INVITE.
U 109.235.36.178:5060 -> 109.235.32.40:5060 INVITE sip:172.19.162.1:5060;line=pcs- mp4KWiTsxRmtEAM3WGysx7y3xGnoxAxtuAxSuA7KEsktxGZKWgQfZD6smqlf9Gttzjy*;user=phone SIP/2.0.
This is handled within dialog (has_totag() && !loose_route()), which in the default config ends in a sl_send_reply("404","Not here")
Explicitly handing INVITE (just relaying), results in the INVITE being sent to 172.19.162.1 (which doesn't exist)
U 109.235.32.40:5060 -> 172.19.162.1:5060 INVITE sip:172.19.162.1:5060;line=pcs- mp4KWiTsxRmtEAM3WGysx7y3xGnoxAxtuAxSuA7KEsktxGZKWgQfZD6smqlf9Gttzjy*;user=phone SIP/2.0.
How to get this INVITE to the actual destination? To get the same result for the INVITE as for the ACK to the 200 OK?
U 109.235.32.40:5060 -> 109.235.36.178:5060 SIP/2.0 200 OK. ... Contact: sip:172.19.162.1;line=pcs- mp4KWiTsxRmtEAM3WGysx7y3xGnoxAxtuAxSuA7KEsktxGZKWgQfZD6smqlf9Gttzjy*.
U 109.235.36.178:5060 -> 109.235.32.40:5060 ACK sip:172.19.162.1;line=pcs- mp4KWiTsxRmtEAM3WGysx7y3xGnoxAxtuAxSuA7KEsktxGZKWgQfZD6smqlf9Gttzjy* SIP/2.0.
U 109.235.32.40:5060 -> 109.235.34.107:5060 ACK sip:+31756418030@109.235.34.107:5060;transport=udp SIP/2.0.
Hello,
the re-INVITE should be handled in the same way as ACK for 200ok or BYE (i.e., request within dialog). Do you get any error message in syslog? Can you share a ngrep trace of such situation (from initial INVITE to the end)? you can send it to me if it has sensitive information.
Cheers, Daniel
On 09/04/14 16:06, Daniel Tryba wrote:
I'm having some trouble with kamailio that uses the topology hider module and an incoming call being put onhold by the caller. The INVITE containing the sdp a=sendonly is to the 172.19.162.1 (the topoh mask_ip) contact header from the 200 OK to the initial INVITE.
U 109.235.36.178:5060 -> 109.235.32.40:5060 INVITE sip:172.19.162.1:5060;line=pcs- mp4KWiTsxRmtEAM3WGysx7y3xGnoxAxtuAxSuA7KEsktxGZKWgQfZD6smqlf9Gttzjy*;user=phone SIP/2.0.
This is handled within dialog (has_totag() && !loose_route()), which in the default config ends in a sl_send_reply("404","Not here")
Explicitly handing INVITE (just relaying), results in the INVITE being sent to 172.19.162.1 (which doesn't exist)
U 109.235.32.40:5060 -> 172.19.162.1:5060 INVITE sip:172.19.162.1:5060;line=pcs- mp4KWiTsxRmtEAM3WGysx7y3xGnoxAxtuAxSuA7KEsktxGZKWgQfZD6smqlf9Gttzjy*;user=phone SIP/2.0.
How to get this INVITE to the actual destination? To get the same result for the INVITE as for the ACK to the 200 OK?
U 109.235.32.40:5060 -> 109.235.36.178:5060 SIP/2.0 200 OK. ... Contact: sip:172.19.162.1;line=pcs- mp4KWiTsxRmtEAM3WGysx7y3xGnoxAxtuAxSuA7KEsktxGZKWgQfZD6smqlf9Gttzjy*.
U 109.235.36.178:5060 -> 109.235.32.40:5060 ACK sip:172.19.162.1;line=pcs- mp4KWiTsxRmtEAM3WGysx7y3xGnoxAxtuAxSuA7KEsktxGZKWgQfZD6smqlf9Gttzjy* SIP/2.0.
U 109.235.32.40:5060 -> 109.235.34.107:5060 ACK sip:+31756418030@109.235.34.107:5060;transport=udp SIP/2.0.
On Thursday 10 April 2014 09:43:28 Daniel-Constantin Mierla wrote:
the re-INVITE should be handled in the same way as ACK for 200ok or BYE (i.e., request within dialog). Do you get any error message in syslog? Can you share a ngrep trace of such situation (from initial INVITE to the end)? you can send it to me if it has sensitive information.
No errors as far as I can see, ACKs go thru just fine.
Digging further it seems that the problem is not handling these re-INVITEs in general but only the ones from a test trunk from a new provider.
Following re-INVITE fails (10.10.48.129 is external SBC, 10.0.36.178 my 4.1 "SBC" and 10.0.32.40 the 4.0 register server with topoh, attached the full dialog):
# U 10.10.48.129:5060 -> 10.0.36.178:5060 INVITE sip:172.19.162.1;line=pcs- mp4KWiTsxRmtEAM3WGysx7y3xGnoxAxtuAxSuA7KEsktxGZKWgQfZD6smqlf9Gttzjy*;alias=10.0.32.40~5060~1 SIP/2.0. Via: SIP/2.0/UDP 10.10.48.129:5060;branch=z9hG4bKq7m2h6102gbgpmsb52c1.1. Call-ID: SDqj77801-889102173bc5f169e17c9aee50469a7f-a8b85e3. From: "Anonymous" sip:anonymous@anonymous.invalid;tag=SDqj77801-127.0.0.1alUtKGp-06001+1+5df90004+11130183. To: sip:;user=phone;tag=1ab0493ac1bfcdac. CSeq: 596754228 INVITE. Expires: 180. Contact: sip:anonymous@10.10.48.129:5060;transport=udp. Min-SE: 1800. Session-Expires: 1800;refresher=uac. Supported: replaces, 100rel, timer. Content-Length: 394. Allow: INVITE, BYE, REGISTER, ACK, OPTIONS, CANCEL, SUBSCRIBE, NOTIFY, PRACK, INFO, REFER, UPDATE. Max-Forwards: 67. Content-Type: application/sdp. User-Agent: Alcatel-Lucent 5020 MGC-8 8.1.0.16.SP5.4.
Here the To is mangled and there is no Route. But is that the reason things go wrong? If inconclusive I'll dig some further on the register server during off peak moments.
Calling the same endpoint but simulating with a SIP phone (natted) to 10.0.36.178, onhold works as expected.
U 10.0.34.226:54503 -> 10.0.36.178:5060 INVITE sip:172.19.162.1;line=pcs- mp4KWiTsxRmtEAM3WGysx7y3xGnoxAxtuAxSuA7KEsktxGZKWgQfZD6smqlf9Gttzjy*;alias=10.0.32.40~5060~1 SIP/2.0. Via: SIP/2.0/UDP 10.0.3.175:5060;branch=z9hG4bK-fe9a78d6. From: "sandbox" sip:tst6@sandbox.pocos.nl;tag=15cf109cd7012b3fo0. To: sip:0756xxxxxx@sandbox.pocos.nl;tag=34dc7260908c3408. Remote-Party-ID: "sandbox" sip:tst6@sandbox.pocos.nl;screen=yes;party=calling. Call-ID: 5e72bda0-f317c20b@10.0.3.175. CSeq: 102 INVITE. Max-Forwards: 70. Route: sip:10.0.36.178;lr=on;nat=yes, sip:10.0.32.40;lr=on;ftag=15cf109cd7012b3fo0;did=179.95c1;vst=AAAAABsEBAEBBwwBCwBzWzAFAw8dBQwLGkEIQRMAEEEdQm5s. Contact: "sandbox" sip:tst6@10.0.3.175:5060. Expires: 30. User-Agent: Linksys/SPA962-6.1.3(a). Content-Length: 227. Content-Type: application/sdp.
On Thursday 10 April 2014 14:53:10 Daniel Tryba wrote:
Here the To is mangled and there is no Route. But is that the reason things go wrong? If inconclusive I'll dig some further on the register server during off peak moments.
It appears I have been wasting time for everyone that is reading this thread. Kamailio appears to work just fine (as ever :)
A further test show the problem only occurs if the initial call is incoming (from my mobile) from this provider. Making an outbound call to this provider (to my mobile) and putting the mobile onhold results in correct behavior. In and outbound are different SBCs at this provider.
U 10.10.48.1:5060 -> 10.0.36.178:5060 INVITE sip:172.19.162.1;line=pcs- mp4KWiTsxRMKxAnsWGZpxry3xGnoxAxtuAxSuA7KEsktxGZKWgQfZD6smqlf9Gttzjy*;alias=10.0.32.40~5060~1 SIP/2.0. Via: SIP/2.0/UDP 10.10.48.1:5060;branch=z9hG4bKmhdrea00d071mlotd3e0.1. Call-ID: !!:WGXdzDrtWDE8E8xszRX6EAnSER9JzDxfxqM6zRntzGX*. From: sip:0646xxxxxx@sip.pocos.nl;user=phone;tag=SDctq2a99-127.0.0.1alUtKGp-02000+1+e10e0003+505e777f. To: "Daniel" sip:+31402xxxxxx@sip.pocos.nl;tag=0e601ee1e78114a5. CSeq: 1054377942 INVITE. Expires: 180. Contact: sip:+3164xxxxxxx@10.10.48.1:5060;user=phone;lr;transport=udp. Min-SE: 1800. Session-Expires: 1800;refresher=uac. Supported: replaces, 100rel, timer. Content-Length: 214. Allow: INVITE, BYE, REGISTER, ACK, OPTIONS, CANCEL, SUBSCRIBE, NOTIFY, PRACK, INFO, REFER, UPDATE. Max-Forwards: 67. Content-Type: application/sdp. User-Agent: Alcatel-Lucent 5020 MGC-8 8.1.0.16.SP5.4. Route: sip:10.0.36.178;lr=on;did=a6d.63b1;nat=yes. Route: sip:10.0.32.40;lr=on;ftag=0e601ee1e78114a5.
-
Daniel Tryba -
Daniel-Constantin Mierla