Feature request: codec policies based on subnets

[Mark Dutton]

Hi All

It would be great to be able to define codec policies based
on IP addresses/subnets, or even on SIP trunks and
gateways.

E.G. A low speed interconnect may need a codec policy of
g729,gsm, etc.

[Michael Picher]

Couldn't you do that now based on a phone group?

Also a particular gateway can be configured to prefer different codecs...

Mike

Post by Mark Dutton
Hi All
It would be great to be able to define codec policies based
on IP addresses/subnets, or even on SIP trunks and
gateways.
E.G. A low speed interconnect may need a codec policy of
g729,gsm, etc.
--
Regards
Mark Dutton
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

--
Michael Picher, Director of Technical Services
eZuce, Inc.

300 Brickstone Square****

Suite 201****

Andover, MA. 01810
O.978-296-1005 X2015
M.207-956-0262
@mpicher <http://twitter.com/mpicher>
linkedin <http://www.linkedin.com/profile/view?id=35504760&trk=tab_pro>
www.ezuce.com

------------------------------------------------------------------------------------------------------------
There are 10 kinds of people in the world, those who understand binary and
those who don't.

[Mark Dutton]

Yes i guess you could use groups for phones, but what if you
have say 3 sites, each with their own voice switch? Site 1
and site 2 have 10Mb/S lines, but site 3 has 1Mb/s and the
users are also using terminal services. They only want to
commit 200k to voice, but they want 6 call capacity. You are
now talking sipX to sipX and unless all the phones are set
to only use a low bandwidth codec, even for internal calls,
you are going to get a high bandwidth call.

Perhaps the sip trunks could be enhanced with codec lists.
When you create a trunk between two sites, the SIP trunk
will pass on only the allowed codecs for negotiation. If
the calling endpoint does not offer a suitable codec, then a
"488 not acceptable" would be returned from the SBC?

Maybe I am getting too ambitious.

[Tony Graziano]

Me thinks more bandwidth would be a better idea. In this type of instance
nothing will fix the problem without hitting it hard enough. Normally we
use a separate pass thru appliance to groom the internet bandwidth to keep
voice happy and prioritize by application (layer 7 stuff). We've never
found a more encompassing way of doing it that will auto recognize the
protocols we need given best priority.Even if this is what you do today,
using codec based policies, once your call capacity changes you are back to
the drawing board again. You might need to hunker down on whatever routers
you have an ensure you give your most important items best priority, but
I've never found a router that couldn't be fooled too easily by some new
app.

Post by Mark Dutton
Yes i guess you could use groups for phones, but what if you
have say 3 sites, each with their own voice switch? Site 1
and site 2 have 10Mb/S lines, but site 3 has 1Mb/s and the
users are also using terminal services. They only want to
commit 200k to voice, but they want 6 call capacity. You are
now talking sipX to sipX and unless all the phones are set
to only use a low bandwidth codec, even for internal calls,
you are going to get a high bandwidth call.
Perhaps the sip trunks could be enhanced with codec lists.
When you create a trunk between two sites, the SIP trunk
will pass on only the allowed codecs for negotiation. If
the calling endpoint does not offer a suitable codec, then a
"488 not acceptable" would be returned from the SBC?
Maybe I am getting too ambitious.
--
Regards
Mark Dutton
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

[Mark Dutton]

Actually Tony, I do agree with you to a point. Accommodating
higher bandwidth codecs is not really such a huge issue
these days. Even here in Australia bandwidth is getting
cheaper and I suppose we could end it there with this post.

I have another post where I am asking for admission control.
That is really the major issue as it is impossible to
control how many calls traverse a link no matter what the
protocol with sipX. All the QoS in the world won't help if
the source of the traffic is overcommitting itself.

[Tony Graziano]

I saw that post. I have not digested it yet. There are two different points
of view on it "within" the sip stack itself, but I will post that to the
appropriate thread after I get some rest and look at it fresh.

Post by Mark Dutton
Actually Tony, I do agree with you to a point. Accommodating
higher bandwidth codecs is not really such a huge issue
these days. Even here in Australia bandwidth is getting
cheaper and I suppose we could end it there with this post.
I have another post where I am asking for admission control.
That is really the major issue as it is impossible to
control how many calls traverse a link no matter what the
protocol with sipX. All the QoS in the world won't help if
the source of the traffic is overcommitting itself.
--
Regards
Mark Dutton
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: [phone]
sip: ***@voice.myitdepartment.net
Fax: [phone]
~~~~~~~~~~~~~~~~~~
Linked-In Profile:
http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4
Ask about our Internet Fax services!
~~~~~~~~~~~~~~~~~~

Using or developing for sipXecs from SIPFoundry? Ask me about sipX-CoLab
2013!
<http://sipxcolab2013.eventbrite.com/?discount=tony2013>

[Mark Dutton]

Rest?!!

It's Wednesday mid morning! :p

[Nathaniel Watkins]

It would add some expense, but a patton gateway can do call-rate-limiting. So you could send the call to the patton gateway, then have it setup where if a site to site call goes over the "limit" (say 4 simultaneous call paths), then send it a traditional pstn connection or to ext. xxxx (or voicemail/etc).

-----Original Message-----
From: sipx-users-***@list.sipfoundry.org [mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of Mark Dutton
Sent: Tuesday, July 24, 2012 11:36 PM
To: sipx-***@list.sipfoundry.org
Subject: Re: [sipx-users] Feature request: codec policies based on subnets

I have another post where I am asking for admission control.
That is really the major issue as it is impossible to control how many calls traverse a link no matter what the protocol with sipX. All the QoS in the world won't help if the source of the traffic is overcommitting itself.
--

This message and any files transmitted with it are intended only for the individual(s) or entity named. If you are not the intended individual(s) or entity named you are hereby notified that any disclosure, copying, distribution or reliance upon its contents is strictly prohibited. If you have received this in error, please notify the sender, delete the original, and destroy all copies. Email transmissions cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Garrett County Government therefore does not accept any liability for any errors or omissions in the contents of this message, which arise as a result of email transmission.


Garrett County Government,
203 South Fourth Street, Courthouse, Oakland, Maryland 21550 www.garrettcounty.org