Re: [cisco-voip] Jabber/CIPC and QoS

[Hodgeman, Samuel]

For option 1, using Windows... this can be implemented with Group Policies, 
taking it out of the hands of end users, and can be associated with specific 
application executable and/or specific IP address source/destination.


-  Sam H

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of Ben 
Amick
Sent: Tuesday, January 03, 2017 3:25 PM
To: Cisco VoIP Group 
Subject: [cisco-voip] Jabber/CIPC and QoS

So, I know this is an age old question that's debated, but I've been wondering 
if anyone here has a perspective here in regards to QoS for softphones. 
Obviously, with hardphones, you usually partition a separate VLAN with 
AutoQoS/DSCP tags, but that isn't applicable with softphones.

I've heard of three different options in the past, neither of which seem to be 
very simple to deploy, but all seem to be Jabber-centric.

1.  Configuring windows to perform DSCP tagging, and do DSCP QoS on the 
switches they are connected to, as well as trusting the device. Problems: 
Requires users to be local admins, openings for abuse and network impact due to 
blind PC trust.

2.  Configuring your switches with an access list that recognizes the ports 
Jabber does outbound to attach DSCP tags to them. Problems: Other programs 
could theoretically use those ports

3.  Installing Medianet services on all jabber clients; Configure all 
switches for medianet tagging. Problem: (I think?) Requires newer switches to 
use, maybe needs an additional server (I vaguely remember possibly needing 
prime collab?)?

Maybe I'm missing some things, but what approach have you guys taken for 
softphone/Jabber QoS? And on top of that, what options are there for CIPC (I 
know there's the auto qos trust cisco-softphone for cisco switches, but I don't 
believe there's a solution other than #1 for non-cisco switches)?

Ben Amick
Telecom Analyst


Confidentiality Note: This message is intended for use only by the individual 
or entity to which it is addressed and may contain information that is 
privileged, confidential, and exempt from disclosure under applicable law. If 
the reader of this message is not the intended recipient or the employee or 
agent responsible for delivering the message to the intended recipient, you are 
hereby notified that any dissemination, distribution or copying of this 
communication is strictly prohibited. If you have received this communication 
in error, please contact the sender immediately and destroy the material in its 
entirety, whether electronic or hard copy. Thank you
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] SIP Caller ID issue

[Hodgeman, Samuel]

Well the SIP modification can certainly be done but I tell ya it is a royal 
pain in the buttockskis.

There is possibly a lower-complexity fix, not to the TECHNICAL issue but for 
the BUSINESS requirement.

Typically when customers have this issue, and I ask them WHY they truly need to 
send out that “main number” from another circuit (or even another carrier) as 
the caller id the answer is something like this:
“When we call somebody, and they decide to call us back at the number they see 
on their caller id (or with *67) we want the calls to go to our main number and 
NOT to the individual DID of the person who originally made the outbound call.”

One lower-complexity solution to this business requirement would be to 
designate one of the “allowed” numbers on the SIP service for use as the caller 
id, and simply call-forward-always that number back to your main number that 
resides on the PRI. If you want to avoid hairpinning issues, you can simply ask 
XO to do the forwarding in their Broadwords server so it never hits your system.

Another solution would be to again designate one of the “allowed” numbers on 
the SIP service for use as the caller id, and ask XO to set up “Configurable 
Calling Line ID” feature on that number. As I recall, that is a standard offer 
on the XO retail SIP trunks product. With this feature, the outbound call is 
SCREENED for access based on, for example, the “allowed” SIP number of the 
originating number sent from the ipPBX, but when that number hits the XO 
Broadworks server, the caller id can be configured to be automatically changed 
to ANY number that you own (you may need to prove that you own it) before it is 
forwarded back out to the greater PSTN.


-  Sam H

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of 
Charles Goldsmith
Sent: Friday, January 16, 2015 11:27 AM
To: Mike
Cc: voip puck
Subject: Re: [cisco-voip] SIP Caller ID issue

We see this a lot with carriers, it prevents scammers from changing caller-id 
info.  Some carriers will make an exception for things like main numbers, just 
have to prove you own that number, which isn't hard.

I've never went through the excercise of modifying the SIP header to resolve 
this.

On Fri, Jan 16, 2015 at 10:09 AM, Mike mik...@msn.commailto:mik...@msn.com 
wrote:
Hi all , I have a situation where the carrier (XO) is not allowing the call 
manager to send caller ID if it’s not a number assigned to the trunk. In this 
situation the main number is not on the sip trunk its on a PRI. The XO tech 
said you can get around this by modify the SIP header in the from field. Anyone 
ever ran into this?

Thanks,
Mike



___
cisco-voip mailing list
cisco-voip@puck.nether.netmailto:cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip