Brought over from the sipx-users list... 

Scott wrote:
> On Fri, 2009-07-31 at 15:55 -0400, Paul Mossman wrote:
> > 
> > Ranga wrote:
> > ...
> > > > Can we set these up in  a way that forces the phones to use alaw
> > > > (g711) between each other over the LAN and use G729 over
> > > the SIP trunk
> > > > (SIP trunk over DSL) to provider?
> > > 
> > > 
> > > No you cannot do that. May I ask you why you want to do that? 
> > > We used to have codec filtering in sipxbridge but it is 
> an ugly hack 
> > > and does not exist any longer for good reason.
> > > Codecs are negotiated end to end in sipx.
> > 
> > Because he wants calls out over his DSL line to chew as little 
> > bandwidth as possible.  The only way we can do it today is to 
> > configure the phones to use only G.729.  But then local 
> calls wouldn't 
> > be using the much higher bandwidth available on the LAN.
> > 
> > It would be nice to be able to configure, for each SIP 
> Trunk, the list 
> > of codecs may be used.  i.e. All SDP offers that pass through 
> > sipXbridge would have disallowed codecs removed.
> 
> The trouble is that at the time you send the INVITE (from the 
> phone), you don't have any way of knowing where the call will 
> go.  If I tell my extension to ring both my desk phone (LAN) 
> and my cell phone (PSTN, and therefor possibly that DSL 
> line), it's the _same_ invite forked at the proxy that goes to both.

I still don't see what the problem is.

The SDP offer manipulation would be done by sipXbridge, not by the
phone.  Only messages that pass through sipXbridge would be manipulated.

It wouldn't even matter which direction through sipXbridge that the SDP
offer passes.  The answerer would simply not see the disallowed codecs
in the offer, and the offerer would simply not see any of the 
disallowed codecs it offered in the answer.  

I suppose sipXbridge would also need special handling for the case where
an offer contains only disallowed codes.  The behaviour would depend on
whether the offer is in an INVITE or not...

But still, I think it would work.  Is there something I'm missing?


Thanks.


-Paul
[email protected]




_______________________________________________
sipx-dev mailing list [email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
sipXecs IP PBX -- http://www.sipfoundry.org/

Reply via email to