Unsupported URI Scheme

[Justin Ferello]

Hey all,

We have a cluster of (2) VCS Control and (2) VCS Expressways.  Just the other night we disabled H323 on the traversal zone, turned on media encryption and TLS.  Now we are getting random "Unsupported URI Scheme" error messages.

The destination URI in the search page will look like this:

sip:john.doe.ex90@abc.com;registration-serial-number=8d03a68f-e41f-4044-bafd-2dd15d3eda56

To me, this does look like an invalid URI string, but how & why is the VCS inserting all that crap after the real URI?

All VCSes are running X8.1.1

Thanks,

Justin

[Martin Koch]

But is this one of the URIs which failed? Or just a URI you wondered about?

Do calls actually fail? Whats the benefit for you to disable h323 on the traversal zone?

Welcome to the world of SIP :-)

In general the URI looks ok, on SIP you can have additional parameters in the uri.

Wait for it, especially from third party devices you will see way stranger uris than this ;-)

I assume you have findme running (could be the option to auto add registered devices that you see

the "registration-serial-number" tag behind the uri.

What I could picture is that you have some non sip friendly transform, searchrule or findme entry

which causes a result without @domain, examples could be an old call fork to a domain less

h323id, e164 number or for example ISDN GW, ...

Can even be something you strip and then pass it back to the traversal zone (where you said

h323 is not there anymore)

The complete search history from all parts of the calls would be handy.

[Justin Ferello]

Martin,

Yes the URI is a valid URI for our environment and it does fail.

According to the MRA deployment guide, one must change the Media Encryption to Force which in turn forces you to disable H.323 on the traversal zone.

This appears to be an issue with the B2BUA engine.  As soon as we turn off Media Encryption, the same exact URI/call works over the SIP trunk.