Category Archives: SIP

SIP/2.0 415 Unsupported Media Type

30 Saturday Sep 2017

Posted by in Firewall Rules, SIP, SIP 415, SIP/2.0 415 Unsupported Media Type

≈ 3 Comments

Tags

, ,

So this is a new error for me, not seen this in Skype Client logs before. But there it was, SIP/2.0 415 Unsupported Media Type.

unsupported media

The deployment is Two Front End Pools (both Standard Edition) with a single Edge Pool. No Enterprise Voice (yet).

The Problem

When attempting to call a service that’s effectively a Pexip DMZ Cloud Service in New Zealand (called SmartPresence) from the corporate LAN then the call seems to connect but then disconnects, there is no audio or video.

It all works when then the Skype user tries calling the Pexip\SmartPresence bridge from an external location (not corporate LAN).

Troubleshooting

At first glance, you’d agree that this smells of firewall issues. Lets see what the logs say. Heading off to the client logs cause that’s my go to as a starting point for these sorts of issues. I find the call and of course spot the SIP/2.0 415 Unsupported Media Type.

Looking at the negotiation of Media I see that the Skype Client sends all the usual audio and video codec options.

Audio options from Skype client

Snooper 01

Video Options from Skype client

snooper 02

On the inbound side from SmartPresence we see that there are less media options (thats expected) but certainly options that match with what the Skype client is capable of.

Audio Options from Pexip\SmartPresence

snooper 03

So it appears that its not so much an unsupported Media type, lets see what the clients agree on using by looking for the results of the candidate negotiation.

Looking for the a=remote-candidates line tell in the client log should show the options both clients agree on.

Wait..there is no a=remote-candidates for this call!

What, so that means that the candidate negotiation is failing to establish a viable path between the the Skype client and the Pexip\SmartPresence service. Taking a closer look at the candidtes on offer I see the below.

Candidates from Skype client

snooper 04

So the Skype client sends options 2,3 and 4 as viable (1 and 5 are direct, thats not allowed by customer strict firewall policies).

Candidates from SmartPresence\Pexip

pexip 01

Looking at the options from the Pexip\SmartPresence service I can see the candidates on offer.. and there it is.

Those are not standard ports!

Since when do we need ports in the 40 000 range from our Edge Server pool outbound?

Right, what does the Pexip portal say with regard to firewall requirements. Searched a while for this info but eventually found the following table

pexip 02

and also this little gem

pexip 03

Solution

Open ports 40 000 – 49 999 for both UDP and TCP outbound from the Edge pool to Pexip\SmartPresence Cloud

Source https://docs.pexip.com/sfb/ports.htm

Advertisement

Enable Referred By Header

29 Wednesday May 2013

Posted by in B-Party, Billing, CLI, Refer Support, Referred-by, SIP

≈ Leave a comment

I have often come across a SIP vendor that uses the CLI for billing purposes. This can be an issue when A (External PSTN party) calls B (lync DDI user) which is forwarded or transferred to C (external PSTN party).
In this case the true caller A cannot be shown as the calling party as the SIP vendor cant bill that caller.  In this instance you will find that the vendor supports refered-by headers, not something that is enabled on Lync by default.

On each Mediation server do the following:’
Edit the file MediationServerSvc.exe.config found in C:\Program Files\Microsoft Lync Server 2010\Mediation Server so that it looks as follows:-




   
               

   
 
   
 


NOTE
In my example I have 2 gateways as shown by the 2 add key lines.
The Mediation Services will need a restart to take effect

Microsoft reference 
http://support.microsoft.com/kb/2500421

SIP Options

20 Wednesday Feb 2013

Posted by in SIP, SIP Options

≈ Leave a comment

For some time now I have seen my Wireshark traces and the event log on the Mediation Server report an issue with regard to SIP Options. I finally was forced to pay attention to this item during a recent deployment.


In the image above the Source IP 10.2.85.31 is the Lync FE and 10.2.85.20 & 10.2.85.21 are both gateways. Lync here sends the SIP Options Request and both gateways reply with OK.

What do SIP Options do?
They are used by Lync to determine if the gateway\SBC is good and ready to accept calls from Lync (no that’s not a typo, this is in relation to outbound calls).

Lync sends a SIP Options request to the Gateway and expects an answer (apparently any answer will do) usually a 200 OK. These messages are sent every 4 seconds. If no response is received for a period of up to 30 seconds the route using this particular gateway is marked as down. 

If its the only gateway Lync will continue to attempt to route calls across it. If there is an alternate gateway available then this will receive the outbound calls instead.

Sometimes you may come across a gateway that sends SIP Option messages to Lync, in this case Lync will stop sending Options messages and instead reply to the options messages it receives with an OK. Lync will also send a SIP Option messages every 20 seconds to be sure all is good.

If Lync stops seeing the SIP messages from the gateway it will revert to taking over the role of sending messages in 5 minutes from the last Options message received.