[cisco-voip] CUCM sends presence subscribe messages to PSTN SIP trunk - found solution to block

[Brian Meade]

What subscribe CSS did you have set on the phones?  Usually you make it so
the Subscribe CSS can't hit anything but the DN partition(s).  The phone
will still send the Subscribe but CUCM won't forward it along.

On Thu, Dec 22, 2016 at 12:47 PM, Brian V <bvanbens at gmail.com> wrote:

> I'm working on remotely setting up a CUBE for a customer and I'm using
> CIPC (in sccp mode) to perform some basic testing.
>
> I have the *debug ccsip messages* enabled on the CUBE, and navigated to
> my placed calls directory on the CIPC phone.
>
> [image: Inline image 1]
>
> As soon as I did that I saw 2 subscribe messages show up on the CUBE from
> CUCM for the 2 numbers in the placed calls list.
>
> The CUCM cluster has BLF for call lists enabled.
>
> The 88. is a temp access code I'm using to send calls to the CUBE.  Route
> list strips the 88. and then pre-pends a 9
>
> This is reproducible, every time the placed calls list is opened, I see
> subscribe messages to CUBE for any of the calls that traversed it.
>
> CUBE didn’t respond to the messages and I don’t believe it will. But I can
> see in a large company not wanting to send all this messaging to CUBE.
>
>
>
> 000285: Dec 22 11:10:15.370: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>
> Received:
>
> SUBSCRIBE sip:918004444444 at 10.yy.2.6:5060 SIP/2.0
>
> Via: SIP/2.0/TCP 10.xx.8.6:5060;branch=z9hG4bK101c952867a3cc
>
> From: <sip:82ab6558-ed4e-c6fe-4655-9de41b0994a8 at 10.xx.8.6>;tag=1127369285
>
> To: <sip:918004444444 at 10.xx.2.6>
>
> Call-ID: 80367b00-85c108f7-ef000-608200a at 10.xx.8.6
>
> CSeq: 101 SUBSCRIBE
>
> Date: Thu, 22 Dec 2016 17:10:15 GMT
>
> User-Agent: Cisco-CUCM11.0
>
> Event: presence
>
> Expires: 10800
>
> Contact: <sip:82ab6558-ed4e-c6fe-4655-9de41b0994a8 at 10.xx.8.6:5060;
> transport=tcp>
>
> Accept: application/pidf+xml
>
> Max-Forwards: 69
>
> Content-Length: 0
>
>
>
>
>
> 000286: Dec 22 11:10:15.380: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>
> Received:
>
> SUBSCRIBE sip:918005532447 at 10.yy.2.6:5060 SIP/2.0
>
> Via: SIP/2.0/TCP 10.xx.8.6:5060;branch=z9hG4bK101c963da3f899
>
> From: <sip:82ab6558-ed4e-c6fe-4655-9de41b0994a8 at 10.xx.8.6>;tag=1494595130
>
> To: <sip:918005532447 at 10.xx.2.6>
>
> Call-ID: 80367b00-85c108f7-ef001-608200a at 10.xx.8.6
>
> CSeq: 101 SUBSCRIBE
>
> Date: Thu, 22 Dec 2016 17:10:15 GMT
>
> User-Agent: Cisco-CUCM11.0
>
> Event: presence
>
> Expires: 10800
>
> Contact: <sip:82ab6558-ed4e-c6fe-4655-9de41b0994a8 at 10.xx.8.6:5060;
> transport=tcp>
>
> Accept: application/pidf+xml
>
> Max-Forwards: 69
>
> Content-Length: 0
>
>
>
> Not sure if this is a CIPC quirk or if it’s a CUCM function to check BLF
> presence status on behalf of SCCP phones. (I'm leaning towards the latter,
> but since I'm currently remote I don’t have any other way to test SCCP
> phones at the moment)
>
>
>
> In any case, to stop the behavior I created another BLF presence Group,
> and blocked presence IN BOTH DIRECTIONS with the default group and then
> assigned the presence group to the sip trunk
>
>  [image: Inline image 2]
>
> [image: Inline image 1]
>
>
> [image: Inline image 2]
>
> *SIP Trunk Setting*
>
>  [image: Inline image 3]
>
> This stopped the subscribe messages from being sent to the CUBE.
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20161222/60e235ea/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 12069 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20161222/60e235ea/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 7376 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20161222/60e235ea/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 13507 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20161222/60e235ea/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 24034 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20161222/60e235ea/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 6881 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20161222/60e235ea/attachment-0004.png>