Yes the ip for the
[carr] is missing.
But I thought, the [gw ]
should create the ack based on the transaction and send it
to the [carr]
My situation
Class5 system [c5] à Loadbalancer kamailio (dispatcher module)
[lbl] -à gateway kamailio [gw] à carrier [carr]
So who is doing a
mistake? The lbl, the gw or even the c5 system?
If helpful, I could
provide a trace with all the stations in it.
Kr,
Oli
Your
ACK is missing the right IP in the RURI (should be the one
in the contact header in the 200 OK) and the Route headers
for every Record-Route in the 200 OK, if I understand well
your scenario…
I removed the changes
for the to header – so it is not touched all the time
200 ok from [carr]
SIP/2.0 200 OK
From: <sip:41275279225@212.25.7.69>;tag=sc1NXPTEST-4c9b51343502af61
To: <sip:0794567735@212.25.7.70>;tag=snl_0015024070
Call-ID:
5773d0ab9b30-5bau50gxp4en
CSeq: 1 INVITE
Via: SIP/2.0/UDP
185.49.222.44;branch=z9hG4bKbe7c.0f5ca21e3a66f41694ca709ac28c1192.0
Via: SIP/2.0/UDP
185.49.222.43;branch=z9hG4bKbe7c.a5e4cba8b1d9a4a56d1120d012a06850.0
Via: SIP/2.0/UDP
212.25.7.69:5060;uac=sc1;branch=z9hG4bKsc1NXPTEST-ae749ab817378131
Record-Route: <sip:185.49.222.44;lr=on;did=4b7.9422>
Record-Route: <sip:185.49.222.43;lr=on>
Contact: <sip:794567735@81.7.235.236:5060;transport=udp>
Content-Type: application/sdp
Content-Length: 197
Accept-Language: en;q=0.0
Allow: REGISTER, INVITE, ACK, BYE, CANCEL,
NOTIFY, REFER, UPDATE
Supported: timer
Session-Expires: 1800;refresher=uas
Date: Wed, 29 Jun 2016 13:44:20 GMT
v=0
o=- 277262053 1 IN IP4 81.7.235.228
s=-
c=IN IP4 81.7.235.228
t=0 0
m=audio 24212 RTP/AVP 8 101
a=fmtp:101 0-15
a=rtpmap:101 telephone-event/8000
a=silenceSupp:off - - - -
a=ptime:20
ACK from [lbl] to [gw]
ACK sip:185.49.222.44;did=4b7.9422;lr=on SIP/2.0
From: <sip:41275279225@212.25.7.69>;tag=sc1NXPTEST-4c9b51343502af61
To: <sip:0794567735@212.25.7.70>;tag=snl_0015024070
Call-ID: 5773d0ab9b30-5bau50gxp4en
CSeq: 1 ACK
Max-Forwards: 28
Via: SIP/2.0/UDP 185.49.222.43;branch=z9hG4bKbe7c.a6f12b66454fbb7b536aa22cef3d568c.0
Via: SIP/2.0/UDP 185.49.222.43;branch=z9hG4bKbe7c.7bc483a166362b13ba3cc40ca60308ea.0
Via: SIP/2.0/UDP 212.25.7.69:5060;branch=z9hG4bKsc1NXPTEST-ae749ab817378131A
Content-Length: 0
X-gateway: <null>
X-SI: <null>
X-gateway: <null>
X-SI: <null>
Initial Inivte to [gw]
from [lbl]
INVITE sip:0794567735@185.49.222.43:5060 SIP/2.0
Record-Route: <sip:185.49.222.43;lr=on>
From: <sip:0275279225@212.25.7.69>;tag=sc1NXPTEST-4c9b51343502af61
To: <sip:0794567735@212.25.7.70>
Call-ID: 5773d0ab9b30-5bau50gxp4en
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, BYE, OPTIONS
Max-Forwards: 29
User-Agent: AareSwitch/6.2.8553
Via: SIP/2.0/UDP 185.49.222.43;branch=z9hG4bKbe7c.a5e4cba8b1d9a4a56d1120d012a06850.0
Via: SIP/2.0/UDP 212.25.7.69:5060;uac=sc1;branch=z9hG4bKsc1NXPTEST-ae749ab817378131
Contact: <sip:0275279225@212.25.7.69:5060>
P-Asserted-Identity: <sip:0275279225@212.25.7.69>
Content-Type: application/sdp
Content-Length: 401
Invite sent to [carr]
from [gw]
INVITE sip:41794567735@81.7.235.236 SIP/2.0
Record-Route: <sip:185.49.222.44;lr=on;did=4b7.9422>
Record-Route: <sip:185.49.222.43;lr=on>
From: <sip:41275279225@212.25.7.69>;tag=sc1NXPTEST-4c9b51343502af61
To: <sip:0794567735@212.25.7.70>
Call-ID: 5773d0ab9b30-5bau50gxp4en
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, BYE, OPTIONS
Max-Forwards: 28
User-Agent: AareSwitch/6.2.8553
Contact: <sip:41279225@212.25.7.69>
Via: SIP/2.0/UDP 185.49.222.44;branch=z9hG4bKbe7c.0f5ca21e3a66f41694ca709ac28c1192.0
Via: SIP/2.0/UDP 185.49.222.43;branch=z9hG4bKbe7c.a5e4cba8b1d9a4a56d1120d012a06850.0
Via: SIP/2.0/UDP 212.25.7.69:5060;uac=sc1;branch=z9hG4bKsc1NXPTEST-ae749ab817378131
P-Asserted-Identity: <sip:41275279225@212.25.7.69;user=phone>
Content-Type: application/sdp
Hi,
Does
the ACK has the correct Router headers and R-URI? Maybe you
can share the 200 OK and the ACK headers..
I
had a similar issue 3 weeks ago.
Cheers,
Francisco.
Hi all
Follow scenario
Class5 system [c5] à Loadbalancer kamailio (dispatcher module)
[lbl] -à gateway kamailio [gw] à carrier [carr]
I get Invites from [c5]
with
Request ,To, from,
contact, pid in national format 0794445566
[lbl] dispatches this to
[gw]
For the [carr] I need
international format.
So doing these
transactions in [gw]
And sending to [carr] in
international format
Request, to, from,
contact, … => 417794445566
Everything ok
Then I get a 100, 183
and even 200 from [carr]
Ack is coming from [c5]
to [lbl] and [gw] – but then it stocks
The ACK is not sent to
the [carr]
I kamailio log I see
DEBUG: RFC3261
transaction matching failed
DEBUG: t_lookup_request:
no transaction found
So for me, the ACK
cannot be assigned to a transaction and gets discarded by
if ( is_method("ACK") )
{
xlog(,"L_INFO", "WITHINDLG ACK - not loose route\n");
if ( t_check_trans() ) {
xlog(,"L_INFO", "WITHINDLG ACK - t_check_trans()
\n");
# no loose-route, but stateful ACK;
# must be an ACK after a 487
# or e.g. 404 from upstream server
t_relay();
exit;
} else {
xlog(,"L_INFO", "WITHINDLG ACK - not t_check_trans()
DISCARD!!\n");
# ACK without matching transaction ... ignore and discard
route(NATMANAGE);
#t_relay();
#exit;
Any idea?
Problem with modifying
the sip tags? Or problem with the dialog?
Thanks for helping
OIi