Anybody see this before?

I send INVITEs to two different SIP servers from FMG.  The INVITE to another FMG returns:

-------------------------------------------

SIP/2.0 200 OK

From: "Dennis Ernst via FMS"<sip:mms1devFMG@mms1dev.vin.com>;tag=43ec080-0-13c4-5506-f1c9-d6351ad-f1c9

To: <sip:8888@209.204.188.250>;tag=40b5fa0-0-13c4-5506-876a-7ff2895-876a

Call-ID: 43f2548-0-13c4-5506-f1c9-521b3a17-f1c9

CSeq: 2 INVITE

Via: SIP/2.0/UDP 10.10.10.190:5060;branch=z9hG4bK-f1c9-3b07d0f-3ee6b1f0

Contact: <sip:8888@209.204.188.250>

Content-Type: application/sdp

Content-Length: 250

v=0

o=MG 2630303 2630303 IN IP4 209.204.188.250

s=Flash Media Gateway 2,0,0,72

c=IN IP4 209.204.188.250

b=AS:612

b=CT:612

t=0 0

m=audio 49158 RTP/AVP 0 101

a=rtpmap:0 PCMU/8000

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-16

a=sendrecv

-----------------------------------------

and RTP packets quickly follow and every thing works as it should.

The other one (Avaya IP Office) returns this:

-----------------------------------------

SIP/2.0 200 Ok

Via: SIP/2.0/UDP 10.10.10.190:5060;branch=z9hG4bK-d6ee-3479545-28138f1c

From: "Dennis Ernst via FMS" <sip:763@192.168.2.223:5060>;tag=43eddc0-0-13c4-5506-d6ee-2447e8b2-d6ee

To: <sip:755@192.168.2.223:5060>;tag=a7b6482bf0653b5b

Call-ID: 43f28f0-0-13c4-5506-d6ee-fb4d1d4-d6ee

CSeq: 1 INVITE

Contact: "Dennis Ernst" <sip:755@192.168.2.223:5060;transport=udp>

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, INFO, SUBSCRIBE, REGISTER, PUBLISH, UPDATE

X-Avaya-Name-Id: "514082926869" <sip:514082926869@192.168.2.223:5060>

Supported: timer

Content-Type: application/sdp

Content-Length: 205

v=0

o=UserA 2663674873 206985747 IN IP4 192.168.2.223

s=Session SDP

c=IN IP4 192.168.2.223

t=0 0

m=audio 49152 RTP/AVP 0 101

a=rtpmap:0 PCMU/8000

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-15

---------------------------------------------

Which doesn't work.  It doesn't send out any RTP packets and apparently doesn't set up to receive RTP packets because they

are rejected with ICMP "Portion unreachable" messages.

There are two extra fields in the failing case, but they don't seem relevant.

They only other differences I can see is the trivial one of not supporting DTMF flash (0-15 vs 0-16).  The other difference is that there

is no "a=sendrecv" in the failing case.   It is hard to see how this would make a difference because "a=sendrecv" is the default.

I guess though that FMG could have a bug that requires it and it was never tested against anything that didn't send "a=sendrecv".

Any other ideas??

Ernie