[SR-Users] RTP multiplexing, batching and compression (KamailioWorld followup)
Hi, as a followup to the 5 min 5 slides talk on Tuesday at the Kamailio world conference, I wanted to send links to that implementation, as I did get some interest about this afterwards. This transparent RTP mux gateway implementation in SEMS is a multiplexing, batching and compression mechanism, which can save quite some bandwidth on low bitrate codecs - can be useful if you need to work with very low bitrate links, e.g. on satellite (I tested with 10 G729 calls instead of 5 on a 128kbit sat link). It's a bit like ROHC (RFC3095) but on application level, only for RTP, and by using configuration for IP addresses instead of negotiation. Or as osmux, but without separate negotiation (but in-band), and for all codecs, and SIP. Or iax2 trunking mode, but with normal SIP/RTP. https://github.com/sems-server/sems/blob/sayer/rtp-mux/doc/rtp_mux/rtp_mux_protocol.txt https://github.com/sems-server/sems/blob/sayer/rtp-mux/doc/rtp_mux/rtp_mux.txt For now it's in the sayer/rtp-mux branch, but it's planned to merge it to master, possibly with simplification of the configuration. On another note, many thanks to the organizers of the Kamailio World conference! It's both really nice to meet, and very useful, and I think as well individually as well as for the community as a whole. Best Regards, Stefan ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] SEMS with sbc application
Hello, Mojtaba wrote on 24.01.2018 12:17: > Hello, > I have a problem today, It's strange for me. > Suppose we have this senario: > uac1--->SEMS(mo profile)--->Kamailio>SEMS(mt > profile)-->uac2 > > In above topology, we have two interfaces(intern,extern) for SEMS, and > just used as SBC (sbc application). > if i used port=5060 as external port, every things is right and log > file is like this: > [#7fed3f9f9700/32820] [run, udp_trsp.cpp:352] DEBUG: vv M [|] u recvd > msg via UDP from 89.165.117.125:42411 vv > --++-- > REGISTER sip:kava.shatel.ir;transport=UDP SIP/2.0 > Via: SIP/2.0/UDP > 89.165.117.125:42411;branch=z9hG4bK-d8754z-021bd8b61efc7ac0-1---d8754z- > Max-Forwards: 70 > Contact: 89.165.117.125:42411;rinstance=79011092e56e1a09;transport=UDP> > To: > From: ;tag=82820e1f > Call-ID: Y2U4YThiYjEwNTUzMzliZTIwNWZkMDI3MTM4OTZlNWU. > CSeq: 2 REGISTER > Expires: 3600 > Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, > INFO, SUBSCRIBE > Supported: replaces, norefersub, extended-refer, timer, X-cisco-serviceuri > User-Agent: Z 3.3.25608 r25552 > Allow-Events: presence, kpml > Content-Length: 0 > > but when i changed port=4080 for external port, The Via header and > contact header are changed to my public ip, like this: > > [#7fed3f9f9700/32820] [run, udp_trsp.cpp:352] DEBUG: vv M [|] u recvd > msg via UDP from 89.165.117.125:42411 vv > --++-- > REGISTER sip:kava.shatel.ir;transport=UDP SIP/2.0 > Via: SIP/2.0/UDP > 172.1.1.125:42411;branch=z9hG4bK-d8754z-021bd8b61efc7ac0-1---d8754z- > Max-Forwards: 70 > Contact: > To: > From: ;tag=82820e1f > Call-ID: Y2U4YThiYjEwNTUzMzliZTIwNWZkMDI3MTM4OTZlNWU. > CSeq: 2 REGISTER > Expires: 3600 > Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, > INFO, SUBSCRIBE > Supported: replaces, norefersub, extended-refer, timer, X-cisco-serviceuri > User-Agent: Z 3.3.25608 r25552 > Allow-Events: presence, kpml > Content-Length: 0 > Why my public ip address is there here? I just changed external > port=4080 in sems server. In SDP protocol i have the same problem when > i changed external ip port in sems server. is this message log the one of the first SEMS (mo profile) which is sent by uac1? In that case it's the uac1 which puts the 172.1.1.125 IP addresses in the SIP message. Or rather: I can imagine that there's a SIP ALG on the NAT between the uac1 and SEMS, which only changes packets when the destination port is 5060. Stefan > > Thanks. > --Mojtaba Esfandiari.S > > ___ > Kamailio (SER) - Users Mailing List > sr-users@lists.kamailio.org > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] t_suspend usage in branch_route
Aymeric Moizard wrote on 09.02.2018 13:49: > I understand your warning about TCP: If I have only on TCP branch and > it fails > I guess I will have a fast " I'm terribly sorry, server error occurred > (7/SL)" answer > and no time for my "pushed" app to be already registered. However, I think usrloc's handle_lost_tcp is a good tip. we're using these in a push notification config for webrtc [0]: set_forward_no_connect(); t_set_disable_internal_reply(1); and then if t_relay() fails ts_store and t_suspend the transaction which I believe works. Stefan [0] https://github.com/saycel/kamailio-config/blob/fc17b58369af5a487d131dd67ac3c6a8628d1b29/kamailio.cfg#L695 ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] msilo on proxy in front of registrar
Hello, I have a bit of a strange situation where I want to add SIP MESSAGE reliability (store and forward) for a proxy that is in front of the (message-wise unreliable) registrar/message originator. So I m_store MESSAGEs in the failure_route of MESSAGE requests. By default, msilo's m_dump works only for REQUEST_ROUTE, thus I can't use that in the 200 to REGISTER. But when I add a function to msilo for ONREPLY_ROUTE (without the check for MESSAGE support) it works. So, is there a reason that there's m_dump only for REQUEST_ROUTE? And, is this: if ((msg->first_line).type == SIP_REQUEST) the correct way to check whether we're handling a request or reply? Also, is there a way to check the expires of contacts in the 200 to REGISTER from the script, so I don't try to m_dump on de-REGISTER? Or does this have to go into the m_dump function for the ONREPLY_ROUTE case? Many thanks for hints! Stefan ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
