VCS Transform - Why does it transform from SIP to H323

[John Faltys]

I dial a uri 99912@domain.com

The regex transform, transforms

(9[6-9]\d{3})(@.*\.domain.com)?

replaces with

42425\1@voip.domain.com

The result ends up as an H323 alias, when the source was sip.  Why? How can this stay SIP?

    Destination (1)

        Alias (1)

            Type: Url

            Origin: Unknown

            Value: sip:99912@voip.domain.com

    SubSearch (1)

        Type: Transforms

        Action: Transformed

        ResultAlias (1)

            Type: H323Id

            Origin: Unknown

            Value: 4242599912@voip.domain.com

[Fred Nielsen (ePlus)]

I'm curious about this too,VCS seems to prefer H323 over SIP when routing calls or transforming aliases.  The only clear way to modify this behavior that I've found is to disable H323 altogether, but this is undesirable for obvious reasons.  It would be nice in many of the environments we are implementing today to reverse this seemingly in-built preference.

Your post has me wondering about this, what would happen if we put "sip:" prefixes in the replaces for matched rules that we know we want to send via SIP?  I haven't tried it yet, just thinking out loud here...

[John Faltys]

Frederick,

Thanks for the interest. Exactly what I thought. I actually tried sip: as a replacement and it still treated it as h323.

Thanks

[Martin Koch]

Hi John / Frederick!

I read what you say, but I do not understand your problem.

Yes, the search history shows it as a "h323id", but I would say this is only some

internal vcs alias handling or maybe even only a displaying bug.

For me it is more important how the call is set up at the end and here I see that it will be sip<->sip calls.

Did you look further down, its more interesting where the call is matched.

If it does not match, maybe your search rule is not ok.

The VCS will try to stay in protocol, if you initiate a sip call it  will try to reach the destination in sip first and switch over

to h323 if not sucessfull (or vice versa on a h323 initated call).

Included an example of a search match on a of a sip<->sip call. You see the "alias type" is h323id,

but the Protocol is SIP. This was a call on a VCS-E but local or calls to other zones on a VCS-C work

fine for us as well.

    SearchRule (3)
        Name: DNS
        Zone (1)
            Name: DNS
            Type: DNS
            Protocol: SIP
            Found: True
            Reason: Use RTCP Feedback Instead
            Gatekeeper (1)
                Alias (1)
                    Type: H323Id
                    Origin: Unknown
                    Value: user@domain.com

Could you two describe a bit more where you see a practical impact in your deployment?

[Fred Nielsen (ePlus)]

I have to reverse what I said, I was remembering incorrectly before.  VCS does in fact send out the call first in the native protocol of the originating endpoint, and then attempt to internetwork the call using the opposite protocol, as Martin described. 

But this brings up the problem that I wish there were a better answer for: when calling an outside party's H323 endpoint from a SIP endpoint (and all our endpoints are SIP-only now), the VCS Expressway first attempts to route the call via SIP and depending on the response received can take quite some time to timeout and retry via H323.  So what we basically observe much of the time is an automatic 30 second delay placing H323 calls. 

This is illustrated with my two fake call attempts below, the first to fred@1.2.3.4 and the second to 1.2.3.4.  We appreciate that it tries both protocols, it would be nice if we could adjust the SIP timeout value somewhere though:

[awinter2]

Hi Frederick,

you can disable SIP UDP on your Expressway to get rid of the 30 second delay.

The 30 second delay is due to the Expressway sending out a UDP-based INVITE towards the destination, which will time out after 30 seconds if unanswered.

- Andreas

[Fred Nielsen (ePlus)]

Yeah, thought about this earlier when we observed a packet capture, but was concerned that this might hamper functionality... not sure how many external parties rely solely on UDP, shouldn't be many I suppose..

[awinter2]

John,

When you state that "The result ends up as an H323 alias, when the source was sip", are you referring to the fact that the search result shows "Type: H323Id" for the result alias, or that the VCS places the outbound call using H323 as the call protocol?

Type: H323Id simply means that the result alias is a URI as opposed to an E164 number, not that the call will be placed using H323 as the signaling protocol.

The call will remain in its original protocol (In this case SIP) if the VCS is able to route the call in this protocol, which would normally require the remote party to have set up SIP DNS SRV records for the domain inquestion ('voip.domain.com'.)

- Andreas

[John Faltys]

Andreas,

Ok, that makes sense.  It does seem that it checks sip first.

I guess since the call was not completing from VCS registered endpoint, but was from call manager registered endpoint, I jumped to conclusions when I saw the "h323id".

Thanks for the response.