sr-users

sr-users@lists.kamailio.org

42 participants
37519 discussions

Question about UAC and PUA modules routing behavior
by Jean-Francois Lemieux 03 Jan '23

03 Jan '23

Hello, I have some trouble to figure out how routing works when the request coming from the kamailio itself (used as a user agent per example) .I try to use presence PUA... modules. The issue I have is the NOTIFY requests aren't sent to the good destination; it doesn't seems to obey to the contact or other informations when the device did a SUBSCRIBE. I don't want to ask to troubleshoot the presence module directly I just want to know how Kamailio deals with request coming from Kamailio itself (in the case of a NOTIFY generated by PUA_... modules My mains questions are: Does the pua modules when generating request like NOTIFY will pass through request_route ? Does the pua modules when generating request like NOTIFY will be sent only when t_relay() is used or UA kamailio based request bypass all the logic of the Kamailio proxy behavior ? I'm trying to understand if I can modify the NOTIFY request to change destination before the "routing decision" is made by Kamailio Kamailio 5.6.0 used as : -proxy to remote pbx for call dialog -registrar/location server -media relaying and nat management -...and I try to use it as a presence server instead to use the pbx behind kamailio

3 2

Steering egress on replies
by Alex Balashov 03 Jan '23

03 Jan '23

Hi, Happy New Year! From what I understand, replies are always sent back out of the listener on which they were received, though `reply_to_via` (off by default) can override this and cause the exit listener to be recalculated based on a real-time assessment of the best way to reach the last Via hop. Two questions arise: 1) If turning `mhomed` off, can `$fs` be used to override the exit interface of locally generated replies, too? If so, where should it be done? In a request_route prior to a send_reply() / sl_send_reply() / t_reply() call? Or should it be done inside a local reply route or onsend_route? 2) Does this differ for locally generated replies vs. relayed replies, either statefully or statelessly? Thanks! -- Alex -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/

2 1

Registration Proxy
by nutxase 02 Jan '23

02 Jan '23

Hi Guys, can someone point me in the right direction as to how i can use kamailio as a registration proxy similar to how opensips does mid_registrar? i want to proxy all sip registrations through kamailio to asterisk or freeswitch Sent with [Proton Mail](https://proton.me/) secure email.

3 2

Happy New Year 2023!
by Daniel-Constantin Mierla 01 Jan '23

01 Jan '23

A Happy, Peaceful And Prosperous Year 2023 to everyone using Kamailio and helping to improve the project! Looking forward to meeting many of you around this world during 2023 and collaborating in a friendly environment! Daniel -- Daniel-Constantin Mierla www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - www.asipto.com Kamailio World Conference - June 5-7, 2023 - www.kamailioworld.com

1 0

Re: Direct Routing, SIP, INVITE TO TEAMS (400 BAD REQUEST)
by Lewis Hutchinson 30 Dec '22

30 Dec '22

Hi Brandon Apologies if you have provided this but do you have a PCAP of the INVITE / 400 Bad Request rather than the Pastebin of the INVITE The last time I had this was because of a missing /r/n on the SDP granted it was not with teams but still difficult to track down. Also, what is the MTU Size, have you checked to see if the is causing packet fragmentation and manifesting in a Bad Request. Are there any clues in the Teams - Call Analytics. Regards Lewis -----Original Message----- From: sr-users-request(a)lists.kamailio.org <sr-users-request(a)lists.kamailio.org> Sent: 29 December 2022 20:17 To: sr-users(a)lists.kamailio.org Subject: sr-users Digest, Vol 211, Issue 67 Send sr-users mailing list submissions to sr-users(a)lists.kamailio.org To subscribe or unsubscribe via email, send a message with subject or body 'help' to sr-users-request(a)lists.kamailio.org You can reach the person managing the list at sr-users-owner(a)lists.kamailio.org When replying, please edit your Subject line so it is more specific than "Re: Contents of sr-users digest..." Today's Topics: 1. Re: Direct Routing, SIP, INVITE TO TEAMS (400 BAD REQUEST) (Brandon Armstead) 2. Re: Direct Routing, SIP, INVITE TO TEAMS (400 BAD REQUEST) (Brandon Armstead) ---------------------------------------------------------------------- Message: 1 Date: Thu, 29 Dec 2022 12:15:16 -0800 From: Brandon Armstead <brandon(a)cryy.com> Subject: [SR-Users] Re: Direct Routing, SIP, INVITE TO TEAMS (400 BAD REQUEST) To: Henning Westerholt <hw(a)gilawa.com> Cc: "Kamailio (SER) - Users Mailing List" <sr-users(a)lists.kamailio.org> Message-ID: <CABAX3EoF+hfruLiV2Nh_g117_q8diaKxVEyp5hMFO=wyKbQidQ(a)mail.gmail.com> Content-Type: multipart/alternative; boundary="0000000000005692d905f0fd2538" Henning, There was no reply (reason) available in my case. - Brandon On Thu, Dec 29, 2022 at 11:48 AM Henning Westerholt <hw(a)gilawa.com> wrote: > Hello, > > > > as mentioned before, have a look to the 400 reply reason phrase. This > was done quite good from their side, better than many other vendors. > > Usually, Teams is not too bad if you are using a defined > infrastructure that do not introduce too many variables. We are > usually using a B2BUA in our customer projects for that purpose. > > > > Cheers, > > > > Henning > > > > -- > > Henning Westerholt - > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fskal > atan.de%2Fblog%2F&data=05%7C01%7Clewis.hutchinson%40missionlabs.co.uk% > 7Ce1670c8a21444edf0ed408dae9f91fac%7C97c26f550a7a4661bd8f7b43b50d3f2b% > 7C0%7C0%7C638079553431377130%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM > DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdat > a=QU%2BzOgPdbmRYh51a9PvptIvVjnTZrGxT8z1G7b2RRGQ%3D&reserved=0 > > Kamailio services - > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgila > wa.com%2F&data=05%7C01%7Clewis.hutchinson%40missionlabs.co.uk%7Ce1670c > 8a21444edf0ed408dae9f91fac%7C97c26f550a7a4661bd8f7b43b50d3f2b%7C0%7C0% > 7C638079553431377130%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQI > joiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=PuDqkZ > QCj2IlxvRsLQGoKFv19K3uVE5RBxvcPKPODwQ%3D&reserved=0 > > > > *From:* Brandon Armstead <brandon(a)cryy.com> > *Sent:* Thursday, December 29, 2022 7:52 PM > *To:* Kamailio (SER) - Users Mailing List > <sr-users(a)lists.kamailio.org> > *Subject:* [SR-Users] Re: Direct Routing, SIP, INVITE TO TEAMS (400 > BAD > REQUEST) > > > > Alex & Kaufman, > > > > Appreciate the feedback. The pastebin is one example of about > 1000+ iterations literally of changes. So I'm finally reaching out > :). I haven't tested the socket attribute in record-route change, I > will try this now. As for the angle brackets I've tried with and > without, etc (already) to no effect. The SDP unknown media type seems > to be a Poly thing, so I > *want* to rule this out as its not in my other SDP's and still receive > 400 bad request. > > One more iteration here we go... please feel free to let me know if > you have any other thoughts on the matter :). > > > > Thanks! > > > > - Brandon > > > > On Thu, Dec 29, 2022 at 8:08 AM Alex Balashov > <abalashov(a)evaristesys.com> > wrote: > > Yeah, the grammar says that rr-params are just generic-params, in > which case it's not. I didn't see that -- nicely spotted! > > I think that may be the basis of the 400 Bad Request. I'd be shocked > if it weren't. > > The broken clock of "Microsoft SIP" can still be right twice a day. > > > On Dec 29, 2022, at 10:31 AM, Kaufman <bkaufman(a)bcmone.com> wrote: > > > > In your top Record-Route you have: > > > > socket=; > > > > Not sure if that is legal. > > > > Kaufman > > > > -----Original Message----- > > From: Alex Balashov <abalashov(a)evaristesys.com> > > Sent: Thursday, December 29, 2022 9:02 AM > > To: Kamailio (SER) - Users Mailing List > > <sr-users(a)lists.kamailio.org> > > Subject: [SR-Users] Re: Direct Routing, SIP, INVITE TO TEAMS (400 > > BAD > REQUEST) > > > > Sorry to hear you're having to interoperate with Teams. It's a > > unique > form of sadism I wouldn't wish upon anyone. > > > > A few theories: > > > > 1) Microsoft doesn't like the "bare" Contact header-value here: > > > > Contact: > sip:+MY_FROM_PHONE_NUMBER_HERE@MY_FQDN_WAS_HERE:5061;transport=tls > > > > Unlike the careted one right above: > > > > P-Asserted-Identity: > > <sip:+MY_FROM_PHONE_NUMBER_HERE@MY_FQDN_WAS_HERE> > > > > A bare URI absent other header-params is of course completely legal, > > but > I'm really trying to get inside the imaginary world of antisocial > "Microsoft SIP" here. > > > > 2) Could it be that antisocial "Microsoft SIP" sends 400 as a way of > objecting to something in the SDP, e.g. where a non-demented SIP stack > would send "488 Not Acceptable Here" or "415 Unsupported Media Type"? > > > > I know you've said you tried multiple clients to rule that out, but > > I > wonder if the thing it's objecting to hasn't been ruled out that way. > > > > 3) I saw this media line in the SDP: > > > > m=application 41356 <unknown media type> > > > > What's that? > > > > -- Alex > > > >> On Dec 29, 2022, at 9:51 AM, Brandon Armstead <brandon(a)cryy.com> wrote: > >> > >> Outbound calls from my SBC into Teams (Polycom -> SBC -> Teams) > >> always > result in a 400 BAD REQUEST. > >> Example invite below: > >> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fn > >> am11.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%25 > >> 2Fpast&data=05%7C01%7Clewis.hutchinson%40missionlabs.co.uk%7Ce1670c > >> 8a21444edf0ed408dae9f91fac%7C97c26f550a7a4661bd8f7b43b50d3f2b%7C0%7 > >> C0%7C638079553431377130%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDA > >> iLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sda > >> ta=5v20CvNnmdiHwfWMBX6tgjMlE1i2aKpFgTnuVFfpyl0%3D&reserved=0 > >> ebin.com%2FF1G1Ce59&data=05%7C01%7Cbkaufman%40bcmone.com%7C55672dbf > >> 739 > >> a4ff447f008dae9b0c9b2%7Cafc1818e7b6848568913201b9396c4fc%7C1%7C0%7C > >> 638 > >> 079242759152531%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjo > >> iV2 > >> luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Cbff6B4g > >> Nr8 > >> A9zs89smJ129y8IyNM9%2B3zVkGhlzpa54%3D&reserved=0 > >> I've taken care to make sure numbers are all E.164 format in > From/To/Contact. I've also taken care to make sure that FQDN is used > in Contact and Record-Route header. > >> I've tried many different variations and have followed the SIP > information here: > >> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fn > >> am11.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%25 > >> 2Flear&data=05%7C01%7Clewis.hutchinson%40missionlabs.co.uk%7Ce1670c > >> 8a21444edf0ed408dae9f91fac%7C97c26f550a7a4661bd8f7b43b50d3f2b%7C0%7 > >> C0%7C638079553431377130%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDA > >> iLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sda > >> ta=ELk0UD1Pleq%2FG9j1%2BT18tiuFe0yjflimR9ztnW%2F7oPM%3D&reserved=0 > >> n.microsoft.com%2Fen-us%2Fmicrosoftteams%2Fdirect-routing-protocols > >> -si > >> p&data=05%7C01%7Cbkaufman%40bcmone.com%7C55672dbf739a4ff447f008dae9 > >> b0c > >> 9b2%7Cafc1818e7b6848568913201b9396c4fc%7C1%7C0%7C638079242759152531 > >> %7C > >> Unknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6I > >> k1h > >> aWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=GO26A9FOOoS42yMCWPPGo5PkKo > >> 75c > >> kjSJSkjAeYRsU0%3D&reserved=0 I've also tried several different > >> clients (Bria, Polycom CCX 600, Grandstream, etc) to see if maybe > >> it was > something in the SDP or otherwise causing an issue. > >> SIP Transport is TLS, RTP is SRTP > >> I might also add that OPTION pings are active and Direct Routing > Endpoint is active, so this is successful. I also am able to receive > calls FROM teams to my IP phone(s) without issue. It is only when I > try and call INTO teams (INVITE -> Microsoft Teams) that I always > receive a 400 BAD REQUEST to my INVITE. > >> Any help is appreciated, thank you! > >> > >> - Brandon > >> > >> __________________________________________________________ > >> 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: > > > > -- > > Alex Balashov | Principal | Evariste Systems LLC > > > > Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) > > Web: > https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.e > varistesys.com%2F&data=05%7C01%7Clewis.hutchinson%40missionlabs.co.uk% > 7Ce1670c8a21444edf0ed408dae9f91fac%7C97c26f550a7a4661bd8f7b43b50d3f2b% > 7C0%7C0%7C638079553431377130%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM > DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdat > a=hbww6wEEztE85YqxcN92bpMR%2BkiI9%2BE3jF1i6fQpjEk%3D&reserved=0, > > https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.c > srpswitch.com%2F&data=05%7C01%7Clewis.hutchinson%40missionlabs.co.uk%7 > Ce1670c8a21444edf0ed408dae9f91fac%7C97c26f550a7a4661bd8f7b43b50d3f2b%7 > C0%7C0%7C638079553431377130%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD > AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata > =4E7a5ZxSvttBiMxl1VTtolmTvS4T5VGZHA00CsbPR2c%3D&reserved=0 > > > > __________________________________________________________ > > 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: > > __________________________________________________________ > > 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: > > -- > Alex Balashov | Principal | Evariste Systems LLC > > Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) > Web: > https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.e > varistesys.com%2F&data=05%7C01%7Clewis.hutchinson%40missionlabs.co.uk% > 7Ce1670c8a21444edf0ed408dae9f91fac%7C97c26f550a7a4661bd8f7b43b50d3f2b% > 7C0%7C0%7C638079553431377130%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM > DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdat > a=hbww6wEEztE85YqxcN92bpMR%2BkiI9%2BE3jF1i6fQpjEk%3D&reserved=0, > https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.c > srpswitch.com%2F&data=05%7C01%7Clewis.hutchinson%40missionlabs.co.uk%7 > Ce1670c8a21444edf0ed408dae9f91fac%7C97c26f550a7a4661bd8f7b43b50d3f2b%7 > C0%7C0%7C638079553431377130%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD > AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata > =4E7a5ZxSvttBiMxl1VTtolmTvS4T5VGZHA00CsbPR2c%3D&reserved=0 > > __________________________________________________________ > 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

Direct Routing, SIP, INVITE TO TEAMS (400 BAD REQUEST)
by Brandon Armstead 29 Dec '22

29 Dec '22

Outbound calls from my SBC into Teams (Polycom -> SBC -> Teams) always result in a 400 BAD REQUEST. Example invite below: https://pastebin.com/F1G1Ce59 I've taken care to make sure numbers are all E.164 format in From/To/Contact. I've also taken care to make sure that FQDN is used in Contact and Record-Route header. I've tried many different variations and have followed the SIP information here: https://learn.microsoft.com/en-us/microsoftteams /direct-routing-protocols-sip I've also tried several different clients (Bria, Polycom CCX 600, Grandstream, etc) to see if maybe it was something in the SDP or otherwise causing an issue. SIP Transport is TLS, RTP is SRTP I might also add that OPTION pings are active and Direct Routing Endpoint is active, so this is successful. I also am able to receive calls FROM teams to my IP phone(s) without issue. It is only when I try and call INTO teams (INVITE -> Microsoft Teams) that I always receive a 400 BAD REQUEST to my INVITE. Any help is appreciated, thank you! - Brandon

5 9

Remove all Via Header or create custome Via Header
by Benoit Panizzon 27 Dec '22

27 Dec '22

Hi out there! While experimenting with the listen and adverize 'hostname' option I came across a voice switch, which I suppose fails if the Via header is not an IPv4 address. There is a record_route_advertised_address(address) in the RR module, to set a customer Record-Route Header. Is there something similar for the Via header so I could try if having an IP address instead of a hostname in the top-most Via would solve the issue? Or is there a way to remove all via header? Remove_hf("Via") in the branch route trigger garbles the From: HF. 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 4

Proxy edge
by Giovanni Iamonte 26 Dec '22

26 Dec '22

Dear List We have configured kamailio to work as a proxy edge and register. As a proxy edge cfg file we have used the example *edge_websocket.cfg.** * We are developing two different client the first one based on *PJSIP* and the other one based *JsSIP*. Client PJSIP (no websockets) everything work perfectly, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, MESSAGE, INVITE Client JsSIP (with websockets) The REGISTER, SUBSCRIBE works, the NOTIFY does not work. In more in details we have: Browser Proxy Edge Register Client JsSIP Websocket | | | | | | | ----------Register-----------> | -----------Register----------> | | <----------200 OK ----------- | <----------200 OK ----------- | | | | | ----------Subscribe----------> | -----------Subscribe---------> | | <----------200 OK ----------- | <----------200 OK ----------- | | | | | X<--- | <----------NOTIFY ----------- | | | | As you can see the NOTIFY start from Register and reach the proxy, beloe the Register log file and the sip messages. Could somebody put me in the right direction. Thanks Bye *Log File* Dec 20 10:51:58 kr-server /usr/sbin/kamailio[87875]: DEBUG: <core> [core/tcp_read.c:1533]: tcp_read_req(): content-length=0 Dec 20 10:51:58 kr-server /usr/sbin/kamailio[87875]: DEBUG: <core> [core/parser/parse_fline.c:249]: parse_first_line(): first line type 2 (reply(status)) flags 1 Dec 20 10:51:58 kr-server /usr/sbin/kamailio[87875]: DEBUG: <core> [core/parser/msg_parser.c:689]: parse_msg(): SIP Reply (status): Dec 20 10:51:58 kr-server /usr/sbin/kamailio[87875]: DEBUG: <core> [core/parser/msg_parser.c:690]: parse_msg(): version: <SIP/2.0> Dec 20 10:51:58 kr-server /usr/sbin/kamailio[87875]: DEBUG: <core> [core/parser/msg_parser.c:692]: parse_msg(): status: <478> Dec 20 10:51:58 kr-server /usr/sbin/kamailio[87875]: DEBUG: <core> [core/parser/msg_parser.c:694]: parse_msg(): reason: <Unresolvable destination (478/SL)> Dec 20 10:51:58 kr-server /usr/sbin/kamailio[87875]: DEBUG: <core> [core/parser/parse_hname2.c:301]: parse_sip_header_name(): parsed header name [Via] type 1 *Sip Messages* *REGISTER* sip:sip-register.quintetto.it SIP/2.0 Via: SIP/2.0/WSS 13569868356.invalid;branch=z9hG4bK7825787 Max-Forwards: 69 To: <sip:quintetto00@sip-register.quintetto.it> From: "quintetto00" <sip:quintetto00@sip-register.quintetto.it>;tag=2tnuk9btmp Call-ID: unrnseei8924hf67khoi3g CSeq: 2 REGISTER Authorization: Digest algorithm=MD5, username="quintetto00", realm="sip-register.quintetto.it", nonce="Y6GUq2Ohk3//HTza7ZYMfd85XMdavgnc", uri="sip:sip-register.quintetto.it", response="c9cc56d2d5e36b0a68873c1d5258d062" Contact: <sip:quintetto00@13569868356.invalid;transport=ws>;+sip.ice;reg-id=1;+sip.instance="<urn:uuid:64e71c57-fd55-4868-be2b-a4a3fa546ac8>";expires=3600 Expires: 3600 Allow: INVITE,ACK,CANCEL,BYE,UPDATE,MESSAGE,OPTIONS,REFER,INFO,NOTIFY,SUBSCRIBE,PUBLISH Supported: path,gruu,outbound User-Agent: JsSIP 3.10.0 Content-Length: 0 SIP/2.0 *200 OK* Via: SIP/2.0/WSS 13569868356.invalid;rport=37566;received=192.168.100.192;branch=z9hG4bK7825787 To: <sip:quintetto00@sip-register.quintetto.it>;tag=2b789d0fa67ad6c2da65f0cce35dd60b.71a84df9 From: "quintetto00" <sip:quintetto00@sip-register.quintetto.it>;tag=2tnuk9btmp Call-ID: unrnseei8924hf67khoi3g CSeq: 2 REGISTER Contact: <sip:quintetto00@13569868356.invalid;transport=ws>;expires=3600;+sip.instance="<urn:uuid:64e71c57-fd55-4868-be2b-a4a3fa546ac8>";reg-id=1 Server: kamailio (5.6.2 (x86_64/linux)) Content-Length: 0 *SUBSCRIBE* sip:quintetto03@sip-register.quintetto.it SIP/2.0 Via: SIP/2.0/WSS 13569868356.invalid;branch=z9hG4bK3648599 Max-Forwards: 69 To: <sip:quintetto03@sip-register.quintetto.it> From: "quintetto00" <sip:quintetto00@sip-register.quintetto.it>;tag=o261bh2uh7 Call-ID: 4beh90hur8hdhptnbjt8 CSeq: 5813 SUBSCRIBE Proxy-Authorization: Digest algorithm=MD5, username="quintetto00", realm="sip-register.quintetto.it", nonce="Y6GU+mOhk86y3fnrMzoKgiVAdkaTvBId", uri="sip:quintetto03@sip-register.quintetto.it", response="04ca6d83661ac338810baa95ffaa568b" Event: presence Expires: 3600 Accept: application/pidf+xml, application/xpidf+xml Contact: <sip:quintetto00@13569868356.invalid;transport=ws> Content-Type: application/pidf+xml Allow: INVITE,ACK,CANCEL,BYE,UPDATE,MESSAGE,OPTIONS,REFER,INFO,NOTIFY,SUBSCRIBE,PUBLISH Supported: outbound User-Agent: JsSIP 3.10.0 Content-Length: 35 SIP/2.0 *200 OK* Record-Route: <sip:192.168.100.24:15006;transport=tcp;r2=on;lr> Record-Route: <sip:192.168.100.24:16005;transport=ws;r2=on;lr> Via: SIP/2.0/WSS 13569868356.invalid;rport=37566;received=192.168.100.192;branch=z9hG4bK3648599 To: <sip:quintetto03@sip-register.quintetto.it>;tag=c906ce7d8b5c7cc84a3505ebe369640b-e45527ec From: "quintetto00" <sip:quintetto00@sip-register.quintetto.it>;tag=o261bh2uh7 Call-ID: 4beh90hur8hdhptnbjt8 CSeq: 5813 SUBSCRIBE Expires: 3600 Contact: <sip:192.168.100.23:15006;transport=tcp> Server: kamailio (5.6.2 (x86_64/linux)) Content-Length: 0 *NOTIFY*.sip:quintetto00@13569868356.invalid;transport=ws.SIP/2.0 Via:.SIP/2.0/TCP.1 92.168.100.23:15 006;branch=z9hG4bK28ad.a5d3bdf6000000000000000000000000.0 To: <sip:quintetto00@sip-register.quintetto.it>;tag=o261bh2uh7 From: <sip:quintetto03@sip-register.quintetto.it>;tag=c906ce7d8b5c7cc84a3505ebe369640b-e45527ec CSeq : 2 NOTIFY Call-ID:.4beh90hur8h dhptnbjt8 Route : <sip:192.168.1 00.24:15006;transport=tcp;r2=on;lr>,.<sip:192.16 8.100.24:16005;transport=ws;r2=on;lr> Content-Length:.0 User-Agent: kamailio.(5.6.2.(x86_64/li nux)) Max-Forwards:.70 Event: presence Contact:.<sip:192.168.100.23:15006;transport=tcp> Subscription-State: active;expires= 3600 SIP/2.0.478.Unresolvable.destination.(478/SL) Via: SIP/2.0/TC P.192.168.100.23 :15006;branch=z9hG4bK28ad.a5d3bdf6000000000000000000000000.0;rport=38019 To:.<sip:quintetto00@s ip-register.quintetto.it>;tag=o261bh2uh7 From: <sip:quintetto03 @sip-register.quintetto.it>;tag=c906ce7d8b5c7cc84a3505ebe369640b-e45527ec CSeq: 2 NOTIFY Call-ID: 4beh90hur8hdhptnbjt8 Server :.kamailio.(5.6.2.(x86_64/linux)) Content-Length: 0 SIP/2.0.478.Unresolvable.destination.(478/TM) Via: SIP/2.0/TC P.192.168.100.23:15006;branch=z9hG4bK28ad.a5d3bdf6000000000000000000000000.0;rport=38019 To: <sip:quintetto00@s ip-register.quintetto.it>;tag=o261bh2uh7 From: <sip:quintetto03 @sip-register.quintetto.it>;tag=c906ce7d8b5c7cc84a3505ebe369640b-e45527ec CSeq: 2 NOTIFY Call-ID: 4beh90hur8hdhptnbjt8 Server : kamailio.(5.6.2.(x86_64/linux)) Content-Length: 0 -- ------------------------------------------------------------------------ Ing. Giovanni Iamonte Developments and technologies area Quintetto Srl Via Monte Navale, 1 10015 - Ivrea (TO)  mobile: +39 393 9196310  tel: +39 0165 1845290  e-mail: giovanni.iamonte(a)quintetto.it  web: www.quintetto.it

3 4

ACK received instead of Status Code
by Waqar 40 26 Dec '22

26 Dec '22

Dear All, Attached in this email, is the screenshot of Kamailio logs for a call that did not originate. When Kamailio sends the call to the media destination which is an asterisk server, it should start sending status codes 100, 183, and 180 but instead, it sends ACK and the call did not originate. This happens only for some calls and I want to know why this is happening. Also, I want to identify these cases and do some further logic like trying some other media destination. How can I do that? [image: image.png] Regards, Vicky

1 0

Re: Call drops after 1 minute
by James Browne 23 Dec '22

23 Dec '22

Hi Christian I read your trace. There's no ACK after the SIP-200 response. It's cumbersome to read the trace because the client and server are at the same IP address, but I did it anyway. There's no ACK after the SIP-200 response, so it looks like the client (213.52.37.107) either doesn't sent it, or sends it directly to the server (213.52.37.107, the same IP address) without properly using the RR header field in the SIP-200 response. If you can set up a similar test and have a different host set up for the client and server (instead of 213.52.37.107 for both), and if you then trace the traffic again at all hosts, then you may find the rogue ACK request or be able to prove that the client never sent it (which might prove a broken client). When you use the client and server at the same IP address, it's not always straightforward to trace any traffic that might go directly from client to server, because it won't leave any network interface. Also I find strange that your call ends after "about a minute or so". I expect that they should end after about 31.5 seconds. It's almost certainly a SIP problem, and not any RTP/rtpproxy problem, so I recommend that you focus on the SIP. (I wrote this message before noticing that the thread is two weeks old.) James On Wed, 7 Dec 2022 at 08:41, Henning Westerholt <hw(a)gilawa.com> wrote: > > Hello, > > > > it looks that the 200 OK is not properly transmitted, as they seem to be retransmits. > > Maybe you should read a bit about SIP if you have not done it yet. It will help you debugging this problem (and probably others in the future). 😉 > > > > Cheers, > > > > Henning > > > > -- > > Henning Westerholt – https://skalatan.de/blog/ > > Kamailio services – https://gilawa.com > > > > From: Christian B Wiik <cbw(a)itf-as.no> > Sent: Wednesday, December 7, 2022 9:13 AM > To: Henning Westerholt <hw(a)gilawa.com> > Cc: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org> > Subject: Re: [SR-Users] Call drops after 1 minute > > > > Link to entire trace: > > > > https://docs.google.com/document/d/1yWFJ_Cv13p5cYk-d8m5HMBSeLalkutV0cKZHjHf… > > > > -- > > Regards > > Christian > > > > > > ons. 7. des. 2022 kl. 08:57 skrev Henning Westerholt <hw(a)gilawa.com>: > > Hi Christian, > > > > this ACK is the reply to the 407 and not the relevant one for the dialog. > > > > Please have a look to the full SIP dialog. > > > > Cheers, > > > > Henning > > > > -- > > Henning Westerholt – https://skalatan.de/blog/ > > Kamailio services – https://gilawa.com > > > > From: Christian B Wiik <cbw(a)itf-as.no> > Sent: Wednesday, December 7, 2022 8:14 AM > To: Henning Westerholt <hw(a)gilawa.com> > Cc: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org> > Subject: Re: [SR-Users] Call drops after 1 minute > > > > Thanks Henning. > > > > These are the first 3 packets filtering on my user. I see the ACK but I'm not able to spot the error. > > > > U 213.52.37.107:50336 -> 10.1.2.10:5060 #1 > INVITE sip:kmm@sip2.itf-as.com SIP/2.0..Via: SIP/2.0/UDP 213.52.37.107:35270;rport;branch=z9hG4bKPj398365dc9 > 706413f868bdd222cadbed8..Max-Forwards: 70..From: <sip:cbwlap@sip2.itf-as.com>;tag=4183d760c26e4531a7a39f45d1 > 4fb4c6..To: <sip:kmm@sip2.itf-as.com>..Contact: <sip:cbwlap@213.52.37.107:35270;ob>..Call-ID: b3dd380f0c1d4e > 0ebdd7fc223710d938..CSeq: 23860 INVITE..Route: <sip:sip2.itf-as.com;lr>..Allow: PRACK, INVITE, ACK, BYE, CAN > CEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS..Supported: replaces, 100rel, timer, norefersu > b..Session-Expires: 1800..Min-SE: 90..User-Agent: MicroSIP/3.21.3..Content-Type: application/sdp..Content-Le > ngth: 345....v=0..o=- 3879388988 3879388988 IN IP4 213.52.37.107..s=pjmedia..b=AS:84..t=0 0..a=X-nat:0..m= > audio 35276 RTP/AVP 8 0 101..c=IN IP4 213.52.37.107..b=TIAS:64000..a=rtcp:35277 IN IP4 213.52.37.107..a=send > recv..a=rtpmap:8 PCMA/8000..a=rtpmap:0 PCMU/8000..a=rtpmap:101 telephone-event/8000..a=fmtp:101 0-16..a=ssrc > :1053777612 cname:28d400de4b7d5918.. > # > U 10.1.2.10:5060 -> 213.52.37.107:50336 #2 > SIP/2.0 407 Proxy Authentication Required..Via: SIP/2.0/UDP 213.52.37.107:35270;rport=50336;branch=z9hG4bKPj > 398365dc9706413f868bdd222cadbed8;received=213.52.37.107..From: <sip:cbwlap@sip2.itf-as.com>;tag=4183d760c26e > 4531a7a39f45d14fb4c6..To: <sip:kmm@sip2.itf-as.com>;tag=9dd61ff61e802d8e2bef5f14621ef3c2.f003010a..Call-ID: > b3dd380f0c1d4e0ebdd7fc223710d938..CSeq: 23860 INVITE..Proxy-Authenticate: Digest realm="sip2.itf-as.com", no > nce="Y5A72WOQOq3afsXxs6AD2ihlmLAlgNOe"..Server: kamailio (5.6.2 (x86_64/linux))..Content-Length: 0.... > # > U 213.52.37.107:50336 -> 10.1.2.10:5060 #3 > ACK sip:kmm@sip2.itf-as.com SIP/2.0..Via: SIP/2.0/UDP 213.52.37.107:35270;rport;branch=z9hG4bKPj398365dc9706 > 413f868bdd222cadbed8..Max-Forwards: 70..From: <sip:cbwlap@sip2.itf-as.com>;tag=4183d760c26e4531a7a39f45d14fb > 4c6..To: <sip:kmm@sip2.itf-as.com>;tag=9dd61ff61e802d8e2bef5f14621ef3c2.f003010a..Call-ID: b3dd380f0c1d4e0eb > dd7fc223710d938..CSeq: 23860 ACK..Route: <sip:sip2.itf-as.com;lr>..Content-Length: 0.... > > > > -- > > Regards > > Christian > > > > > > ons. 7. des. 2022 kl. 07:51 skrev Henning Westerholt <hw(a)gilawa.com>: > > Hello, > > > > as you’ve guessed, this can be a common problem related to the routing of the ACK message. > > > > Have a look e.g. with ngrep or sngrep to the SIP signalisation on the server side and check if everything is correct in the SIP messages. > > > > > > From: sr-users <sr-users-bounces(a)lists.kamailio.org> On Behalf Of Christian B Wiik > Sent: Wednesday, December 7, 2022 7:43 AM > To: sr-users(a)lists.kamailio.org > Subject: [SR-Users] Call drops after 1 minute > > > > Greetings! > > > > I have a CentOS setup in AWS where all my calls are dropped after about a minute or so. I realize this typically is a NAT problem, but I can't see where my error is. > > Sound is fine both ways. > > > > Kamailio is set with WITH_NAT and I use rtpproxy like this: > > OPTIONS="-l 10.1.2.10 -s udp:127.0.0.1:7722 -d INFO:LOG_LOCAL5 -m 35010 -M 35110 -A 54.171.168.48" > > (10.1.2.10 is the local IP for CentOS) > > > > Tested with MicroSIP and Linphone and tried numerous configurations. It seems the receiving client is not able to verify the call has been set up, and disconnects. MicroSIP has the status "Connecting..." until it disconnects. > > > > All tips appreciated. Will post configuration and logs if needed. > > Kamailio version 5.6.2 from rpm and rtpproxy 2.1.0 compiled from source. > > > > __________________________________________________________ > Kamailio - Users Mailing List - Non Commercial Discussions > sr-users(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: > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

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