[SR-Users] ACK / BYE transaction problem

Francisco Valentin Vinagrero francisco.valentin.vinagrero at cern.ch
Wed Jun 29 16:16:50 CEST 2016


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 at lists.sip-router.org] On Behalf Of Oliver Roth
Sent: 29 June 2016 16:04
To: Kamailio (SER) - Users Mailing List <sr-users at 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 at 212.25.7.69>;tag=sc1NXPTEST-4c9b51343502af61
To: <sip:0794567735 at 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 at 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 at 212.25.7.69>;tag=sc1NXPTEST-4c9b51343502af61

To: <sip:0794567735 at 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 at 185.49.222.43:5060 SIP/2.0

Record-Route: <sip:185.49.222.43;lr=on>

From: <sip:0275279225 at 212.25.7.69>;tag=sc1NXPTEST-4c9b51343502af61

To: <sip:0794567735 at 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 at 212.25.7.69:5060>

P-Asserted-Identity: <sip:0275279225 at 212.25.7.69>

Content-Type: application/sdp

Content-Length: 401


Invite sent to [carr] from [gw]

INVITE sip:41794567735 at 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 at 212.25.7.69>;tag=sc1NXPTEST-4c9b51343502af61

To: <sip:0794567735 at 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 at 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 at 212.25.7.69;user=phone>

Content-Type: application/sdp





Von: sr-users [mailto:sr-users-bounces at 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 at lists.sip-router.org<mailto:sr-users at 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 at lists.sip-router.org] On Behalf Of Oliver Roth
Sent: 29 June 2016 15:55
To: sr-users at lists.sip-router.org<mailto:sr-users at 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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20160629/92e7a9d9/attachment.html>


More information about the sr-users mailing list