UC560 v8.0 - Two distinct extension - share MWI message icon for one mailbox?

[alex_hannah]

Hello,

I have an interesting scenerio that I am not sure how to handle...  I have a customer with the following call flow:

1.  PRI routes calls into an AA at ext 850

2.  AA transfers calls out to a shared line on two receptionist phones ( ext 197 )

3.  If after 3 rings the receptionist doesn't answer, the call is transfered to another CUE AA script

4.  2nd AA transfers call out to a 2nd shared line on backup receptionist phones ( totally different ext 690 )

5.  After 3 rings there it Transfers back to ext 197 mailbox.

What they are wanting to do is to have the MWI mailbox icon turn on on both ext 197 and 690 should a message be left in 197's vm box.  I know I have done E.164 numbers in the past with the 2nd ext's directory information and normally it works.  However this time it is not and I am puzzled.

I am attaching the configuration for both CUE and CME to this thread.  Ephone-dn530 and 532 are the extensions in quesiton. In addition, I ran debug ccsip messages on the CME to see what was going on with VM notification and I never see ext 690 come from CUE for MWI notification.  Any thoughts?

025701: May 17 03:31:31.328: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
BYE sip:899@10.1.10.1:5060 SIP/2.0
Via: SIP/2.0/UDP 10.1.10.2:5060;branch=z9hG4bK198E14B6
From: "Karen Walsh" <sip:106@10.1.10.2>;tag=39FA889C-4C8
To: <sip:899@10.1.10.1>;tag=cuee3d5b47a
Date: Tue, 17 May 2011 03:31:01 GMT
Call-ID: EC1E4960-7F6C11E0-955AE5D6-D07438EB@10.1.10.2
User-Agent: Cisco-SIPGateway/IOS-12.x
Max-Forwards: 70
Timestamp: 1305603091
CSeq: 102 BYE
Reason: Q.850;cause=16
Content-Length: 0

0
CancerCenter_UC560#25702: May 17 03:31:31.332: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 200 Ok
Via: SIP/2.0/UDP 10.1.10.2:5060;branch=z9hG4bK198E14B6
To: <sip:899@10.1.10.1>;tag=cuee3d5b47a
From: "Karen Walsh" <sip:106@10.1.10.2>;tag=39FA889C-4C8
Call-ID: EC1E4960-7F6C11E0-955AE5D6-D07438EB@10.1.10.2
CSeq: 102 BYE
Content-Length: 0

025703: May 17 03:31:32.180: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
INVITE sip:A800197@10.1.10.2:5060;user=phone SIP/2.0
Via: SIP/2.0/UDP 10.1.10.1:5060;branch=z9hG4bKw8sLTn6BAGqA1x5K+IjAxA~~877
Max-Forwards: 70
To: <sip:A800197@10.1.10.2:5060;user=phone>
From: <sip:897@10.1.10.1:5060>;tag=cue98d82c02
Call-ID: 1305603092174431@10.1.10.1
CSeq: 1 INVITE
Content-Length: 172
Contact: <sip:897@10.1.10.1:5060>
Content-Type: application/sdp
Cisco-Gcid: FC022ECE-012F-1000-4000-001125CUCE68
Call-Info: <sip:10.1.10.1:5060>;method="NOTIFY;Event=telephone-event;Duration=2000"
Allow-Events: telephone-event

v=0
o=CiscoSystemsSIP-Workflow-App-UserAgen
CancerCenter_UC560#
CancerCenter_UC560#
CancerCenter_UC560#t 3792 3792 IN IP4 10.1.10.1
s=SIP Call
c=IN IP4 10.1.10.1
t=0 0
m=audio 16898 RTP/AVP 0
a=rtpmap:0 pcmu/8000
a=ptime:20

025704: May 17 03:31:32.196: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.1.10.1:5060;branch=z9hG4bKw8sLTn6BAGqA1x5K+IjAxA~~877
From: <sip:897@10.1.10.1:5060>;tag=cue98d82c02
To: <sip:A800197@10.1.10.2:5060;user=phone>
Date: Tue, 17 May 2011 03:31:32 GMT
Call-ID: 1305603092174431@10.1.10.1
CSeq: 1 INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-12.x
Content-Length: 0

025705: May 17 03:31:32.240: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 10.1.10.1:5060;branch=z9hG4bKw8sLTn6BAGqA1x5K+IjAxA~~877
From: <sip:897@10.1.10.1:5060>;tag=cue98d82c02
To: <sip:A800197@10.1.10.2:5060;user=phone>;tag=39FB0068-1198
Date: Tue, 17 May 2011 03:31:32 GMT
Call-ID: 1305603092174431@10.1.10.1
CSeq: 1 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Remote-Party-ID: <sip:A800000@10.1.10.2>;party=called;screen=no;privacy=off
Contact: <sip:A800197@10.1.10.2:5060>
Server: Cisco-SIPGateway/IOS-12.x
Content-Length: 0

025706: May 17 03:31:36.320: %SEC-6-IPACCESSLOGP: list 108 permitted udp 66.45.180.253(39611) -> 74.92.135.125(53), 1 packet 
025707: May 17 03:31:36.320: %SEC-6-IPACCESSLOGP: list 108 permitted udp 66.45.180.253(39621) -> 74.92.135.125(53), 1 packet 
025708: May 17 03:31:37.192: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
CANCEL sip:A800197@10.1.10.2:5060;user=phone SIP/2.0
Via: SIP/2.0/UDP 10.1.10.1:5060;branch=z9hG4bKw8sLTn6BAGqA1x5K+IjAxA~~877
Max-Forwards: 70
To: <sip:A800197@10.1.10.2:5060;user=phone>
From: <sip:897@10.1.10.1:5060>;tag=cue98d82c02
Call-ID: 1305603092174431@10.1.10.1
CSeq: 1 CANCEL
Content-Length: 0

025709: May 17 03:31:37.200: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.1.10.1:5060;branch=z9hG4bKw8sLTn6BAGqA1x5K+IjAxA~~877
From: <sip:897@10.1.10.1:5060>;tag=cue98d82c02
To: <sip:A800197@10.1.10.2:5060;user=phone>
Date: Tue, 17 May 2011 03:31:37 GMT
Call-ID: 1305603092174431@10.1.10.1
CSeq: 1 CANCEL
Content-Length: 0

025710: May 17 03:31:37.200: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 487 Request Cancelled
Via: SIP/2.0/UDP 10.1.10.1:5060;branch=z9hG4bKw8sLTn6BAGqA1x5K+IjAxA~~877
From: <sip:897@10.1.10.1:5060>;tag=cue98d82c02
To: <sip:A800197@10.1.10.2:5060;user=phone>;tag=39FB0068-1198
Date: Tue, 17 May 2011 03:31:37 GMT
Call-ID: 1305603092174431@10.1.10.1
CSeq: 1 INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-12.x
Reason: Q.850;cause=16
Content-Length: 0

025711: May 17 03:31:37.200: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
ACK sip:A800197@10.1.10.2:5060;user=phone SIP/2.0
Via: SIP/2.0/UDP 10.1.10.1:5060;branch=z9hG4bKw8sLTn6BAGqA1x5K+IjAxA~~877
Max-Forwards: 70
To: <sip:A800197@10.1.10.2:5060;user=phone>;tag=39FB0068-1198
From: <sip:897@10.1.10.1:5060>;tag=cue98d82c02
Call-ID: 1305603092174431@10.1.10.1
CSeq: 1 ACK
Content-Length: 0

Thanks!

Alex

[David Trad]

Hi Alex,

That is some funky call routing going on there

I am not sure that this is possible, because the CUE looks to the username and the attached extension, which could also be part of the authentication process, unless in CCA you can add another member to that mail box, potentially this could do what you want but I think that is only reserved for GDM's (General Delivery Mailboxes).

Would you consider an alternative call routing method to try and resolve this particular one?

For instance, Call comes into AA>>> Then AA Transfers the call to Blast Group 1 (Both Receptions are listed)>>> If no response the call is then transferred over to AA>>> AA then hands the call over to Blast Group 2 (Both Receptionist phones again)>>> If still no answer then call is passed over to the GDM for Blast Group 2... Blast Group 2 has two members assigned to it and both can check the GDM.

That is one way of doing it, the other is doing a shared DN and have it setup as Octo-Line (Accepts 8 Incoming Calls "They really need a Quad-Line") - and you can assign a Shared DN to each reception phone with both of them having each DN except one is set to silent ringing on and on the second round both are on normal ringing, this way you can have a Mail box for the primary DN and it will show up on both phones with an envelope next to the button.

They are the two ways I can think of at this stage, the question is if they can be done via CCA, that I am not too certain of.

However if you cannot alter the call routing method, then I am not sure how you can achieve what you want, but I am certain someone will pipe up on here who may have more of a clue than me on it

Cheers,

David.