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

 

Von: sr-users [mailto:sr-users-bounces@lists.sip-router.org] Im Auftrag von Francisco Valentin Vinagrero
Gesendet: Mittwoch, 29. Juni 2016 16:17
An: Kamailio (SER) - Users Mailing List <sr-users@lists.sip-router.org>
Betreff: Re: [SR-Users] ACK / BYE transaction problem

 

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…

 

From: sr-users [mailto:sr-users-bounces@lists.sip-router.org] On Behalf Of Oliver Roth
Sent: 29 June 2016 16:04
To: Kamailio (SER) - Users Mailing List <sr-users@lists.sip-router.org>
Subject: Re: [SR-Users] ACK / BYE transaction problem

 

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

 

 

 

 

 

Von: sr-users [mailto:sr-users-bounces@lists.sip-router.org] Im Auftrag von Francisco Valentin Vinagrero
Gesendet: Mittwoch, 29. Juni 2016 16:00
An: Kamailio (SER) - Users Mailing List <sr-users@lists.sip-router.org>
Betreff: Re: [SR-Users] ACK / BYE transaction problem

 

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.

 

From: sr-users [mailto:sr-users-bounces@lists.sip-router.org] On Behalf Of Oliver Roth
Sent: 29 June 2016 15:55
To: sr-users@lists.sip-router.org
Subject: [SR-Users] ACK / BYE transaction problem

 

 

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