sr-users July 2018

sr-users@lists.kamailio.org

84 participants
102 discussions

Re: [SR-Users] NATHELPER issue
by Ali Taher 23 Jul '18

23 Jul '18

Hi Konstantin, INVITE: INVITE sip:9613159370@X.X.X.X:5065 SIP/2.0 Record-Route: <sip:X.X.X.X:5065;lr;ftag=5269152d> X-AUTH-IP: Y.Y.Y.Y Via: SIP/2.0/UDP X.X.X.X:5065;branch=z9hG4bK0f8e.68a6417bb4b72bec0eb7c44427dc8731.0 Via: SIP/2.0/UDP 192.168.26.3:31556;received=Y.Y.Y.Y;branch=z9hG4bK-d87543-6a165215a2441724-1--d87543-;rport=31556 Max-Forwards: 69 Contact: <sip:967123456@192.168.26.3:31556;alias=Y.Y.Y.Y~31556~1> To: "9613159370"<sip:9613159370@X.X.X.X:5065> From: "+967123456"<sip:967123456@X.X.X.X:5065>;tag=5269152d Call-ID: c10f30782b42be0fNjNiNTdjNGM1MWIzNDlhNTM4MzAwYWI0NWY2NGRmOTM. CSeq: 1 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO Content-Type: application/sdp User-Agent: eyeBeam release 1003s stamp 31159 Content-Length: 434 v=0 o=- 5 2 IN IP4 192.168.26.3 s=CounterPath eyeBeam 1.5 c=IN IP4 192.168.26.3 t=0 0 m=audio 8602 RTP/AVP 0 8 101 a=alt:1 4 : F4Vpy7HX BRVjd5rl 192.168.26.3 8602 a=alt:2 3 : ZTQ/VQpO 5uDGgHMJ 192.168.164.1 8602 a=alt:3 2 : ZZPaUsAW LVjbM9qy 192.168.74.1 8602 a=alt:4 1 : 5lOKe54U yTwyWfpC 11.11.0.122 8602 a=fmtp:101 0-15 a=rtpmap:101 telephone-event/8000 a=sendrecv a=x-rtp-session-id:0CDBBC1F22564B72BDA5AD0B07C2AECF 200 OK 200 OK Via: SIP/2.0/UDP 192.168.26.3:31556;received=Y.Y.Y.Y;branch=z9hG4bK-d87543-6a165215a2441724-1--d87543-;rport=31556 Record-Route: <sip:X.X.X.X:5065;lr;ftag=5269152d> From: "+967123456" <sip:967123456@X.X.X.X:5065>;tag=5269152d To: "9613159370" <sip:9613159370@X.X.X.X:5065>;tag=agtHmrp3Dccrg Call-ID: c10f30782b42be0fNjNiNTdjNGM1MWIzNDlhNTM4MzAwYWI0NWY2NGRmOTM. CSeq: 1 INVITE Contact: <sip:9613159370@X.X.X.X:5060;transport=udp> User-Agent: FIKAR Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE Supported: timer, path, replaces Allow-Events: talk, hold, conference, presence, as-feature-event, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer Content-Type: application/sdp Content-Disposition: session Content-Length: 200 Remote-Party-ID: "Outbound Call" <sip:506251539613159370@X.X.X.X>;party=calling;privacy=off;screen=no v=0 o=FIKAR 4050780586 4050780588 IN IP4 X.X.X.X s=FIKAR c=IN IP4 X.X.X.X t=0 0 m=audio 24496 RTP/AVP 8 101 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 where: X.X.X.X is Kamailio IP Y.Y.Y.Y is origination public IP Regards, Ali From: Konstantin Polyakov <piligrim_pk(a)mail.ru> Sent: Monday, July 23, 2018 12:08 PM To: Ali Taher <ataher(a)vanrise.com> Subject: Re[2]: [SR-Users] NATHELPER issue Hello Ali, Could you show your latest INVITE and OK? Check you SDP bodies in those messages, if you still have there private IPs then you need to solve usual NAT traversal task in your media software (not proxy). Kamailio doesn't process media as you know. Of course you can try fix_nated_sdp function from nathelper module but it will not work for symmetric NAT because you fix SDP with public IP toward proxy but not toward UA. Your media software or hardware should support STUN or ICE protocols to work correctly via NAT. Best regards. Понедельник, 23 июля 2018, 11:41 +03:00 от Ali Taher <ataher(a)vanrise.com <mailto:ataher@vanrise.com> >: Thank you for your reply. ACK is now sent correctly to public IP , yet I have another issue with RBT where it’s still sent to private IP .Yet the call media is sent correctly to the public IP. There is something strange , as I hear two short different ringing tones then complete silence till the called party answer the call and RTP flow normally. How can I handle this case? Thanks, Ali From: Konstantin Polyakov <piligrim_pk(a)mail.ru <mailto:piligrim_pk@mail.ru> > Sent: Friday, July 20, 2018 3:01 PM To: sr-users(a)lists.kamailio.org <mailto:sr-users@lists.kamailio.org> ; Ali Taher <ataher(a)vanrise.com <mailto:ataher@vanrise.com> > Subject: Re: [SR-Users] NATHELPER issue Hello Ali, ACK is sent by UAC to the Contact which is received in OK from UAS. So from my point of view you need to fix that Contact in OK on your proxy. My NATDETECT looks like: if (nat_uac_test("19")) { fix_nated_contact(); } I call it for requests and responses. Best regards. Konstantin Message: 23 Date: Fri, 20 Jul 2018 11:13:42 +0300 From: "Ali Taher" <ataher(a)vanrise.com <file://e.mail.ru/compose/%3fmailto=mailto%253aataher@vanrise.com> > To: <sr-users(a)lists.sip-router.org <file://e.mail.ru/compose/%3fmailto=mailto%253asr%252dusers@lists.sip%252drouter.org> > Subject: [SR-Users] NATHELPER issue Message-ID: <070901d42001$939be2b0$bad3a810$(a)vanrise.com <file://e.mail.ru/compose/%3fmailto=mailto%253a070901d42001$939be2b0$bad3a810$@vanrise.com> > Content-Type: text/plain; charset="utf-8" Hello, I'm using Kamailio 4.2 as proxy with nathelper enabled. Yet , the ACK packet sent from the proxy to the origination's private IP. The ACK is sent as reply on the following 200 OK sent from the origination : 8m2EJN41BN/6WSIP/2.0 200 OK From: <sip:+4444331234567@X.X.X.X;user=phone>;tag=XQBQNjvjgp4Ze To: <sip:+905362695933@172.16.45.65;user=phone>;tag=12033368836000 Via: SIP/2.0/UDP X.X.X.X:5065;branch=z9hG4bK2959.233ecbc5eff949f946d8763ce25e5e6d.0;received= X.X.X.X,SIP/2.0/UDP X.X.X.X;received=X.X.X.X;rport=5060;branch=z9hG4bKN93cXvv26vDDN Record-Route: <sip:X.X.X.X:5065;lr;ftag=XQBQNjvjgp4Ze> Call-ID: CbeX8453909200habfGhEfElPce(a)BC00.XXXXXXXXXXXXXX <file://e.mail.ru/compose/%3fmailto=mailto%253aCbeX8453909200habfGhEfElPce@BC00.XXXXXXXXXXXXXX> CSeq: 125698370 INVITE Accept: application/sdp Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,UPDATE P-Charging-Vector: icid-value=B0912C3D70-0720-09394507;icid-generated-at=BC00.XXXXXXXXXXXXXX.XX ;orig-ioi=MXXXXXXXXXXXXXX Content-Type: application/sdp Contact: <sip:172.16.45.65:5060;transport=UDP> Content-Length: 268 v=0 o=- 5838243 5838244 IN IP4 BC00.XXXXXXXXXXXXXX s=- c=IN IP4 172.16.45.144 t=0 0 a=sendrecv m=audio 47588 RTP/AVP 18 96 c=IN IP4 172.16.45.144 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=yes a=rtpmap:96 telephone-event/8000 a=fmtp:96 0-15 a=maxptime:20 Following is the header of the sent ACK packet: Request-Line: ACK sip:172.16.45.65:5060;transport=UDP SIP/2.0 Record-Route: <sip:X.X.X.X:5065;lr;ftag=XQBQNjvjgp4Ze> Via: SIP/2.0/UDP X.X.X.X:5065;branch=z9hG4bK2959.871535fd341bbe3099d0bf60d6460e18.0 Via: SIP/2.0/UDP X.X.X.X;received=X.X.X.X;rport=5060;branch=z9hG4bKQUpy0jy90etjc Max-Forwards: 69 From: <sip:+4444331234567@X.X.X.X;user=phone>;tag=XQBQNjvjgp4Ze To: <sip:+905362695933@172.16.45.65;user=phone>;tag=12033368836000 Call-ID: CbeX8453909200habfGhEfElPce(a)BC00.XXXXXXXXXXXXXX <file://e.mail.ru/compose/%3fmailto=mailto%253aCbeX8453909200habfGhEfElPce@BC00.XXXXXXXXXXXXXX> CSeq: 125698370 ACK Content-Length: 0 Where X.X.X.X is Kamailio server public IP. Following is part of my config file : route { route(NATDETECT); record_route(); if(!mf_process_maxfwd_header("10")) { sl_send_reply("483", "Too Many Hops"); exit; } # Maybe some sanity_check() here. if(has_totag()) { if(loose_route()) { route(DLGURI); if(!t_relay()) sl_reply_error(); exit; } else { if(is_method("ACK")) { route(DLGURI); if(t_check_trans()) { t_relay(); } } else sl_send_reply("403", "Forbidden"); } exit; } ..... } route[NATDETECT] { #!ifdef WITH_NAT force_rport(); if (nat_uac_test("19")) { if (is_method("REGISTER")) { fix_nated_register(); } else { add_contact_alias(); } setflag(FLT_NATS); } #!endif return; } route[DLGURI] { #!ifdef WITH_NAT if(!isdsturiset()) { handle_ruri_alias(); } #!endif return; } Can you please check why the ACK is still sent on private IP ? Thanks Ali Taher "Ali Taher" <ataher(a)vanrise.com <https://e.mail.ru/compose?To=ataher@vanrise.com> > С уважением, Константин Поляков.

1 0

Re: [SR-Users] NATHELPER issue
by Ali Taher 23 Jul '18

23 Jul '18

Hi Konstantin, INVITE: INVITE sip:9613159370@X.X.X.X:5065 SIP/2.0 Record-Route: <sip:X.X.X.X:5065;lr;ftag=5269152d> X-AUTH-IP: Y.Y.Y.Y Via: SIP/2.0/UDP X.X.X.X:5065;branch=z9hG4bK0f8e.68a6417bb4b72bec0eb7c44427dc8731.0 Via: SIP/2.0/UDP 192.168.26.3:31556;received=Y.Y.Y.Y;branch=z9hG4bK-d87543-6a165215a2441724-1--d87543-;rport=31556 Max-Forwards: 69 Contact: <sip:967123456@192.168.26.3:31556;alias=Y.Y.Y.Y~31556~1> To: "9613159370"<sip:9613159370@X.X.X.X:5065> From: "+967123456"<sip:967123456@X.X.X.X:5065>;tag=5269152d Call-ID: c10f30782b42be0fNjNiNTdjNGM1MWIzNDlhNTM4MzAwYWI0NWY2NGRmOTM. CSeq: 1 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO Content-Type: application/sdp User-Agent: eyeBeam release 1003s stamp 31159 Content-Length: 434 v=0 o=- 5 2 IN IP4 192.168.26.3 s=CounterPath eyeBeam 1.5 c=IN IP4 192.168.26.3 t=0 0 m=audio 8602 RTP/AVP 0 8 101 a=alt:1 4 : F4Vpy7HX BRVjd5rl 192.168.26.3 8602 a=alt:2 3 : ZTQ/VQpO 5uDGgHMJ 192.168.164.1 8602 a=alt:3 2 : ZZPaUsAW LVjbM9qy 192.168.74.1 8602 a=alt:4 1 : 5lOKe54U yTwyWfpC 11.11.0.122 8602 a=fmtp:101 0-15 a=rtpmap:101 telephone-event/8000 a=sendrecv a=x-rtp-session-id:0CDBBC1F22564B72BDA5AD0B07C2AECF 200 OK 200 OK Via: SIP/2.0/UDP 192.168.26.3:31556;received=Y.Y.Y.Y;branch=z9hG4bK-d87543-6a165215a2441724-1--d87543-;rport=31556 Record-Route: <sip:X.X.X.X:5065;lr;ftag=5269152d> From: "+967123456" <sip:967123456@X.X.X.X:5065>;tag=5269152d To: "9613159370" <sip:9613159370@X.X.X.X:5065>;tag=agtHmrp3Dccrg Call-ID: c10f30782b42be0fNjNiNTdjNGM1MWIzNDlhNTM4MzAwYWI0NWY2NGRmOTM. CSeq: 1 INVITE Contact: <sip:9613159370@X.X.X.X:5060;transport=udp> User-Agent: FIKAR Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE Supported: timer, path, replaces Allow-Events: talk, hold, conference, presence, as-feature-event, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer Content-Type: application/sdp Content-Disposition: session Content-Length: 200 Remote-Party-ID: "Outbound Call" <sip:506251539613159370@X.X.X.X>;party=calling;privacy=off;screen=no v=0 o=FIKAR 4050780586 4050780588 IN IP4 X.X.X.X s=FIKAR c=IN IP4 X.X.X.X t=0 0 m=audio 24496 RTP/AVP 8 101 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 Regards, Ali From: Konstantin Polyakov <piligrim_pk(a)mail.ru> Sent: Monday, July 23, 2018 12:08 PM To: Ali Taher <ataher(a)vanrise.com> Subject: Re[2]: [SR-Users] NATHELPER issue Hello Ali, Could you show your latest INVITE and OK? Check you SDP bodies in those messages, if you still have there private IPs then you need to solve usual NAT traversal task in your media software (not proxy). Kamailio doesn't process media as you know. Of course you can try fix_nated_sdp function from nathelper module but it will not work for symmetric NAT because you fix SDP with public IP toward proxy but not toward UA. Your media software or hardware should support STUN or ICE protocols to work correctly via NAT. Best regards. Понедельник, 23 июля 2018, 11:41 +03:00 от Ali Taher <ataher(a)vanrise.com <mailto:ataher@vanrise.com> >: Thank you for your reply. ACK is now sent correctly to public IP , yet I have another issue with RBT where it’s still sent to private IP .Yet the call media is sent correctly to the public IP. There is something strange , as I hear two short different ringing tones then complete silence till the called party answer the call and RTP flow normally. How can I handle this case? Thanks, Ali From: Konstantin Polyakov <piligrim_pk(a)mail.ru <mailto:piligrim_pk@mail.ru> > Sent: Friday, July 20, 2018 3:01 PM To: sr-users(a)lists.kamailio.org <mailto:sr-users@lists.kamailio.org> ; Ali Taher <ataher(a)vanrise.com <mailto:ataher@vanrise.com> > Subject: Re: [SR-Users] NATHELPER issue Hello Ali, ACK is sent by UAC to the Contact which is received in OK from UAS. So from my point of view you need to fix that Contact in OK on your proxy. My NATDETECT looks like: if (nat_uac_test("19")) { fix_nated_contact(); } I call it for requests and responses. Best regards. Konstantin Message: 23 Date: Fri, 20 Jul 2018 11:13:42 +0300 From: "Ali Taher" <ataher(a)vanrise.com <file://e.mail.ru/compose/%3fmailto=mailto%253aataher@vanrise.com> > To: <sr-users(a)lists.sip-router.org <file://e.mail.ru/compose/%3fmailto=mailto%253asr%252dusers@lists.sip%252drouter.org> > Subject: [SR-Users] NATHELPER issue Message-ID: <070901d42001$939be2b0$bad3a810$(a)vanrise.com <file://e.mail.ru/compose/%3fmailto=mailto%253a070901d42001$939be2b0$bad3a810$@vanrise.com> > Content-Type: text/plain; charset="utf-8" Hello, I'm using Kamailio 4.2 as proxy with nathelper enabled. Yet , the ACK packet sent from the proxy to the origination's private IP. The ACK is sent as reply on the following 200 OK sent from the origination : 8m2EJN41BN/6WSIP/2.0 200 OK From: <sip:+4444331234567@X.X.X.X;user=phone>;tag=XQBQNjvjgp4Ze To: <sip:+905362695933@172.16.45.65;user=phone>;tag=12033368836000 Via: SIP/2.0/UDP X.X.X.X:5065;branch=z9hG4bK2959.233ecbc5eff949f946d8763ce25e5e6d.0;received= X.X.X.X,SIP/2.0/UDP X.X.X.X;received=X.X.X.X;rport=5060;branch=z9hG4bKN93cXvv26vDDN Record-Route: <sip:X.X.X.X:5065;lr;ftag=XQBQNjvjgp4Ze> Call-ID: CbeX8453909200habfGhEfElPce(a)BC00.XXXXXXXXXXXXXX <file://e.mail.ru/compose/%3fmailto=mailto%253aCbeX8453909200habfGhEfElPce@BC00.XXXXXXXXXXXXXX> CSeq: 125698370 INVITE Accept: application/sdp Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,UPDATE P-Charging-Vector: icid-value=B0912C3D70-0720-09394507;icid-generated-at=BC00.XXXXXXXXXXXXXX.XX ;orig-ioi=MXXXXXXXXXXXXXX Content-Type: application/sdp Contact: <sip:172.16.45.65:5060;transport=UDP> Content-Length: 268 v=0 o=- 5838243 5838244 IN IP4 BC00.XXXXXXXXXXXXXX s=- c=IN IP4 172.16.45.144 t=0 0 a=sendrecv m=audio 47588 RTP/AVP 18 96 c=IN IP4 172.16.45.144 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=yes a=rtpmap:96 telephone-event/8000 a=fmtp:96 0-15 a=maxptime:20 Following is the header of the sent ACK packet: Request-Line: ACK sip:172.16.45.65:5060;transport=UDP SIP/2.0 Record-Route: <sip:X.X.X.X:5065;lr;ftag=XQBQNjvjgp4Ze> Via: SIP/2.0/UDP X.X.X.X:5065;branch=z9hG4bK2959.871535fd341bbe3099d0bf60d6460e18.0 Via: SIP/2.0/UDP X.X.X.X;received=X.X.X.X;rport=5060;branch=z9hG4bKQUpy0jy90etjc Max-Forwards: 69 From: <sip:+4444331234567@X.X.X.X;user=phone>;tag=XQBQNjvjgp4Ze To: <sip:+905362695933@172.16.45.65;user=phone>;tag=12033368836000 Call-ID: CbeX8453909200habfGhEfElPce(a)BC00.XXXXXXXXXXXXXX <file://e.mail.ru/compose/%3fmailto=mailto%253aCbeX8453909200habfGhEfElPce@BC00.XXXXXXXXXXXXXX> CSeq: 125698370 ACK Content-Length: 0 Where X.X.X.X is Kamailio server public IP. Following is part of my config file : route { route(NATDETECT); record_route(); if(!mf_process_maxfwd_header("10")) { sl_send_reply("483", "Too Many Hops"); exit; } # Maybe some sanity_check() here. if(has_totag()) { if(loose_route()) { route(DLGURI); if(!t_relay()) sl_reply_error(); exit; } else { if(is_method("ACK")) { route(DLGURI); if(t_check_trans()) { t_relay(); } } else sl_send_reply("403", "Forbidden"); } exit; } ..... } route[NATDETECT] { #!ifdef WITH_NAT force_rport(); if (nat_uac_test("19")) { if (is_method("REGISTER")) { fix_nated_register(); } else { add_contact_alias(); } setflag(FLT_NATS); } #!endif return; } route[DLGURI] { #!ifdef WITH_NAT if(!isdsturiset()) { handle_ruri_alias(); } #!endif return; } Can you please check why the ACK is still sent on private IP ? Thanks Ali Taher "Ali Taher" <ataher(a)vanrise.com <https://e.mail.ru/compose?To=ataher@vanrise.com> > С уважением, Константин Поляков.

1 0

KEMI: accessing "keyword" variables from core
by Enrico Bandiera 23 Jul '18

23 Jul '18

Hi, anyone how to access keyword variables like dst_port or src_port from kemi? (specifically python in our case). Thanks, Enrico.

2 3

Re: [SR-Users] NATHELPER issue
by Konstantin Polyakov 23 Jul '18

23 Jul '18

Hello Ali, ACK is sent by UAC to the Contact which is received in OK from UAS. So from my point of view you need to fix that Contact in OK on your proxy. My NATDETECT looks like: if (nat_uac_test("19")) { fix_nated_contact(); } I call it for requests and responses. Best regards. Konstantin >Message: 23 >Date: Fri, 20 Jul 2018 11:13:42 +0300 >From: "Ali Taher" < ataher(a)vanrise.com > >To: < sr-users(a)lists.sip-router.org > >Subject: [SR-Users] NATHELPER issue >Message-ID: < 070901d42001$939be2b0$bad3a810$(a)vanrise.com > >Content-Type: text/plain; charset="utf-8" > >Hello, > > > >I'm using Kamailio 4.2 as proxy with nathelper enabled. > > > >Yet , the ACK packet sent from the proxy to the origination's private IP. > > > >The ACK is sent as reply on the following 200 OK sent from the origination : > > > > >8m2EJN41BN/6WSIP/2.0 200 OK > >From: <sip:+4444331234567@X.X.X.X;user=phone>;tag=XQBQNjvjgp4Ze > >To: <sip:+905362695933@172.16.45.65;user=phone>;tag=12033368836000 > >Via: SIP/2.0/UDP >X.X.X.X:5065;branch=z9hG4bK2959.233ecbc5eff949f946d8763ce25e5e6d.0;received= >X.X.X.X,SIP/2.0/UDP >X.X.X.X;received=X.X.X.X;rport=5060;branch=z9hG4bKN93cXvv26vDDN > >Record-Route: <sip:X.X.X.X:5065;lr;ftag=XQBQNjvjgp4Ze> > >Call-ID: CbeX8453909200habfGhEfElPce(a)BC00.XXXXXXXXXXXXXX > >CSeq: 125698370 INVITE > >Accept: application/sdp > >Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,UPDATE > >P-Charging-Vector: >icid-value=B0912C3D70-0720-09394507;icid-generated-at=BC00.XXXXXXXXXXXXXX.XX >;orig-ioi=MXXXXXXXXXXXXXX > >Content-Type: application/sdp > >Contact: <sip:172.16.45.65:5060;transport=UDP> > >Content-Length: 268 > > > >v=0 > >o=- 5838243 5838244 IN IP4 BC00.XXXXXXXXXXXXXX > >s=- > >c=IN IP4 172.16.45.144 > >t=0 0 > >a=sendrecv > >m=audio 47588 RTP/AVP 18 96 > >c=IN IP4 172.16.45.144 > >a=rtpmap:18 G729/8000 > >a=fmtp:18 annexb=yes > >a=rtpmap:96 telephone-event/8000 > >a=fmtp:96 0-15 > >a=maxptime:20 > > > >Following is the header of the sent ACK packet: > > > >Request-Line: ACK sip:172.16.45.65:5060;transport=UDP SIP/2.0 > >Record-Route: <sip:X.X.X.X:5065;lr;ftag=XQBQNjvjgp4Ze> > >Via: SIP/2.0/UDP >X.X.X.X:5065;branch=z9hG4bK2959.871535fd341bbe3099d0bf60d6460e18.0 > >Via: SIP/2.0/UDP >X.X.X.X;received=X.X.X.X;rport=5060;branch=z9hG4bKQUpy0jy90etjc > >Max-Forwards: 69 > >From: <sip:+4444331234567@X.X.X.X;user=phone>;tag=XQBQNjvjgp4Ze > >To: <sip:+905362695933@172.16.45.65;user=phone>;tag=12033368836000 > >Call-ID: CbeX8453909200habfGhEfElPce(a)BC00.XXXXXXXXXXXXXX > >CSeq: 125698370 ACK > >Content-Length: 0 > > > >Where X.X.X.X is Kamailio server public IP. > > > >Following is part of my config file : > > > >route { > >route(NATDETECT); > >record_route(); > > > > if(!mf_process_maxfwd_header("10")) { > > sl_send_reply("483", "Too Many Hops"); > > exit; > > } > > > > # Maybe some sanity_check() here. > > > > if(has_totag()) { > > > > if(loose_route()) { > > route(DLGURI); > > if(!t_relay()) > > sl_reply_error(); > > > > exit; > > } else { > > if(is_method("ACK")) { > > route(DLGURI); > > if(t_check_trans()) { > > t_relay(); > > } > > } else > > sl_send_reply("403", "Forbidden"); > > } > > exit; > > } > > > >..... > >} > > > > > >route[NATDETECT] { > >#!ifdef WITH_NAT > > force_rport(); > > if (nat_uac_test("19")) { > > if (is_method("REGISTER")) { > > fix_nated_register(); > > } else { > > add_contact_alias(); > > } > > setflag(FLT_NATS); > > } > >#!endif > > return; > >} > > > >route[DLGURI] { > >#!ifdef WITH_NAT > > if(!isdsturiset()) { > > handle_ruri_alias(); > > } > >#!endif > > return; > >} > > > >Can you please check why the ACK is still sent on private IP ? > > > >Thanks > >Ali Taher > > "Ali Taher" < ataher(a)vanrise.com >

2 1

Selectively enable / disable cdrs using acc module
by M S 23 Jul '18

23 Jul '18

Hi, I have a kamailio v5.0 setup where cdrs are enabled using acc module. Is there a way to enable / disable cdrs on per call basis in kamailio script? For example i want to allow cdrs only for offnet calls and disable them for onnet calls? May be a dialog flag configurable in module parameters to signal acc module whether or not to generate cdr for current dialog at the end of call?

2 5

Options for SIP traffic duplicating to third party tcp port
by Максим Баранов 23 Jul '18

23 Jul '18

Hello, what are the options for duplicating sip traffic to arbitrary tcp port in Kamailio?

3 5

forbidden domain not served
by eyas barhouk 22 Jul '18

22 Jul '18

Dears i'm using kamilio 5.2.0 as IMS with Zoiper client and RTP Engine when i'm trying to terminate a video call ,BYE message does not arrived to destination with error from S-cscf side "forbidden domain not served " has any one had the same issue before ? and is there any ideas about how to solve it ? ? thanks in advance

2 3

dialog module with dmq
by E. Schmidbauer 22 Jul '18

22 Jul '18

Is anyone using dialog module with DMQ to share dialogs across multiple kamailio instances? i've been testing it and it seems unreliable. sometimes the dialog data is sent from nodeA to nodeB, sometimes it is not. im wondering if im missing some settings or it's a bug. I tested latest master branch and version 5.1.4 Thanks! Emmanuel

3 2

$var(name) - Private memory variables
by Sergey Safarov 21 Jul '18

21 Jul '18

Hello I have faced when case when private var defined as $var(json_request) is share between different SIP messages. In my case first time this var is used from registration processing route. Then var with same name is used PUBLISH messge processing. And i be able to this value defined from registration processing. I expecting that vars is not shared between threads and message handling routes for var defined as $var(name). Is that not true? How i can prevent race condition between different message processing routes when two thread simultaneously change same variable? Sergey

3 5

uri==myself
by Karthik Srinivasan 20 Jul '18

20 Jul '18

Hello, Can someone explain to me why statement A returns True and statement B returns False. Statement A: is_myself("$ru") Statement B: uri == myself Isn't uri and $ru referencing the same data? With my current config i am expecting the is_myself to return True; i was expecting the same for Statement B but unfortunately it is returning False. Thanks, Karthik

2 11

← Newer
1
2
3
4
5
6
7
8
...
11
Older →

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

sr-users July 2018