reSIProcate 1.13 is in the makings and is in the current GitHub master branch at:  https://github.com/resiprocate/resiprocate 

In this version of reSIProcate we've taken measures to update the stack to more modern C++ semantics.  There are other changes in this version, but this post focuses on those changes that cause a break in API/ABI for applications that are based off of the reSIProcate API's.  These applications will require some relatively easy changes to be applied to the application source code in order to build with this new version.

Summary of the changes that are specific to API/ABI and build:

• addition of VS2019 solution and project files, and removal of VS2013 solutions and projects
• replace std::auto_ptr with std::unique_ptr
• replace resip::SharedPtr with std::shared_ptr
• return project, replace boost::shared_ptr with std::shared_ptr
• makefile now requires C++11 compiler support
• replace boost::bind with std::bind or lambda expressions

Application Porting Guide:
stack/dum/return/recon applications:

• Remove any #include references to <rutil/SharedPtr.hxx>
• Find and replace: resip::SharedPtr with std::shared_ptr
• Find and replace: SharedPtr with std::shared_ptr
• Many reisp API's changed from std::auto_ptr use to std::unique_ptr use
  • update all code that interacts with these to use std::unique_ptr
  • when passing a std::unique pointer to a method call you will need to wrap in in std::move
  • For Example:
  • mDum.getSipStack().postMS(std::move(pMsg),
         getUserProfile()->getDefaultStaleCallTime() * 1000, &mDum);
  • Callback/handlers that used std::auto_ptr (usually for Message contents) were updated to std::unique_ptr
  • Applications will need to update their callback overrides accordingly
  • Consider doing a selective find and replace:
    • std::auto_ptr -> std::unique_ptr
    • auto_ptr -> std::unique_ptr
  • Then build and fix up to add std::move's where needed.

Proxy applications:

• repro::Dispatcher recently moved from repro namespace to resip namespace - adjust as needed
  • Find and replace: repro::Dispatcher with resip::Dispatcher
  • include is now: #include <resip/stack/Dispatcher.hxx>
• ServerAuthManager::AsyncBool moved to it's own class and is now in resip namespace
• UserAuthGrabber changed from taking a UserStore to taking the entire DataStore - pass in the correct type now

RFC 3263 - Locating SIP Servers contains a lot of cool features that SIP entities can take advantage of, to be located.  It is much more advanced that just a simple name to IP address mapping.  While the RFC itself provides all the nitty gritty details it is good to understand the process at a high level.

Any SIP entity that would like to send a message to a particular domain is required to perform the following DNS lookups:

Step 1 - Selecting a Transport
This is performed by doing a DNS NATPR record lookup on the domain part of the SIP URI or AOR trying to be routed to.  The NAPTR record results tell clients which SIP protocol is preferred and in which order, ie: UDP, TCP or TLS.  They also provide the next name element to be looked up.  Clients should select the highest priority NAPTR record / protocol that they support, then perform step 2 on resulting name.

Step 2 - Discovering Servers
Using the name discovered from Step 1 a DNS SRV record lookup is performed.  This can result in a number of records returned.  Each record has a priority and weight and a mapped server/hostname.  The priority and weight allow the owners of domain to implement a wide range of redundancy and load balancing options.  For example: entries with equal priorities are load balanced to using a distribution described by their weight.

Step 3 - Resolving servers to IP Addresses
Using the priority and weight rules from Step 2 a single server/hostname is selected by the client and it's IP address is looked up via A and AAAA (IPv6) DNS queries.  The request is then sent to that particular address.

If the request fails to send, then the next server from Step 2 is used to route the request to.

A potential gotcha:
DNS records have an expiration, and often this duration is much shorter than the duration of a SIP call or other long standing SIP communications.  Some SIP servers are created such that they are stateless (or have shared state), but others are not.  As a result it can detrimental if the SIP server receiving the REGISTRATION is not the same SIP server that receives a re-REGISTER or an INVITE at a later time.  Some SIP servers expect that you do NOT always follow the DNS rules for every request that you send to them, and that you instead pick a "good" DNS server following the above rules, then stick with that server until you have errors communicating with it.

The reSIProcate stack offers the ability to configure its DNS resolution logic with the logic to stick to a known good server once it is found.  This reSIProcate feature is called DNS VIP, and it can be enabled at the time you create the SipStack object via it's constructor.

​Scott

The other day I was successfully able to get reSIProcate and the basicClient example program to run on my Raspberry Pi 2 under Windows 10 IOT Core!  Very few changes were required to the stack in order to get it to compile as an ARM target.  I will be moving these changes into the public GIT repository soon.

Raspberry Pi and Windows 10 IOT support USB speakers and microphones and the board itself has an audio jack, but it would be nice if Microsoft / Cirrus Logic would support the Cirrus Logic Audio Card daughter board for the Raspberry Pi 2 under Windows 10 IOT.  This should prove to be a pretty good platform for embedded VoIP / windows based development.

Scott Godin
President & CEO
SIP Spectrum, Inc.

Need a web-sockets capable SIP proxy for WebRTC?  repro from the resiprocate project is an excellent candidate.

You will need to configure repro to use record-routing so that all SIP requests are routed via the proxy for a particular dialog session.  The following are steps you should use to configure repro and represent changes to the default repro configuration for web-socket use.

1.  Configure transports.  I like to configure one web-sockets transport and one UDP transport on the proxy (to allow communication with legacy VoIP equipment).  In this example I will focus on non-secure web-sockets protocol, however secure web-sockets (WSS) can also be configured with additional effort.  Here is an example of configuration where repro is behind a NAT.  The 192.168.1.117 address is the private IP of the machine running repro and X.X.X.X address is the public IP address to reach this machine.  Note:  If you are not using a NAT'd machine then you can use the auto keyword for the RecordRouteUri instead.

          Transport1Interface = 192.168.1.117:6060
          Transport1Type = WS
          Transport1RecordRouteUri = sip:X.X.X.X;transport=ws

          Transport2Interface = 192.168.1.117:5060
          Transport2Type = UDP
          Transport2RecordRouteUri = auto

2. Enable Flow Token use for WebRTC SIP clients that don't properly advertise
RFC5626 (Outbound) support:
          EnableFlowTokens = true

3.  Add a domain and users (with passwords) using the HTTP admin GUI.  Navigate to http://127.0.0.1:5080 after starting repro.  Note:  Remember to restart repro after adding a domain.


Settings for tryit.jssip.net:
Name = <whatever you like>
SIP URI = sip:<a user from step 3 above>@<domain from step 3 above>
SIP Password = <users password from step 3 above>
WS URI = ws://X.X.X.X:6060      (IP address and port configured in Step 1 above)

Happy Web-RTCing!

Scott

SIPit 30 was hosted by Cisco and held in Raleigh, NC from February 11-15, 2013.  As usual the event proved invaluable for all attendees, with a total number of reported defects nearing 100 (I'm sure there were many more unreported defects).  As well as traditional SIP audio endpoints, the trend of vendors with video enabled endpoints continued, as this event provides huge value to those seeking to improve their video interoperability.  The official event summary can be found here:  SIPit 30 Event Summary.

A new comer to the SIPit events this year was Web-RTC interoperability.  A number of vendors tested interoperability with each other and the new Web-RTC technology in the Mozilla/Firefox and Chrome browsers.

SIP is very prominent in the telephony world, and has long established itself as the VoIP protocol of choice for telephony service providers, IVR vendors and PBX manufacturers.   What some people don't realize is that SIP has also moved it's way into other industries as well.  Of particular interest is the radio industry.

One of the first consulting projects I did within this industry was a SIP based connection from the digital radio world to the telephony world as an access mechanism to bridge a PBX with 2-way radios.  This project was based on vanilla SIP use (using IETF RFC specifications only), and involved the exact same implementation one would do for any standards based SIP/VoIP endpoint.  SIP use in the radio industry doesn't stop there though.  Radio vendor's need mechanisms to interoperate with each other and third party application vendors, such as console operators.  

Radio vendors are designing new TCP/IP based protocols that utilize SIP as the base application level protocol to carry this specialized information.  Public protocols such as Project 25 ISSI (a TIA specification) and DMR extend the base SIP capabilities and layer radio functionality on top.  On top of these two standards there are also a number of vendor specific proprietary specifications encompassing very similar functionality.  This collection of multiple standards may hinder operability in the short-term.   However, I expect as SIP use matures more in the radio world we will see more convergence on a single customized use of SIP that will allow it reach the interoperability level we see today in the telecommunications space.