[SR-Users] ACK / BYE transaction problem

Daniel-Constantin Mierla miconda at gmail.com
Fri Jul 1 09:54:34 CEST 2016


Hello,

can you get the traffic on load balancer (or the first hop in your
network that received the invite)? There you can see if the fault is in
your network or not.

In kamailio.cfg, be sure you don't use fix_nated_contact() function
unless you are the first hop receiving the sip message (request or
reply). As a matter of fact, fix_nated_contact() should not be used
anymore, use set_contact_alias() instead and handle requests within
dialog with handle_ruri_alias() -- see default kamailio.cfg for latest
kamailio versions.

Cheers,
Daniel


On 29/06/16 17:20, Oliver Roth wrote:
>
> 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 at 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 at 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 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 <mailto: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
>
>  
>
>  
>
>  
>
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

-- 
Daniel-Constantin Mierla
http://www.asipto.com - http://www.kamailio.org
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

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


More information about the sr-users mailing list