SIP trunk to Exchange UM for external voicemail

[Anonymous]

I'm coming from the Cisco world and have just found the Netvanta 7100 and I like what I see so far!  We typically setup a Cisco router running Callamanger Express (CME) with a SIP trunk to Exchange 2007 / 2010 / 2013 for voicemail.  I've setup a SIP trunk to the Exchange server from the Netvanta however I'm having some troubles.

First off I found a bug in the GUI.  Exchange requires TCP for the SIP trunk and so from the CLI I've added the TCP parameter to the "sip-server primary" line.  But when you hop over to the GUI and make any change to the SIP trunk, the TCP is reverted back to UDP every time.  I'm not sure who to report this to, so if anyone can point me in the right direction I would appreciate it.

Second, and more importantly I can't get the trunk to work!  When I make a call from the Netvanta I see the attempted connection in Wireshark on the Exchange server and it looks very similar to a call from the Cisco system.  Here is the SIP trunk config from the Netvanta.  Any pointers would be greatly appreciated, thanks.

voice trunk T02 type sip

  description "Exchange Voicemail"

  sip-server primary 10.0.2.2 tcp 5062

  codec-list g711ulaw both

  grammar from host local

  vm-diversion

voice codec-list g711ulaw

  codec g711ulaw

voice grouped-trunk EXCHANGE

  description "Exchange Voicemail"

  trunk T02

  accept 60X cost 0

And here is the SIP trunk config from a working Cisco router to the same Exchange server:

dial-peer voice 10 voip

description ** Exchange Unified Messaging **

destination-pattern 60.

session protocol sipv2

session target ipv4:10.0.2.2:5062

session transport tcp

dtmf-relay rtp-nte

codec g711ulaw

fax rate disable

fax protocol pass-through g711ulaw

no vad

[Anonymous]

I dug in to the Exchange UM details and found that once a connection is established on TCP port 5062 that Exchange sends back a SIP Redirect to either port TCP 5065 or TCP 5067.  The Adtran 7100 does not seem to be able to handle this redirect.  If I point the Adtran to 5065 and bypass the redirect, the call goes through just fine (thank you Adtran TAC for catching that one).

I would consider this the workaround, however there is one additional snag.  Exchange recycles its UM process weekly (or as soon as the process consumes a certain threshold of memory, whichever comes first).  When the process is recycled it switches to 5067 and then back to 5065 at the next recycle time.  So 5065 works fine until the weekly switch and then it stops working.

So the question remains, is there any way that AOS can handle a SIP redirect that changes the port?  Or is there a way that I can work around this by building a trunk that uses both ports?  I set up a primary and secondary server but it didn't work for some reason.

voice trunk T02 type sip

  description "Exchange Voicemail"

  sip-server primary 10.0.2.2 tcp 5065

  sip-server secondary 10.0.2.2 tcp 5067

  sip-server rollover service-unavailable-or-timeout

  codec-list g711ulaw both

  grammar from host local

  vm-diversion

[Anonymous]

bascheew,

Thanks for posting your question.  The NetVanta 7000 series only supports internal voicemail or using a NetVanta UC server (BCS) for voicemail, so this appears to be an unsupported application.  I wanted to link this post, since it also inquires about configuring a SIP trunk to Exchange: Sample config for 3430 SBC to communicate with Exchange 2010 UM (SIP TCP)

Thanks,
Matt

[Anonymous]

Since the Adtran router won't accept the TCP port redirection as a part of the SIP conversation then I think a work-around to this will be to leave the trunk pointed to TCP 5065 and then on the Exchange server setup the Exchange UM service to restart nightly.  Doing so will set Exchange's listening port back to 5065 immediately.  I'm going to try it in the lab and see if that keeps the trunk up at all times.  It's a shame the primary and secondary SIP-servers doesn't work in this case.

And just to report, MWI works fine along with the message counter on VVX phones.

[jayh · Accepted solution]

The redirect to a second port that changes periodically in the Exchange server seems to be the broken behavior here.  SIP services aren't normally dynamic like that.  Any possibility of configuring the Exchange server not to do that?  What is the supposed benefit of Exchange doing this?

Alternatively, have you tried two trunks, one for TCP 5065 and the other for 5067?  You may get some post-dial delay depending on your SIP timeouts but you can keep that short on internal connections.

voice trunk T02 type sip

  description "Exchange Voicemail sometimes"

  sip-server primary 10.0.2.2 tcp 5065

  codec-list g711ulaw both

  grammar from host local

  vm-diversion

voice trunk T03 type sip

  description "Exchange Voicemail other times"

  sip-server primary 10.0.2.2 tcp 5067

  codec-list g711ulaw both

  grammar from host local

  vm-diversion

voice grouped-trunk EXCHANGE

  description "Exchange Voicemail"

  trunk T02

  trunk T03

  accept 60X cost 0

[Anonymous]

jayh,

When a SIP connection is made to one Exchange Mailbox role, it will respond with a SIP redirect to the FQDN and TCP port of the Exchange server that houses that individual's mailbox.  If you have 20 Exchange servers, you typically don't want to make 20 SIP trunks, so you point your trunk to the closest server on the network and that server will redirect you on the fly to the correct server based on the destination of the call.  In many of our SMB customer scenarios they have everything on a single Exchange server, so the complexity that this solution introduces is unnecessary.

I tried adding both trunks to a group and it appears to be handling the fail-over between ports correctly, thanks for that suggestion!  I found that I needed to add "diversion-supported" to each trunk in order for the call to be dropped to a user mailbox instead of the voicemail login prompt.  I will report back on if I have any trouble with the current setup.  Thank you!

[jayh]

bascheew wrote:

When a SIP connection is made to one Exchange Mailbox role, it will respond with a SIP redirect to the FQDN and TCP port of the Exchange server that houses that individual's mailbox.  If you have 20 Exchange servers, you typically don't want to make 20 SIP trunks, so you point your trunk to the closest server on the network and that server will redirect you on the fly to the correct server based on the destination of the call.  In many of our SMB customer scenarios they have everything on a single Exchange server, so the complexity that this solution introduces is unnecessary.

OK, this must be a Microsoft thing.  I would expect that you point your trunk to a voicemail server (closest if one of many) and that server would direct the media to the correct mailbox server based on the destination, but keep the signaling local, sending its own INVITE to the destination mailbox server.  In your example it seems to be redirecting to the same server based on IP but a different port, even more strange.

[Anonymous]

I wanted to provide an update on my 7100 to Exchange experience.  We ran into a few other snags that were were able to work out thanks to the good folks on this forum as well as my favorite TAC Engineer James.  Thanks everyone!

First we found that when calling in from a PRI that the call never made it to Exchange.  Being an Adtran newbie I didn't recognize that "reject-external" is enabled by default, so we had to remove that.  Once calls were making it to Exchange from the PRI we were met with a slow busy, however if we called from an internal phone the call went through fine.  Wireshark was showing the following 403 Forbidden error on the Exchange side when calling from the PRI:

SIP/2.0 403 Forbidden

ms-diagnostics-public: 15604;source="Exchange-Server";reason="Transient error."

Expert Info (Note/Undecoded): Unrecognised SIP header (ms-diagnostics-public)

So I compared the SIP invite headers from an internal call vs a PRI call and found a difference.  The call from the IP phone didn't have an Alert-Info header but the call from the PRI had one that looked like this:

Alert-Info: <http://127.0.0.1/Bellcore-dr2>

For some reason Exchange didn't like that header, so I applied the following command on the SIP trunks to set the URL to the IP of the 7100 and calls started flowing!

NV7100(config)#voice trunk T03 type sip

NV7100(config-T03)#grammar alert-info url 10.0.0.253

Here are the two calls compared.  There is now an "info=alert-external" parameter on the Alert-Info header which wasn't there before.

FAILED PRI CALL

From: "Cell Phone" <sip:5551212@10.0.2.3:5060;transport=TCP>;tag=5adbc80-a0000fd-13c4-4288f-48fa0da1-4288f

To: <sip:601@10.0.2.2:5065>

Call-ID: 5b87c40-a0000fd-13c4-4288f-2d759f25-4288f@10.0.2.3

CSeq: 1 INVITE

Via: SIP/2.0/TCP 10.0.2.3:5060;branch=z9hG4bK-4288f-103e726d-73fb1ffe

Alert-Info: <http://127.0.0.1/Bellcore-dr2>

Diversion: <sip:5552323@10.0.2.3>;reason=no-answer;counter=1;privacy=off;screen=no

Diversion: <sip:5552323@10.0.2.3>;reason=no-answer;counter=1;privacy=off;screen=no

Max-Forwards: 70

Supported: 100rel,replaces

Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, REFER, REGISTER

User-Agent: ADTRAN_NetVanta_7100/R10.10.0.E

Contact: <sip:5551212@10.0.2.3:5060;transport=TCP>

Content-Type: application/sdp

Content-Length: 200

SUCCESSFUL CALL AFTER COMMAND APPLIED

From: "Cell Phone" <sip:5551212@10.0.2.3:5060;transport=TCP>;tag=5adce80-a0000fd-13c4-428c6-eb78e84-428c6

To: <sip:601@10.0.2.2:5065>

Call-ID: 5b88090-a0000fd-13c4-428c6-577b775c-428c6@10.0.2.3

CSeq: 1 INVITE

Via: SIP/2.0/TCP 10.0.2.3:5060;branch=z9hG4bK-428c6-103f4789-6f573b57

Alert-Info: <http://10.0.0.253>;info=alert-external

Diversion: <sip:5552323@10.0.2.3>;reason=no-answer;counter=1;privacy=off;screen=no

Diversion: <sip:5552323@10.0.2.3>;reason=no-answer;counter=1;privacy=off;screen=no

Max-Forwards: 70

Supported: 100rel,replaces

Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, REFER, REGISTER

User-Agent: ADTRAN_NetVanta_7100/R10.10.0.E

Contact: <sip:5551212@10.0.2.3:5060;transport=TCP>

Content-Type: application/sdp

Content-Length: 200

Once this was fixed everything else has been working great.  I will provide further updates as they happen.  Here is my SIP trunk config up to this point:

voice trunk T02 type sip

  description "Exchange Voicemail 5065"

  no reject-external

  sip-server primary 10.0.2.2 tcp 5065

  codec-list g711ulaw both

  grammar from host local

  grammar alert-info url 10.0.0.253

  diversion-supported

  vm-diversion

!

voice trunk T03 type sip

  description "Exchange Voicemail 5067"

  no reject-external

  sip-server primary 10.0.2.2 tcp 5067

  codec-list g711ulaw both

  grammar from host local

  grammar alert-info url 10.0.0.253

  diversion-supported

  vm-diversion

[Anonymous]

First off I found a bug in the GUI.  Exchange requires TCP for the SIP trunk and so from the CLI I've added the TCP parameter to the "sip-server primary" line.  But when you hop over to the GUI and make any change to the SIP trunk, the TCP is reverted back to UDP every time.  I'm not sure who to report this to, so if anyone can point me in the right direction I would appreciate it.

I altered our Engineering team of this issue.  Thanks for pointing that out. 

Also, thank you so much for your detailed updates.  I'm sure this post will be useful for others in the future who are attempting to setup this same application.  I will also pass on the kind words to who has been helping with your support ticket.

Thanks,

Matt

[Anonymous]

First off I found a bug in the GUI.  Exchange requires TCP for the SIP trunk and so from the CLI I've added the TCP parameter to the "sip-server primary" line.  But when you hop over to the GUI and make any change to the SIP trunk, the TCP is reverted back to UDP every time.  I'm not sure who to report this to, so if anyone can point me in the right direction I would appreciate it.

I just wanted to update this thread to mention this bug was fixed in R11.2.0, which was just released.

Thanks,

Matt