sr-users

sr-users@lists.kamailio.org

23 participants
37378 discussions

ACK and Bye not relaying when record_route is not used
by Arun K R 03 Jun '24

03 Jun '24

Issue : Not getting relay of ACK and BYE to the next hop after the call is answered my Scenario : Asterisk ------->kamailio sip proxy-------------------> carrier (outgoing call) My carrier is not allowed to send the SIP packet with Record-Route header. So that I have removed record_route(). After that the call is getting connected. I am getting 200 OK (SDP) from carrier side and forwarded that to the Asterisk on the other side. As a response I am getting ACK from asterisk. But the kamailio is not forwarding the ACK to the carrier side. I understood this is because the record-route is not there. The same thing is happening for BYE also. The Bye is not forwarding to carrier side. Kindly suggest me a solution for this for relaying ACK and bye without Record-Route in kamailio Bellow is the 200 OK SDP I am sending back to asterisk 2024/06/02 10:27:04.756610 103.155.114.101:5060 -> 103.182.153.113:5060 SIP/2.0 200 OK Call-ID: 1d2897fc-8ae2-4835-b7ac-a96cc28adcc2 Via: SIP/2.0/UDP 103.182.153.113:5060 ;received=103.182.153.113;rport=5060;branch=z9hG4bKPj463fedcf-6258-4655-a53d-58ea57f144af To: <sip:09496381412@103.155.114.101 >;tag=6541fd97-665bfb9a2aea9a78-gm-po-lucentPCSF-109109 From: <sip:917946357720@gaesip.teleforce.in >;tag=8dba28f5-d250-48c6-99fc-35d84590cfc1 CSeq: 22823 INVITE Allow: INVITE,BYE,REGISTER,ACK,OPTIONS,CANCEL,SUBSCRIBE,NOTIFY,INFO,REFER,UPDATE Contact: <sip:lucentNGFS-115804@10.5.110.117:5060 ;alias=10.5.110.117~5060~1;x-afi=11> Content-Type: application/sdp Session-Expires: 7200;refresher=uas Supported: timer Content-Length: 248 v=0 o=LucentPCSF 130227946 130227946 IN IP4 103.155.114.101 s=- c=IN IP4 103.155.114.101 t=0 0 m=audio 12806 RTP/AVP 8 101 ------------------------------------------------------------------------------------------------------- The ACK I am getting back from asterisk is 2024/06/02 10:27:04.760392 103.182.153.113:5060 -> 103.155.114.101:5060 ACK sip:lucentNGFS-115804@103.155.114.101:5060;alias=10.5.110.117~5060~1;x-afi=11 SIP/2.0 Via: SIP/2.0/UDP 103.182.153.113:5060 ;rport;branch=z9hG4bKPjb7299c25-13d3-484e-8e78-e7c83620edce From: <sip:917946357720@gaesip.teleforce.in >;tag=8dba28f5-d250-48c6-99fc-35d84590cfc1 To: <sip:09496381412@103.155.114.101 >;tag=6541fd97-665bfb9a2aea9a78-gm-po-lucentPCSF-109109 Call-ID: 1d2897fc-8ae2-4835-b7ac-a96cc28adcc2 CSeq: 22823 ACK Max-Forwards: 70 User-Agent: Asterisk PBX 18.13.0 Content-Length: 0 Thanks Arun

3 3

StriShaken module compilation
by Sergio Charrua 01 Jun '24

01 Jun '24

Hello all! I am struggling on compiling StriShaken module on RHEL 9.2. So far, the module was compiled as well as libstirshaken. Below are the steps used to compile (as sudo) both library and module (I hope this may help someone) and, of course, correct me if I am wrong in any step or if there is a better way. Also, note that the RHEL 9,2 is in a VM environment without access to the WWW, instead it uses Red Hat Satellite to download packages (via Yum or DNF), if available. Lib LibKS download libks from https://github.com/signalwire/libks unzip move to dir created by Unzip run yum groupinstall "Development Tools" dnf install libuuid-devel libatomic openssl-devel cmake . make make install cp /usr/lib/pkgconfig/libks2.pc /usr/lib64/pkgconfig/. For module LibStirShaken: download https://github.com/signalwire/libstirshaken unzip move to dir if using OpenSSL3.0 or + edit file configure.ac and add after line 28: if test x$HAVE_OPENSSL = x1; then openssl_CFLAGS="$openssl_CFLAGS -DHAVE_OPENSSL"; /* PATCH FOR OPENSSL3 */ AC_MSG_CHECKING([for OpenSSL >= 3.0.0]) AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[ #include <openssl/opensslv.h> #if OPENSSL_VERSION_PREREQ(3,0) #error "you_have_version_3" #endif ]], [[]])], [ AC_MSG_RESULT([no]) ], [ AC_MSG_RESULT([yes]); AC_DEFINE(OPENSSL_SUPPRESS_DEPRECATED, 1, [disable openssl deprecated-function warnings]) ]) /* END OF PATCH */ else AC_MSG_ERROR([OpenSSL >= 1.0.1e and associated developement headers required]) fi run configure make sudo make install next, move to dir /root/kamailio/kamailio-5.7.4/src/modules/stirshaken cd /root/kamailio/kamailio-5.7.4/src/modules/stirshaken ln -s /root/stirshakenlib/libks-master/src/include/libks libks make make install All seem to compile OK , *but* when starting Kamailio I get the following errors: May 29 17:42:02 kamailio1 kamailio[248991]: ERROR: <core> [core/sr_module.c:599]: ksr_load_module(): could not open module </usr/local/lib64/kamailio/modules/stirshaken.so>: libstirshaken.so.1: cannot open shared object file: No such file or directory May 29 17:42:02 kamailio1 kamailio[248991]: CRITICAL: <core> [core/cfg.y:3915]: yyerror_at(): parse error in config file /usr/local/etc/kamailio/kamailio_stir_shaken_mod.cfg, line 106, column 12-26: failed to load module I haven't found a solution for this. Can anyone help? Thanks in advance! *Sérgio Charrua*

2 1

Parsing Error with SIP 607 Response
by Ghulam Mustafa 31 May '24

31 May '24

Hello Kamailio Community, I'm encountering a parsing error in Kamailio when receiving a SIP 607 "Unwanted" response. The relevant log entries are: May 31 12:32:09 k-proxy1 /usr/sbin/kamailio[320898]: ERROR: <core> [core/receive.c:378]: receive_msg(): core parsing of SIP message failed (36.53.xx.xx:5060/1) May 31 12:32:10 k-proxy1 /usr/sbin/kamailio[320895]: ERROR: <core> [core/parser/parse_fline.c:272]: parse_first_line(): parse_first_line: bad message (offset: 11) May 31 12:32:10 k-proxy1 /usr/sbin/kamailio[320895]: ERROR: <core> [core/parser/msg_parser.c:790]: parse_msg(): ERROR: parse_msg: message=<SIP/2.0 607#015#012Via: SIP/2.0/UDP 134.195.195.40:5060;branch=z9hG4bKc87a.ed6403ae1529f36b65171bf964604be0.0;i=2#015#012Via: SIP/2.0/UDP 127.0.0.8;branch=z9hG4bKsr-Sz6QPbTDsrqSQc7ys87Ds87VP37Ds87YG870sXCWo1G6ujo6oXzisr0isX7Dsr0isXCSZXcFujwtH.KOH.QqGXs09XNtw.dEJ5GhvjhauNHzwFIzl5c9wbfNG3oaHkl3#015#012From: "15516756486" <sip:15516756486@10.x.x.10>;tag=KXtSBZ1at71Hc#015#012To: <sip:99904441743709685@36.53.xx.xx;transport=udp>;tag=sbcsipuas_1_C35684_20240531083209909_sbc06#015#012Call-ID: a40d965d-99ec-123d-6f92-ecf4bbd64f6c#015#012Contact: <sip:36.53.xx.xx:5060>#015#012CSeq: 84025572 INVITE#015#012Server: sbc_5#015#012Content-Length: 0#015#012#015#012> And the actual SIP message is U 36.53.xx.xx:5060 -> 10.x.x.30:5060 #850 SIP/2.0 607. Via: SIP/2.0/UDP 134.195.195.40:5060 ;branch=z9hG4bKbdbd.95060a558d66b77d258b8d0799be4cf0.0;i=2. Via: SIP/2.0/UDP 127.0.0.8 ;branch=z9hG4bKsr-Sz6QPbTDsrqSQc7ys87Ds87VP37Ds87YG870sXCWo1G6ujo6oXzisr0isX7Dsr0isXCSZXcFujwtH.KOH.QqGXs09XNtw.dEJ5GhvjhauNHzwFCaHXyLA3G.SjwaAmdn. From: "13xxxxxxxxxx" <sip:13xxxxxxxxxx@10.x.x.10>;tag=pFFatBpUc75BH. To: <sip:441xxxxxxxxx@36.53.xx.xx ;transport=udp>;tag=sbcsipuas_1_C56639_20240531081932874_sbc04. Call-ID: e0d2f5fa-99ea-123d-6f92-ecf4bbd64f6c. Contact: <sip:36.53.xx.xx:5060>. CSeq: 84025194 INVITE. Server: sbc_5. Content-Length: 0. Any insights or suggestions would be greatly appreciated. Thank you! Mustafa

5 9

Access avp vars in a cancel? How to pass information from an INVITE to a CANCEL?
by Benoit Panizzon 31 May '24

31 May '24

Hi To determine, if rtpengine was engaged during an invite or not, I make use of rr params for all messages in following transactions and I set an avp for all messages in the current transaction. When the call is canceled, I would need to call rtpengine_delete to make sure rtpengine stops listening for rtp packets. Unfortunately, the avp I set during the INVITE, does not seem to be present while the CANCEL message is processed, despite to my understanding being in the same transaction. How can I pass some information from an INVITE to the corresponding CANCEL? Mit freundlichen Grüssen -Benoît Panizzon- -- I m p r o W a r e A G - Leiter Commerce Kunden ______________________________________________________ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web http://www.imp.ch ______________________________________________________

3 10

core dump on AWS with ~4000 TCP sockets
by David Villasmil 31 May '24

31 May '24

Hello all, I'm seeing core dumps (can't find them!) on AWS with lots of TCP sockets open (not related to load), kamailio dies randomly with: *May 30 14:31:03 sip-proxy /usr/sbin/kamailio[743739]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 142 May 30 14:31:03 sip-proxy /usr/sbin/kamailio[743542]: ALERT: <core> [main.c:788]: handle_sigs(): child process 743672 exited by a signal 11 May 30 14:31:03 sip-proxy /usr/sbin/kamailio[743542]: ALERT: <core> [main.c:791]: handle_sigs(): core was generated May 30 14:32:03 sip-proxy /usr/sbin/kamailio[743542]: CRITICAL: <core> [main.c:698]: sig_alarm_abort(): shutdown timeout triggered, dying...* before this happens, there's a ton of May 26 00:32:01 sip-proxy /usr/sbin/kamailio[74966]: ERROR: <core> [core/tcp_main.c:4591]: tcpconn_main_timeout(): connect 172.56.51.197:34846 failed (timeout) May 26 00:32:01 sip-proxy /usr/sbin/kamailio[74966]: ERROR: <core> [core/tcp_main.c:4591]: tcpconn_main_timeout(): connect 98.196.165.187:38593 failed (timeout) May 26 00:32:01 sip-proxy /usr/sbin/kamailio[74966]: ERROR: <core> [core/tcp_main.c:4591]: tcpconn_main_timeout(): connect 10.241.49.185:49372 failed (timeout) May 26 00:32:01 sip-proxy /usr/sbin/kamailio[74966]: ERROR: <core> [core/tcp_main.c:4591]: tcpconn_main_timeout(): connect 97.101.162.40:45248 failed (timeout) May 26 00:32:01 sip-proxy /usr/sbin/kamailio[74966]: ERROR: <core> [core/tcp_main.c:4591]: tcpconn_main_timeout(): connect 172.59.213.36:57074 failed (timeout) May 26 00:32:01 sip-proxy /usr/sbin/kamailio[74966]: ERROR: <core> [core/tcp_main.c:4591]: tcpconn_main_timeout(): connect 207.195.63.14:2521 failed (timeout) May 26 00:32:01 sip-proxy /usr/sbin/kamailio[74966]: ERROR: <core> [core/tcp_main.c:4591]: tcpconn_main_timeout(): connect 10.241.49.185:22155 failed (timeout) May 26 00:32:01 sip-proxy /usr/sbin/kamailio[74966]: ERROR: <core> [core/tcp_main.c:4591]: tcpconn_main_timeout(): connect 10.241.49.185:10339 failed (timeout) Regards, David Villasmil email: david.villasmil.work(a)gmail.com phone: +34669448337

2 1

Re: Via header force change protocol to TLS?
by David Villasmil 31 May '24

31 May '24

trying to use msg_apply_changes(); subst_hf("Via","/TCP/TLS/","f"); But as i don't seem to have access the top-most via, i can'it doesn't work... i cam change the incoming Via, but not the outgoing... I need this urgently.. any help anyone? > Sergey, > > Thanks for pointing me to the PR but that's not exactly what i need, let > me explain: > > We have an AWS an NLB on which our clients connect to and terminate TLS > connections and from then on into our proxies it is TCP. Now when clients > send invites (with TLS in their VIA as protocol) and we reply to them > (because the socket is TCP) I need to set the protocol on the Via to be > TLS. Otherwise, the client would not understand. This message or will > believe that it's not. about the same connection > > I haven't figured out a way of doing this since it can't get the actual > VIA that will be sent out. I've tried on the onsend_route (enabling > onsend_route_reply) > > Help is greatly appreciated! > > > Regards, > > David Villasmil > email: david.villasmil.work(a)gmail.com > phone: +34669448337 > > > On Thu, May 30, 2024 at 11:44 PM David Villasmil < > david.villasmil.work(a)gmail.com> wrote: > >> HEllo Sergey, >> >> i can send one. yes. >> >> Regards, >> >> David Villasmil >> email: david.villasmil.work(a)gmail.com >> phone: +34669448337 >> >> >> On Thu, May 23, 2024 at 5:14 PM Sergey Safarov <s.safarov(a)gmail.com> >> wrote: >> >>> Hi David >>> Could you send PCAP for an inbound call via TCP connection? >>> >>> Sergey >>> >>> On Thu, May 23, 2024 at 5:53 PM David Villasmil < >>> david.villasmil.work(a)gmail.com> wrote: >>> >>>> it's still in progress though. >>>> Regards, >>>> >>>> David Villasmil >>>> email: david.villasmil.work(a)gmail.com >>>> phone: +34669448337 >>>> >>>> >>>> On Thu, May 23, 2024 at 4:51 PM David Villasmil < >>>> david.villasmil.work(a)gmail.com> wrote: >>>> >>>>> Thanks, I'll check it out! >>>>> Regards, >>>>> >>>>> David Villasmil >>>>> email: david.villasmil.work(a)gmail.com >>>>> phone: +34669448337 >>>>> >>>>> >>>>> On Thu, May 23, 2024 at 4:16 PM Sergey Safarov <s.safarov(a)gmail.com> >>>>> wrote: >>>>> >>>>>> We have tested this PR using the Linphone app. >>>>>> So your case will be resolved using this PR. >>>>>> Need to enable HAproxy protocol headers. >>>>>> >>>>>> On Wed, May 22, 2024 at 4:36 PM Sergey Safarov <s.safarov(a)gmail.com> >>>>>> wrote: >>>>>> >>>>>>> Please try Kamailio PR >>>>>>> https://github.com/kamailio/kamailio/pull/3731 >>>>>>> >>>>>>> We have developed this PR for use case you have described. >>>>>>> We have tested Route and Record-Route headers not Via. >>>>>>> So will provide some review for this PR then will be fine. >>>>>>> >>>>>>> On Wed, May 22, 2024 at 2:22 PM David Villasmil < >>>>>>> david.villasmil.work(a)gmail.com> wrote: >>>>>>> >>>>>>>> Hello Sergey, >>>>>>>> >>>>>>>> Thanks for the suggestion. Not sure if his is what i'm looking for, >>>>>>>> allow me to explain further: >>>>>>>> We set up an NetworkLoadBalancer on AWS to offload tls on it. This >>>>>>>> Load balancer is a TLS listener on the outside and a TCP connection to the >>>>>>>> proxy inside. >>>>>>>> So when sending an INVITE to the connected client, the via has a >>>>>>>> TCP protocol like >>>>>>>> >>>>>>>> Via: SIP/2.0/TCP >>>>>>>> mydomain:port;branch=z9hG4bKf176.53ac8af0d7090a31e44548f15ea420ff.0 >>>>>>>> >>>>>>>> and the client (linphone) disconnects and tries to contact the >>>>>>>> proxy on that address on a TCP socket, which doesn't exist. I tried many >>>>>>>> solutions none of which actually work... last one setting $du =$du + >>>>>>>> ";transport=tls" and forcing the socket to the TCP socket to the load >>>>>>>> balancer, but of course i'm getting warnings about this. >>>>>>>> >>>>>>>> is this something that PR (not merged) would be addressing, i >>>>>>>> didn't see that. >>>>>>>> If not, is there a way of doing this without any trickery? >>>>>>>> >>>>>>>> Thanks! >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> David Villasmil >>>>>>>> email: david.villasmil.work(a)gmail.com >>>>>>>> phone: +34669448337 >>>>>>>> >>>>>>>> >>>>>>>> On Wed, May 22, 2024 at 12:16 PM Sergey Safarov < >>>>>>>> s.safarov(a)gmail.com> wrote: >>>>>>>> >>>>>>>>> Probable you need this PR >>>>>>>>> https://github.com/kamailio/kamailio/pull/3810 >>>>>>>>> >>>>>>>>> Or you can try >>>>>>>>> https://github.com/kamailio/kamailio/pull/3731 >>>>>>>>> In this PR we faced the same issue and solved this. >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, May 22, 2024 at 3:43 AM David Villasmil via sr-users < >>>>>>>>> sr-users(a)lists.kamailio.org> wrote: >>>>>>>>> >>>>>>>>>> Hello Anthony, did you solve this problem? I'm facing the same >>>>>>>>>> problem >>>>>>>>>> >>>>>>>>>> Thanks! >>>>>>>>>> Regards, >>>>>>>>>> >>>>>>>>>> David Villasmil >>>>>>>>>> email: david.villasmil.work(a)gmail.com >>>>>>>>>> phone: +34669448337 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Mon, Feb 5, 2018 at 5:57 AM Anthony Alba < >>>>>>>>>> ascanio.alba7(a)gmail.com> wrote: >>>>>>>>>> >>>>>>>>>>> I have kamailio behind a TLS termination proxy so the sockets >>>>>>>>>>> are correctly deduced to be TCP. However the clients only talk TLS to the >>>>>>>>>>> proxy and are confused when the top Via header added by Kamailio is TCP. Is >>>>>>>>>>> there a way for Kamailio to forcibly pretend its protocol is TLS? Like >>>>>>>>>>> advertised_address but "advertised_protocol" instead. >>>>>>>>>>> >>>>>>>>>>> (With pjsip testing: it has a flag use_tls which ignores TCP >>>>>>>>>>> from Kamailio and continues to use the persistent TLS transport to proxy. >>>>>>>>>>> Linphone fails because it tries to honor TCP in Via and is unable to >>>>>>>>>>> establish TCP transport). >>>>>>>>>>> >>>>>>>>>>> BTW I am using t_relay_to_tcp so Kamailio will return traffic to >>>>>>>>>>> the proxy as TCP even though the contact addresses specify transport=TLS. >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Kamailio (SER) - Users Mailing List >>>>>>>>>>> sr-users(a)lists.kamailio.org >>>>>>>>>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >>>>>>>>>>> >>>>>>>>>> __________________________________________________________ >>>>>>>>>> Kamailio - Users Mailing List - Non Commercial Discussions >>>>>>>>>> To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org >>>>>>>>>> Important: keep the mailing list in the recipients, do not reply >>>>>>>>>> only to the sender! >>>>>>>>>> Edit mailing list options or unsubscribe: >>>>>>>>>> >>>>>>>>>

1 0

Inbound Identity Verification Stir/Shaken
by tfayomi＠untangledtechnology.com 30 May '24

30 May '24

Hi All, I have a quick question regarding verification on incoming calls regarding the stir/shaken policy. I'm using the secsipid library to check the identity header, but the problem I'm running into is that there is no identity header in the invite from the incoming call (It's showing up as null). Have most carriers enabled passing along an identity header, or is this something that is still in the works for some of them. Would I need to request and get the certificate from the terminating carrier? I've tried using the auth_identity module to see if i need to use the verification functions to get/request the certificate, but I have had no luck so far. Would anyone be able to provide direction on how to request/get/pass along the identity header from an incoming call with stir/shaken. (I am using kamailio v5.6 and debian 12) Thanks in advance, Temi

4 6

Via header force change protocol to TLS?
by Anthony Alba 30 May '24

30 May '24

I have kamailio behind a TLS termination proxy so the sockets are correctly deduced to be TCP. However the clients only talk TLS to the proxy and are confused when the top Via header added by Kamailio is TCP. Is there a way for Kamailio to forcibly pretend its protocol is TLS? Like advertised_address but "advertised_protocol" instead. (With pjsip testing: it has a flag use_tls which ignores TCP from Kamailio and continues to use the persistent TLS transport to proxy. Linphone fails because it tries to honor TCP in Via and is unable to establish TCP transport). BTW I am using t_relay_to_tcp so Kamailio will return traffic to the proxy as TCP even though the contact addresses specify transport=TLS.

4 10

libstirshaken installation issues
by tfayomi＠untangledtechnology.com 30 May '24

30 May '24

Hi All, I am attempting to install the stirshaken module for kamailio and I ran into a couple issues installing the open source c library for libstirshaken. When I use the make command, I'm getting this error: src/stir_shaken.c: In function 'stir_shaken_is_key_trusted': src/stir_shaken.c:726:9: error: 'EVP_PKEY_cmp' is deprecated: Since OpenSSL 3.0 [-Werror=deprecated-declarations] 726 | if (!EVP_PKEY_cmp(pkey, candidate_pkey)) { | ^~ In file included from /usr/include/openssl/x509.h:29, from /usr/include/openssl/ssl.h:31, from /usr/include/libks2/libks/ks_ssl.h:25, from /usr/include/libks2/libks/ks.h:80, from include/stir_shaken.h:15, from src/stir_shaken.c:1: /usr/include/openssl/evp.h:1418:5: note: declared here 1418 | int EVP_PKEY_cmp(const EVP_PKEY *a, const EVP_PKEY *b); | ^~~~~~~~~~~~ At top level: cc1: note: unrecognized command-line option '-Wno-gnu-zero-variadic-macro-arguments' may have been intended to silence earlier diagnostics cc1: all warnings being treated as errors make: *** [Makefile:1337: src/stir_shaken.lo] Error 1 I tried going into the stir_shaken file and changing EVP_PKEY_cmp to EVP_PKEY_eq, but it just brings up more deprecation errors. I also tried rolling back the openssl version on my machine to openssl version 1.1 and changing EVP_PKEY_eq back to EVP_PKEY_cmp, but the same error persists. Is there any way to resolve this error, or is there another library that can be used to get the stirshaken module for kamailio? Thanks in advance, Temi

6 7

Is udp_mtu and udp_mtu_try_proto broken in kamailio v5.8
by Supreeth Herle 30 May '24

30 May '24

Hello, I have a dockerized IMS setup using kamailio from git commit id 4fb8accc6747ad56fec3dc84d70cb2b8bbd7316e (tag 5.8.x), where I am seeing an issue faced by one of the users of the dockerized IMS. The issue is that the SIP request (in UDP) even though it exceed the MTU of 1300 (udp_mtu=1300 and udp_mtu_try_proto=TCP) the SIP request from P-CSCF is not sent out as a TCP. The pcap and P-CSCF logs in debug can be found in the github issue - https://github.com/herlesupreeth/docker_open5gs/issues/316#issuecomment-213… IP of the containers are follows: P-CSCF - 172.22.0.21 S-CSCF - 172.22.0.20 SIP Client - 192.168.101.x P-CSCF is configured with udp_mtu=1300 and udp_mtu_try_proto=TCP In the pcap you can notice that the SIP NOTIFY originating from S-CSCF is forwarded to P-CSCF (packet no. 698) and packet length is 2716. At this point P-CSCF should have tried to convey the SIP packet to SIP client via TCP. But I dont see any TCP connection establishment either and eventually request times out (packet 1147). [image: image.png] Any help or insights would be highly appreciated. Thanks and Regards, Supreeth

1 0

Jump to page:

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