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
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:
>
>
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
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
______________________________________________________
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
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
Dear All,
I have three Kamailio in my production environment and I have written some
code in Kamailio.cfg using SqlOps to insert data into the database on
another remote server for every call. I deployed the code in one of the
Kamailio and it inserted data perfectly fine into the database but as soon
as I deployed it in the other two Kamailios. All three Kamailio's become
unreachable or lagging in asterisk. I don't know if it has anything to do
with SqlOps or queries being stuck somewhere as I am receiving logs
consistently for every call in Kamailios.
How can I identify if the queries are being stuck somewhere and that is why
Kamailio is unreachable or lagging? Calls are not dependent on that
database, this I know because even if I stop the mysql service calls will
still be dialed. If it is due to the SqlOps, is there any other way to save
information on every call without Kamailio being stuck?
Regards
VIcky
Hello Everyone,
Does anyone have experience in deploying Kamailio, Asterisk and RTPProxy to
a dockerized environment with K8s?
In short, we are looking to deploy the following applications to our
Kubernetes environment to support a SIP based PBX for our company:
- Kamailio (Sip Proxy with DID, Outbound, edge routing and LB capabilities)
- Asterisk Realtime (PBX, IVR)
- RTPProxy (Media Relay)
Has anyone been successful, or failed, in doing this? I would love to hear
from you.
Terrance
It's not easy and takes a long time to perfect, but our entire VoIP infrastructure is Dockerized, and composed of Asterisk, MySQL, Redis, NodeJS and Kamailio+RTPEngine (not rtpproxy, since rtpproxy isn't maintained anymore). No docker-level port forwarding required anywhere, since the entire system is designed to be volatile (see below).
We have over 500 Asterisk docker containers running, supporting many thousands of users across the world at this point, and it works quite well, so it can be done.
The concept behind the Asterisk containers is designing everything to be completely volatile: Outages happen, even in datacenters, so assume a container will reboot at some point on some random node at some random datacenter location. You don't know Asterisk's private IP, you don't even know where it might pop back up in the cluster. If you can ensure service continuity in that scenario, then you've built a solid setup. Our uptime has been 100% for over 4 years now (this is 3rd-party monitored and validated, in addition to our internal monitoring systems) so I assure you it is very possible.
I also HIGHLY recommend not using a cloud provider for any of the core infrastructure. We tried this, with AWS and GCP, and the voip quality was... meh. The cloud outages were frequent, although customers generally don't notice them when you're using lightweight containers to run everything. So we are fully operating on our own hardware across multiple colo locations, and only using cloud for file storage (eFaxes, voicemails, greetings/recordings, MMS content, phone LCD background images for provisioning, etc).
I am unable to help with your project, but I can at least provide the above pointers/experiences in case they get you in the right direction.
An alternative to building your own infrastructure might be reselling (white label) an existing service provider as well, in case the decision to build your own infrastructure is still up in the air.
Luke Escudé
972.600.1150
support(a)primevox.net
Schedule a meeting!<https://outlook.office365.com/owa/calendar/PrimeVOXCommunications@primevox.…>
View the PrimeVOX R&D Roadmap here<https://trello.com/b/pzpoyn8m/primevox-engineering>
View the PrimeVOX Status Page here<https://status.primevox.net/>
________________________________
From: sr-users-request(a)lists.kamailio.org <sr-users-request(a)lists.kamailio.org>
Sent: Thursday, December 22, 2022 9:44 AM
To: sr-users(a)lists.kamailio.org <sr-users(a)lists.kamailio.org>
Subject: sr-users Digest, Vol 211, Issue 47
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: Dockerized VoIP Stack (Terrance Devor)
2. Re: Dockerized VoIP Stack (Terrance Devor)
3. Re: Dockerized VoIP Stack (Terrance Devor)
----------------------------------------------------------------------
Message: 1
Date: Thu, 22 Dec 2022 09:31:33 -0500
From: Terrance Devor <ter.devor(a)gmail.com>
Subject: [SR-Users] Re: Dockerized VoIP Stack
To: "Kamailio (SER) - Users Mailing List"
<sr-users(a)lists.kamailio.org>
Message-ID:
<CA+w+2f8CtdwkiDtz+Md-pZz5xA4-59gv768b_vq4bkdjf2V3hw(a)mail.gmail.com>
Content-Type: multipart/alternative;
boundary="000000000000398ece05f06b87af"
I did see the CyCore project and tried to connect with Laurel Lauson and
Sean McCord on LinkedIn
On Wed, Dec 21, 2022 at 9:18 PM Fred Posner <fred(a)palner.com> wrote:
> On Dec 21, 2022, at 8:41 PM, Terrance Devor <ter.devor(a)gmail.com> wrote:
>
>
> Does anyone have experience in deploying Kamailio, Asterisk and RTPProxy
> to a dockerized environment with K8s?
>
>
> Check out some past Kamailio World and Astricon presentations, including
> some from Sean McCord. He even has a GitHub demo:
>
> * https://github.com/CyCoreSystems/asterisk-k8s-demo
>
> -- Fred
> The Palner Group, Inc.
> +1 (212) 937-7844
>
> __________________________________________________________
> 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:
>
