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

Thu Dec 22 14:42:58 EST 2016

You raise a great point.  Since I'm just performing the initial test and 
turn up of this SIP trunk I placed my test route pattern in the DN 
partition which is what the Subscribe CSS points at.. This explains why 
I've generally not seen this before.

However, this gets me thinking.  With traditional PRI's we always 
created a site-specific partition for route patterns (or used SLRG) in 
order to ensure calls egress the correct PRI at the correct geographic 
location.

With centralized SIP services, one might be tempted to not do that and 
just dump the route patterns where all phones can reach them.  I think 
this experience shows that still having a separate partition for route 
patterns is still a good idea.

Interesting behavior in any case.

On 12/22/2016 12:28 PM, Brian Meade wrote:
> 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 
> <mailto: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.
>
>     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:
>
>     SUBSCRIBEsip: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:
>
>     SUBSCRIBEsip: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
>
>     Inline image 2
>
>     Inline image 1
>
>
>     Inline image 2
>
>     *SIP Trunk Setting*
>
>     Inline image 3
>
>     This stopped the subscribe messages from being sent to the CUBE.
>
>
>     _______________________________________________
>     cisco-voip mailing list
>     cisco-voip at puck.nether.net <mailto:cisco-voip at puck.nether.net>
>     https://puck.nether.net/mailman/listinfo/cisco-voip
>     <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/f041b2c3/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 24034 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20161222/f041b2c3/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 7376 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20161222/f041b2c3/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 6881 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20161222/f041b2c3/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 13507 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20161222/f041b2c3/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 12069 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20161222/f041b2c3/attachment-0004.png>