[cisco-voip] problem with part and css (the none partition)

Davis, Michael Michael_Davis at eLoyalty.com
Sun Dec 4 17:55:06 EST 2005


IIRC,  the IP Communicator was at some point based on the old Selsius Cisco 30 SP+ rather than CTI. Someone will correct me if I'm wrong.  I know this is definitely the case for CAD Media Termination clients, but am not certain about IP Communicator.
 
Either way, IP Communicator is configured as a hardware device and uses SCCP rather than JTAPI for control.  So in my mind it is a Software only IP Phone, not a "true" JTAPI controlled CTI device. So your testing is consistent with what I've seen.  However, things like IP Blue, Cisco Softphone,  CTI Ports/CTI Route Points and the JTAPI apps such as IPCC/IPCCX, etc) that control them are going to be affected.
 
I know the original post was specific to IP Communicator, but with all the discussion around how CSSes are processed, I thought I should add the caveat.
 
HTH clarify,
 
Mike
 

	-----Original Message----- 
	From: cisco-voip-bounces at puck.nether.net on behalf of Lelio Fulgenzi 
	Sent: Sun 12/4/2005 4:06 PM 
	To: Mark Snow; cisco-voip at puck.nether.net 
	Cc: 
	Subject: Re: [cisco-voip] problem with part and css (the none partition)
	
	
	And the other question is....I'm assuming this doesn't affect IPCommunicator? I ran a test in the lab and it created the PSS according to line+device. Is this because IP communicator is not a CTI application like Softphone? Are my results what you would expect?

		----- Original Message ----- 
		From: Mark Snow <mailto:highspeedsnow at gmail.com>  
		To: 'Lelio Fulgenzi' <mailto:lelio at uoguelph.ca>  ; cisco-voip at puck.nether.net 
		Sent: Sunday, December 04, 2005 4:20 PM
		Subject: RE: [cisco-voip] problem with part and css (the none partition)


		The answer probably lies with the PM, but I don’t know why or when …

		 

		
  _____  


		From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Lelio Fulgenzi
		Sent: Sunday, December 04, 2005 2:04 PM
		To: cisco-voip at puck.nether.net
		Subject: Re: [cisco-voip] problem with part and css (the none partition)

		 

		Is there any particular reason why they've gone this way with the CTIs? Are they eventually going to change it?

		 

			----- Original Message ----- 

			From: Davis, Michael <mailto:Michael_Davis at eLoyalty.com>  

			To: cisco-voip at puck.nether.net 

			Sent: Sunday, December 04, 2005 3:02 PM

			Subject: RE: [cisco-voip] problem with part and css (the none partition)

			 

			I don't have a whole lot of experience with 3.1, but I have recently been "burnt" by forgetting the CTI vs non-CTI search order. :-)
			
			-----Original Message----- 
			From: Mark Snow [mailto:highspeedsnow at gmail.com] 
			Sent: Sun 12/4/2005 1:47 PM 
			To: Davis, Michael; cisco-voip at puck.nether.net 
			Cc: 
			Subject: RE: [cisco-voip] problem with part and css (the none partition)
			
			
			
			Good Point!
			
			For those of you out there running versions prior to 3.1 when it was still
			'Call Mangler'.
			
			Also if you are running those previous versions, try Forwarding your phone
			to it's own DN and then calling it from another phone - just for fun! ;)
			
			> -----Original Message-----
			> From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-
			> bounces at puck.nether.net] On Behalf Of Davis, Michael
			> Sent: Sunday, December 04, 2005 1:36 PM
			> To: cisco-voip at puck.nether.net
			> Subject: RE: [cisco-voip] problem with part and css (the none partition)
			>
			> Also,
			> Prior to CCM 3.1, Device Level CSS were placed ahead of Line Level CSS.
			As of
			> 3.1, Line Level CSSes are placed ahead of Device Level, EXCEPT for CTI
			devices
			> (Softphone, CTI Ports, Route Points, etc,) which use the old method.
			>
			> Mike
			>
			>
			>       -----Original Message-----
			>       From: cisco-voip-bounces at puck.nether.net on behalf of Mark Snow
			>       Sent: Sun 12/4/2005 1:13 PM
			>       To: 'Lelio Fulgenzi'; cisco-voip at puck.nether.net
			>       Cc:
			>       Subject: RE: [cisco-voip] problem with part and css (the none
			partition)
			>
			>
			>
			>       Guys,
			>
			>
			>
			>       The <none> partition is actually a real partition, it is there by
			default and
			> is assigned to the very bottom of every CSS.
			>
			>
			>
			>       So if you had a RP of '91X' in the INTERAL_PT belonging to the
			> HQ_911_CSS and Phone 1 at HQ had this CSS assigned,  but you also had a RP
			of
			> '911' in in the <none> Partition (PT) and the user at Phone 1 at HQ dialed
			911, he
			> would actually be routed to the 911 RP in the <none> PT due to the fact
			that it
			> appears last in the HQ_911_CSS and is a longer match.
			>
			>
			>
			>       It is similar to the <null> MRG, which belongs at the very bottom of
			every
			> MRGL.
			>
			>
			>
			>       MTC and HTH some :-)
			>
			>
			>
			>       -Mark Snow
			>
			>       CCIE Voice # 14073
			>
			>
			>
			>
			>   _____
			>
			>
			>       From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-
			> bounces at puck.nether.net] On Behalf Of Lelio Fulgenzi
			>       Sent: Sunday, December 04, 2005 12:19 PM
			>       To: cisco-voip at puck.nether.net
			>       Subject: Re: [cisco-voip] problem with part and css (the none
			partition)
			>
			>
			>
			>       Oh yeah, and don't forget the <None> partition. It's not really a
			partition,
			> but it encompasses as DNs and patterns that have not been assigned to a
			> partition. There is no easy way to block access to these DNs unless you
			create
			> duplicate entries in another partition and block those (which we have
			done). I
			> can't remember the search algorithm and whether the <None> partition is
			simply
			> placed last in the ordered list and searched accordingly or if it is
			searched only
			> after no match is made in the other partitions. A search on CCO docs could
			tell
			> you this probably.
			>
			>
			>
			>       We've moved towards a dialplan model that has next to no DNs in the
			> <None> partition. The only ones we have in there are our campus emergency
			> number and our helpline number. In the event that a phone goes out
			> misconfigured, chances are very high they will be able to call these
			numbers.
			>
			>
			>
			>               ----- Original Message -----
			>
			>               From: Lelio Fulgenzi <mailto:lelio at uoguelph.ca>
			>
			>               To: James Grace <mailto:jgrace at digitelusa.net>  ; cisco-
			> voip at puck.nether.net
			>
			>               Sent: Sunday, December 04, 2005 1:13 PM
			>
			>               Subject: Re: [cisco-voip] problem with part and css
			>
			>
			>
			>               Think of it this way, a calling search space is simply an
			ordered
			> list of partitions which the line or device searches through for a match
			of the
			> dialed digits. If you look through the traces, you will see the term PSS
			which I
			> believe stands for Phone Search Space. This is made up of the line's
			ordered list of
			> partitions and then the device's ordered list of partitions. For example:
			>
			>
			>
			>               CSS1=PartA,PartB,PartC
			>
			>               CSS2=PartX,PartY,PartZ
			>
			>               Device assigned CSS1
			>
			>               Line assigned CSS2
			>
			>               the PSS would be: PartX,PartY,PartZ,PartA,PartB,PartC
			>
			>
			>
			>               So the idea you propose is a valid one. We use it here.
			Assign the
			> device access to everything and then deny the line access to particular
			services.
			> We isolate the 'everything' to PSTN access and actually allow oncampus
			access
			> through the line's partition.
			>
			>
			>
			>               You have to make sure that the denies are at least as
			specific as
			> the allows. And by denies, I mean, creating a route pattern that has the
			'block'
			> option checked.
			>
			>
			>
			>               Post back if you need more...
			>
			>
			>
			>
			>
			>
			>
			>                       ----- Original Message -----
			>
			>                       From: James Grace <mailto:jgrace at digitelusa.net>
			>
			>                       To: cisco-voip at puck.nether.net
			>
			>                       Sent: Sunday, December 04, 2005 12:35 PM
			>
			>                       Subject: [cisco-voip] problem with part and css
			>
			>
			>
			>                       we have a cm 4.1.2 es 41
			>
			>                       i was just told by a tac rep that 4.1. and higher
			uses both
			> css on line and device.
			>
			>                       what does this mean????
			>
			>
			>
			>                       i have my device as unrestricted and all of the part
			in it.
			> and then i have my line configure with a customize css, ie maybe no int
			calls or LD
			> calls.
			>
			>                       the problem im having is that when i make a ld or
			int call,
			> uses the device.  and when i make a ipphone call ( 4 dgit dialing between
			sites) it
			> uses the line. I dont understand this.  nore do i understand  the
			statement   IT
			> USES BOTH LINE AND DEVICE.   can someone Please clear this up for me.
			> Thanks in advance
			>
			>
			>   _____
			>
			>
			>                       _______________________________________________
			>                       cisco-voip mailing list
			>                       cisco-voip at puck.nether.net
			>                       https://puck.nether.net/mailman/listinfo/cisco-voip
			>
			>
			>   _____
			>
			>
			>               _______________________________________________
			>               cisco-voip mailing list
			>               cisco-voip at puck.nether.net
			>               https://puck.nether.net/mailman/listinfo/cisco-voip
			>
			>
			> _______________________________________________
			> cisco-voip mailing list
			> cisco-voip at puck.nether.net
			> https://puck.nether.net/mailman/listinfo/cisco-voip
			
			
			
			_______________________________________________
			cisco-voip mailing list
			cisco-voip at puck.nether.net
			https://puck.nether.net/mailman/listinfo/cisco-voip




More information about the cisco-voip mailing list