One more thing - I know I wrote "Cisco documentation recommends", but we all
know the CUPS documentation... For me it looks like it has not been updated
after PUBLISH method became available with 7.x.

In one place there is information that PUBLISH is supported/recommended with
CUCM 7.x, but on the wiki page describing CUCM configuration, there is only
information how to configure SUBSCRIBE methods.


On Thu, Jun 17, 2010 at 8:54 PM, kobel <findko...@gmail.com> wrote:

> Dear fellow CCIE wannabies,
>
> I was wondering what are your experiences with integrating CUPS with CUCM.
> AFAIK, there are two methods:
>  * SUBSCRIBE  - has to be used with CUCM releases <= 6.x (requires SIP
> trunk with correct SIP sec profile)
>  * PUBLISH - can be used with 7.x and later (PUBLISH trunk needs to be
> configured in CCM service params and in CUPS)
>
> The second one is recommended for performance reasons. The  difference is
> that with SUBSCRIBE, CUPS needs to sent to a CUCM a SUBSCRIBE message for
> specific presentity (e.g. DN) and only then receives NOTIFY messages with
> the presence state. With PUBLISH method, the CUCM sends PUBLISH messages to
> CUPS without any need for previous SUBSCRIBE messages.
>
> Now the question - proctor guide and CUPS documentation recommend
> configuring a SIP trunk with SIP Security Profile which allow SUBSCRIBE
> messages and SUBSCRIBE CSS. This would point to the first mechanism being
> used. But it seems that I'm able to have working presence without this, only
> configuring PUBLISH trunk (in CCM service parameters and in CUPS itself) - I
> see the line presence information in CUPC and IPPM - this shows that PUBLISH
> method works.
>
> I was wondering if you have the same experiences? Am I missing something
> about the way PUBLISH works? It looks like quicker configurtion method with
> the same results. Does it have any drawbacks I can't see?
>
> regards
> kobel
>
_______________________________________________
For more information regarding industry leading CCIE Lab training, please visit 
www.ipexpert.com

Reply via email to