Mark, i can see it in the 1st INVITE Message came to the VGW from the CUCM :
INVITE sip:121355014@10.235.131.149:5060 SIP/2.0
Via: SIP/2.0/TCP 172.17.19.111:5060;branch=z9hG4bK2a521f66b10
From: <1356607>;tag=4277~197f0523-8faa-4c0c-b0eb-8005e8410b37-38680479
To: <121355014>
Date: Thu, 20 Sep 2012 00:56:34 GMT
Call-ID: 4a5d280-5a169c2-b1-6f1311ac@172.17.19.111
Supported: timer,resource-priority,replaces
Min-SE: 1800
User-Agent: Cisco-CUCM8.6
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
CSeq: 101 INVITE
Expires: 180
Allow-Events: presence, kpml
Supported: X-cisco-srtp-fallback
Supported: Geolocation
Call-Info: <172.17.19.111:5060>;method="NOTIFY;Event=telephone-event;Duration=500"
Cisco-Guid: 0077976192-0000065536-0000000172-1863520684
Session-Expires: 1800
P-Asserted-Identity: <1356607>
Remote-Party-ID: <1356607>;party=calling;screen=yes;privacy=off
Contact: <1356607>
Max-Forwards: 70
Content-Length: 0
please check below in SIP Standard RFC :
3.3.7. Allow-Events header usage
The "Allow-Events" header, if present, includes a list of tokens
which indicates the event packages supported by the client (if sent
in a request) or server (if sent in a response). In other words, a
node sending an "Allow-Events" header is advertising that it can
process SUBSCRIBE requests and generate NOTIFY requests for all of
the event packages listed in that header.
Any node implementing one or more event packages SHOULD include an
appropriate "Allow-Events" header indicating all supported events in
all methods which initiate dialogs and their responses (such as
INVITE) and OPTIONS responses.
This information is very useful, for example, in allowing user agents
to render particular interface elements appropriately according to
whether the events required to implement the features they represent
are supported by the appropriate nodes.
