9 Apr
2014
9 Apr
'14
5:06 p.m.
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.
--
POCOS B.V. - Croy 9c - 5653 LC Eindhoven
Telefoon: 040 293 8661 - Fax: 040 293 8658
http://www.pocos.nl/ - http://www.sipo.nl/
K.v.K. Eindhoven 17097024
10 Apr
10 Apr
10:43 a.m.
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.
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
3:53 p.m.
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(a)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.
--
POCOS B.V. - Croy 9c - 5653 LC Eindhoven
Telefoon: 040 293 8661 - Fax: 040 293 8658
http://www.pocos.nl/ - http://www.sipo.nl/
K.v.K. Eindhoven 17097024
4:17 p.m.
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>.
--
POCOS B.V. - Croy 9c - 5653 LC Eindhoven
Telefoon: 040 293 8661 - Fax: 040 293 8658
http://www.pocos.nl/ - http://www.sipo.nl/
K.v.K. Eindhoven 17097024
3909
days inactive
3910
days old
3 comments
2 participants
participants (2)
-
Daniel Tryba -
Daniel-Constantin Mierla