sipsorcery's blog

Occassional posts about VoIP, SIP, WebRTC and Bitcoin.

sipsorcery.com response times SIP Sorcery Last 3 Hours
daily weekly
sipsorcery.com status

Some Tweaks to SDP Mangling (audio)

August 6, 2009 by sipsorcery

Following on from yesterday’s post about NAT I have today applied some tweaks to the way the sipsorcery app servers do their SDP mangling (to understand what SDP mangling is all about and how it affects audio you’ll need to read the previous post NAT, RTP and Audio Problems).

Luckily the rules for sipsorcery packet mangling are a lot simpler than the various NAT and scenarios and will take a lot less writing to explain. The rules are:

  • If an INVITE request or response arrives with a private address in its SDP the sipsorcery app server will attempt to replace it with the public IP address the request or response was received on,
  • The default mangling behaviour can be turned off in two ways:

    – Adding a dial string option of ma=false to the call leg, example sys.Dial(“1234@somewhere.com[ma=false]”),

    – Placing a call between two sipsorcery SIP accounts that have the same networkid. For example if a SIP account with a networkid of “home” calls a second SIP account also with a networkid of “home” then the sipsorcery app server will recognise that no SDP mangling is to take place on the call between them.

    • In general the only time SDP mangling should be turned off is when a call is being placed between two SIP accounts that are on the same private network. For example on my home network I have a Cisco IP phone and a Polycom IP Phone, if I place a call between them through the sipsorcery server and the default packet mangling is left on then the call will have no audio in either direction. That’s because the SDP sent to each phone contains my public IP address and the NAT implementation on my router won’t have a mapping between the public socket and private socket. To get around that mangling can be turned off on the call and the SDP then contains the private address of each phone and they are able to send RTP between each other.

    The ability to place a call between two phones on a private network and have the RTP get set up directly between them is pretty neat. Most SIP Servers or softswitches I have dealt with don’t have the ability to do that except by using a re-INVITE which is error prone. So what generally happens instead is that if two phones that are right next to one another call each other the RTP streams go out across the internet, are bridged on the softswitch and sent back to the phones. That takes up a nice little chunk of bandwidth, introduces latency and all that other good stuff.

    Hopefully people experiencing audio issues will be able to get a better understanding of where the problem might be and hopefully resolve them. There are undoubtedly situations that the sipsorcery servers won’t be able to cope with but in some cases there maybe an additional rule that can be applied and I’d be happy to implement them if anyone comes up with such a case.

    Aaron