Tag Archives: Troubleshooting

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

No Presence for Fedrated partners – Event ID 11

08 Wednesday Jun 2016

Posted by in Error Codes, Event ID, Federation Issue, Lync DNS Records overview, Lync Edge, O365, Office 365, SRV, SRV Record, Uncategorized, Unified Messaging, voicemail

≈ 2 Comments

Tags

, ,

Problem

Came across a deployment with the following 2 issues:-

  1. federated partners were showing up as presence unknown
  2. unable to call voicemail (hosted in O365)

When trying to send messages to these “unknown” federated partners I got “This message wasn’t sent due to company policy”.

So why did I try to message a contact with a presence status of “unknown? Simply because the federated contact could see my users presence and send me IM’s, I was even able to respond to these IM’s although the presence was still “unknown”.

Presence Unknown

Troubleshooting

A quick look at the client side logs revealed an error in the presence Subscribe message

CSeq: 1 SUBSCRIBE
Via: SIP/2.0/TLS 172.11.12.13:24164;ms-received-port=24164;ms-received-cid=FC9300
ms-diagnostics: 1008;reason=”Unable to resolve DNS SRV record“;domain=”ucsorted.com”;dns-srv-result=”NegativeResult”;dns-source=”InternalCache”;source=”access.ucsorted.com”
Server: RTC/6.0
Content-Length: 0

Taking a look at the users (client side) local event log I found the same error.

Event Log

Event ID 11
A SIP request made by Lync failed in an unexpected manner (status code 80ef01f8).

Response Data
504  Server time-out
ms-diagnostics:  1008;reason=”Unable to resolve DNS SRV record“;domain=”ucsorted.com”;dns-srv-result=”NegativeResult”;dns-source=”InternalCache”;source=”access.ucsorted.com”;OriginalPresenceState=”0″;CurrentPresenceState=”0″;MeInsideUser=”No”;ConversationInitiatedBy=”6″;SourceNetwork=”5″;RemotePartyCanDoIM=”Yes”

Clearly there is some issue with either the federation SRV record or resolving the federation SRV record.

Checking the SRV record from the Edge server I can see that this record is not found. Checking the DNS for the Edge server I noticed that the interfaces are pointing to the internal DNS servers.

Solution

We have 2 options here:-

  1. Configure the Edge Server to point to a public (external) DNS server where the SRV record for _sipfederationtls._tcp.domain.com is valid (frowned upon by some security folks)
  2. Add the SRV record for _sipfederationtls._tcp.domain.com to the internal DNS, making sure that the target FQDN is the Public Access FQDN of the Edge Server.

NOTE

Here is a little reason why you may want to avoid using the common sip.domain.com DNS name for your Edge Servers Access FQDN (only..). Internally the sip.domain.com record was generally configured to resolve to the front end pools, if we now need an internal SRV record for _sipfederationtls._tcp.domain.com then targeting this to sip.domain.com will simply get to the Front End Pool and not to the Federation point at the Access Edge FQDN.

 

 

Solving Event ID 31117 – LS Response Group Service

15 Friday Apr 2016

Posted by in event id, Uncategorized

≈ Leave a comment

Tags

, , , , , ,

The Problem

Users calling in to a existing Response Group Service are getting calls dropped when the call steps through the workflow and is directed to the RGS Queue. All other Workflows are working fine.

History

This started after an admin was tasked with re-directing calls to the workflow DDI\DID in question to another workflow temporarily. It was when they switched the calls back that the issue revealed itself.

The Evidence

Checking the Event Log on one of the Front Ends I find an error alluding to a workflow issue. Event ID 31117 states that “the workflow encountered a critical error”.

Event ID 31117

Monitoring Database shows a Diagnostic ID 26029 with a description “Call is disconnected because of invalid configuration”

Diagnostic ID 26029

So by now I was thinking that there is some sort of configuration issue with the workflow or inherently the queue, or group. I checked and double check, everything looks fine on the surface.

Finding the culprit

With no further information to go by I took a stab at the possibility that an invalid agent SIP address was added to the group (seen a similar issue where that was the cause, see here). Nope, all good.

With only three variables, the Workflow, the Queue and the Group, I decided a quick process of elimination should flush out the hog.

Turning to the Workflow, I changed the destination Queue to one that I knew was working. Tested it and, well that worked. So the Workflow is fine.

Next up the Queue, I removed the associated Groups from the queue and added groups I knew were working. OK so that worked, calls went to the test group members. So now I knew it was the Queue that was causing the pain.

Keeping it simple, I just deleted the Queue, invoked replication and re-added it. A quick test call and voila..Sorted!

Response Groups can be really powerful, they can also be a royal pain in the behind when something goes wrong.

TIP

Making changes to RGS takes a few minutes to set, I usually invoke replication before testing any changes.