Re: [asterisk-users] codec negotiation or transcoding issue
Asterisk might be unable to transcode rtp type from downstream to upstream, or vice versa. There's a bug reported here, for asterisk 12 or above, using chan_sip. https://issues.asterisk.org/jira/browse/ASTERISK-25676 It says that you could avoid the bug by using chan_pjsip, but you still encounter it? Turn `core set debug 5` to see whether you have `Unsupported payload type received` like I once did? rgds, On Wed, Mar 15, 2017 at 1:40 AM Faheem Muhammad wrote: > Hi, > I'm facing strange issue while establishing inbound calls from SIP trunks. > Provider A is sending (G729,Alaw,uLaw) offer and asterisk dial the peer > with its preferred codec order(G729,aLaw, uLaw). The peer's phone send the > codec list as (uLaw, speex) in 200 OK replay. The Peer's phone has selected > only uLaw and speed in this case. > > Ideally Asterisk should establish the call on uLaw codec, but Asterisk > establish the call with two codec for this call. For downstream RTP is > established with G729 and for upstream RTP is established with uLaw codec. > This behavior cause the one way audio for some phones like Eyebeam 1.5.9 > but Phonerlite latest version allow it and there is no audio issue. > > Is it normal SIP RFC 3261 behavior or there is something wrong with codec > negotiation or transcoding? > > I'm using Asterisk 13.14.0 with realtime chan_pjsip compiled with bundled > pjproject on centos 6.8_x64. I have tested it with Asterisk 11.x with > chan_sip and it works fine. > > Please advise me how can I setup the call based on late negotiation > mechanism? > > Thank you! > > > -- > _ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > > Check out the new Asterisk community forum at: > https://community.asterisk.org/ > > New to Asterisk? Start here: > https://wiki.asterisk.org/wiki/display/AST/Getting+Started > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: >http://lists.digium.com/mailman/listinfo/asterisk-users -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- Check out the new Asterisk community forum at: https://community.asterisk.org/ New to Asterisk? Start here: https://wiki.asterisk.org/wiki/display/AST/Getting+Started asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Codec Negotiation problem
Hi Matt Thanks for your response. I have tried with two GXV3175 with same result. Let me dig deep on this to find out the route cause Sam Matthew Jordan wrote: > On Thu, Jun 13, 2013 at 12:04 PM, wrote: > >> Hi there >> >> I have asterisk 10.11.1 which seems to have problem negotiating codec. >> >> Scenario: SIP PHONE1 (XLite) extension 1003, allowed codecs alaw, h263p >> and SIP phone2 (Grandstream GXV3175) extension 1004, allowed codec alaw, >> h263p. I have tried similar combination of codecs and SIP phone but when >> making a video call, it report "Peer doesn't provide video". It seems >> Asterisk is failing to set capability correct. Both codecs are enabled >> on >> the SIP Phones >> >> > > > The 200 OK response from the called XLite phone is declining the video > stream: > > <--- SIP read from UDP:10.10.10.129:48464 ---> > SIP/2.0 200 OK > Via: SIP/2.0/UDP 10.10.10.105:5060;branch=z9hG4bK368135b0;rport=5060 > Contact: > To: "SAM";tag=0c90cc0c > From: ;tag=as24914503 > Call-ID: MmNjOTczNDU5YjZmYjAyNWMxY2Q1MDZjODdhYzQwZjA > CSeq: 102 INVITE > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, > SUBSCRIBE, INFO > Content-Type: application/sdp > Supported: replaces, eventlist > User-Agent: X-Lite release 4.5.2 stamp 70142 > Content-Length: 234 > > v=0 > o=- 13015615910543193 2 IN IP4 10.10.10.129 > s=X-Lite 4 release 4.5.2 stamp 70142 > c=IN IP4 10.10.10.129 > t=0 0 > m=audio 53188 RTP/AVP 8 101 > a=rtpmap:101 telephone-event/8000 > a=fmtp:101 0-15 > a=sendrecv > m=video 0 RTP/AVP 115 > <-> > --- (12 headers 10 lines) --- > Found RTP audio format 8 > Found RTP audio format 101 > Found audio description format telephone-event for ID 101 > Capabilities: us - (alaw|h263p), peer - > audio=(alaw)/video=(nothing)/text=(nothing), combined - (alaw) > > Note that the port for the video stream is set to 0. > > Asterisk is doing the correct thing: it notes that the answer to its offer > declined the video stream, so it disables video for the call between the > two endpoints. > > Matt > > -- > Matthew Jordan > Digium, Inc. | Engineering Manager > 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA > Check us out at: http://digium.com & http://asterisk.org > -- > _ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > New to Asterisk? Join us for a live introductory webinar every Thurs: >http://www.asterisk.org/hello > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: >http://lists.digium.com/mailman/listinfo/asterisk-users -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Codec Negotiation problem
On Thu, Jun 13, 2013 at 12:04 PM, wrote: > Hi there > > I have asterisk 10.11.1 which seems to have problem negotiating codec. > > Scenario: SIP PHONE1 (XLite) extension 1003, allowed codecs alaw, h263p > and SIP phone2 (Grandstream GXV3175) extension 1004, allowed codec alaw, > h263p. I have tried similar combination of codecs and SIP phone but when > making a video call, it report "Peer doesn't provide video". It seems > Asterisk is failing to set capability correct. Both codecs are enabled on > the SIP Phones > > The 200 OK response from the called XLite phone is declining the video stream: <--- SIP read from UDP:10.10.10.129:48464 ---> SIP/2.0 200 OK Via: SIP/2.0/UDP 10.10.10.105:5060;branch=z9hG4bK368135b0;rport=5060 Contact: To: "SAM";tag=0c90cc0c From: ;tag=as24914503 Call-ID: MmNjOTczNDU5YjZmYjAyNWMxY2Q1MDZjODdhYzQwZjA CSeq: 102 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO Content-Type: application/sdp Supported: replaces, eventlist User-Agent: X-Lite release 4.5.2 stamp 70142 Content-Length: 234 v=0 o=- 13015615910543193 2 IN IP4 10.10.10.129 s=X-Lite 4 release 4.5.2 stamp 70142 c=IN IP4 10.10.10.129 t=0 0 m=audio 53188 RTP/AVP 8 101 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv m=video 0 RTP/AVP 115 <-> --- (12 headers 10 lines) --- Found RTP audio format 8 Found RTP audio format 101 Found audio description format telephone-event for ID 101 Capabilities: us - (alaw|h263p), peer - audio=(alaw)/video=(nothing)/text=(nothing), combined - (alaw) Note that the port for the video stream is set to 0. Asterisk is doing the correct thing: it notes that the answer to its offer declined the video stream, so it disables video for the call between the two endpoints. Matt -- Matthew Jordan Digium, Inc. | Engineering Manager 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Codec negotiation issue (no audio format found to offer)
This is an excerpt from rfc3264 in regards to modifying an existing session by the way: "At any point during the session, either participant MAY issue a new offer to modify characteristics of the session. It is fundamental to the operation of the offer/answer model that the exact same offer/answer procedure defined above is used for modifying parameters of an existing session." I understand the implementation would likely be complicated -- I noticed a ticket dating back to 2005 in regards to this. I'm wondering if the user communities' demand for this functionality is enough to justify adding it to the roadmap? -Ryan On Thu, Aug 4, 2011 at 11:06 AM, Ryan McGuire wrote: > > Thanks for the reply David, > I guess I don't understand an issue in implementing the offer/answer model > (rfc3264). If asterisk receives an invite and knows the egress peer's > capabilities, why not respond to the sdp in the initial invite with modified > sdp containing only g729? > So asterisk knows that it is going to dial a peer that supports only g729 > when it gets an invite from a peer that supports both ulaw and g729. Using > the offer / answer model it would look like this: > Peer -> Invite (SDP:ulaw,g729) -> Asterisk > Peer <- 100 Trying (w/ SDP -- g729 only) <- Asterisk > Peer -> 200 OK (w/ SDP g729) -> Asterisk > I understand your point about not knowing what may happen after initial call > setup, but the same implementation would apply in the event of a reinvite. > Maybe this could be an option (allow_rfc3264=yes or something of that nature). > Thanks again, > -Ryan > > On Thu, Aug 4, 2011 at 9:58 AM, David Vossel wrote: >> >> - Original Message - >> > From: "Ryan McGuire" >> > To: asterisk-users@lists.digium.com >> > Sent: Wednesday, August 3, 2011 9:47:42 AM >> > Subject: Re: [asterisk-users] Codec negotiation issue (no audio format >> > found to offer) >> > From looking into this, it appears as if this is due to Asterisk >> > negotiating the legs separately as if they were not related to the >> > same call. So the ingress leg negotiates ulaw, and despite it knowing >> > that the peer also supports g729 fails the call since it's already >> > decided on ulaw and the egress leg only accepts g729. >> > >> > >> > If this is design intent I'm wondering if there is demand enough to >> > justify a feature request? >> > >> > >> > Any advice on how I can work around this issue? >> > >> > >> > Thanks, >> > >> > >> > -Ryan >> >> This is a much more complicated issue than Asterisk negotiating each call >> leg separate of one another. Even if we give one call leg information about >> call setup occurring on the other call leg it is about to be bridged to, we >> are dependent on the endpoints honoring the codec preference priority we >> send them to avoid translation between one codec and another during the >> bridge... Honoring the preference order in the SDP does not always occur, >> which means that any effort in this area would only work in a perfect >> scenario. >> >> Even if we get call legs to negotiate perfectly before being bridged during >> call setup, we are not guaranteed that translation will not occur later if >> the call is transfered or parked. Regardless of what we do, if your setup >> allows ulaw and g729 for sip peers, you will always run the risk of a codec >> mixmatch... You may however be able to avoid this for some cases by using >> the sip.conf preferred_codec_only option. I believe that will limit the >> codecs negotiated during call setup to the single codec currently chosen on >> the other call leg. The problem with this is that we are not guaranteed the >> call leg supplying the codec will not change later. >> >> -- >> David Vossel >> Digium, Inc. | Software Developer, Open Source Software >> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA >> Check us out at: www.digium.com & www.asterisk.org >> The_Boy_Wonder in #asterisk-dev >> >> -- >> _ >> -- Bandwidth and Colocation Provided by http://www.api-digital.com -- >> New to Asterisk? Join us for a live introductory webinar every Thurs: >> http://www.asterisk.org/hello >> >> asterisk-users mailing list >> To UNSUBSCRIBE or update options visit: >> http://lists.digium.com/mailman/listinfo/asterisk-users > -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Codec negotiation issue (no audio format found to offer)
Thanks for the reply David, I guess I don't understand an issue in implementing the offer/answer model (rfc3264). If asterisk receives an invite and knows the egress peer's capabilities, why not respond to the sdp in the initial invite with modified sdp containing only g729? So asterisk knows that it is going to dial a peer that supports only g729 when it gets an invite from a peer that supports both ulaw and g729. Using the offer / answer model it would look like this: Peer -> Invite (SDP:ulaw,g729) -> Asterisk Peer <- 100 Trying (w/ SDP -- g729 only) <- Asterisk Peer -> 200 OK (w/ SDP g729) -> Asterisk I understand your point about not knowing what may happen after initial call setup, but the same implementation would apply in the event of a reinvite. Maybe this could be an option (allow_rfc3264=yes or something of that nature). Thanks again, -Ryan On Thu, Aug 4, 2011 at 9:58 AM, David Vossel wrote: > - Original Message - > > From: "Ryan McGuire" > > To: asterisk-users@lists.digium.com > > Sent: Wednesday, August 3, 2011 9:47:42 AM > > Subject: Re: [asterisk-users] Codec negotiation issue (no audio format > found to offer) > > From looking into this, it appears as if this is due to Asterisk > > negotiating the legs separately as if they were not related to the > > same call. So the ingress leg negotiates ulaw, and despite it knowing > > that the peer also supports g729 fails the call since it's already > > decided on ulaw and the egress leg only accepts g729. > > > > > > If this is design intent I'm wondering if there is demand enough to > > justify a feature request? > > > > > > Any advice on how I can work around this issue? > > > > > > Thanks, > > > > > > -Ryan > > This is a much more complicated issue than Asterisk negotiating each call > leg separate of one another. Even if we give one call leg information about > call setup occurring on the other call leg it is about to be bridged to, we > are dependent on the endpoints honoring the codec preference priority we > send them to avoid translation between one codec and another during the > bridge... Honoring the preference order in the SDP does not always occur, > which means that any effort in this area would only work in a perfect > scenario. > > Even if we get call legs to negotiate perfectly before being bridged during > call setup, we are not guaranteed that translation will not occur later if > the call is transfered or parked. Regardless of what we do, if your setup > allows ulaw and g729 for sip peers, you will always run the risk of a codec > mixmatch... You may however be able to avoid this for some cases by using > the sip.conf preferred_codec_only option. I believe that will limit the > codecs negotiated during call setup to the single codec currently chosen on > the other call leg. The problem with this is that we are not guaranteed the > call leg supplying the codec will not change later. > > -- > David Vossel > Digium, Inc. | Software Developer, Open Source Software > 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA > Check us out at: www.digium.com & www.asterisk.org > The_Boy_Wonder in #asterisk-dev > > -- > _ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > New to Asterisk? Join us for a live introductory webinar every Thurs: > http://www.asterisk.org/hello > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users > -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Codec negotiation issue (no audio format found to offer)
- Original Message - > From: "Ryan McGuire" > To: asterisk-users@lists.digium.com > Sent: Wednesday, August 3, 2011 9:47:42 AM > Subject: Re: [asterisk-users] Codec negotiation issue (no audio format found > to offer) > From looking into this, it appears as if this is due to Asterisk > negotiating the legs separately as if they were not related to the > same call. So the ingress leg negotiates ulaw, and despite it knowing > that the peer also supports g729 fails the call since it's already > decided on ulaw and the egress leg only accepts g729. > > > If this is design intent I'm wondering if there is demand enough to > justify a feature request? > > > Any advice on how I can work around this issue? > > > Thanks, > > > -Ryan This is a much more complicated issue than Asterisk negotiating each call leg separate of one another. Even if we give one call leg information about call setup occurring on the other call leg it is about to be bridged to, we are dependent on the endpoints honoring the codec preference priority we send them to avoid translation between one codec and another during the bridge... Honoring the preference order in the SDP does not always occur, which means that any effort in this area would only work in a perfect scenario. Even if we get call legs to negotiate perfectly before being bridged during call setup, we are not guaranteed that translation will not occur later if the call is transfered or parked. Regardless of what we do, if your setup allows ulaw and g729 for sip peers, you will always run the risk of a codec mixmatch... You may however be able to avoid this for some cases by using the sip.conf preferred_codec_only option. I believe that will limit the codecs negotiated during call setup to the single codec currently chosen on the other call leg. The problem with this is that we are not guaranteed the call leg supplying the codec will not change later. -- David Vossel Digium, Inc. | Software Developer, Open Source Software 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: www.digium.com & www.asterisk.org The_Boy_Wonder in #asterisk-dev -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Codec negotiation issue (no audio format found to offer)
>From looking into this, it appears as if this is due to Asterisk negotiating the legs separately as if they were not related to the same call. So the ingress leg negotiates ulaw, and despite it knowing that the peer also supports g729 fails the call since it's already decided on ulaw and the egress leg only accepts g729. If this is design intent I'm wondering if there is demand enough to justify a feature request? Any advice on how I can work around this issue? Thanks, -Ryan On Tue, Aug 2, 2011 at 3:51 PM, Ryan McGuire wrote: > Running build 1.8.5.0 (compiled from source) I seem to be having an issue > with codec negotiation. I have a Grandstream HT503 FXO port connected to a > pstn line, a Polycom SP501, and a SIP trunk with callwithus. > > What I'm essentially looking to accomplish is for ulaw or g729 (preferably > ulaw) to be used to the Grandstream FXO or any other internal endpoint, and > for g729 only to be used outbound to my SIP trunk. > > Here are the basics of my config, showing the codec list from "sip show > peer ": > > Polycom SP501 (desk phone): > -- > disallow=all > allow=ulaw&g729 > Codecs : 0x104 (ulaw|g729) > Codec Order : (ulaw:20,g729:20) > > Grandstream HT503 (fxo gateway): > -- > disallow=all > allow=ulaw&g729 > Codecs : 0x104 (ulaw|g729) > Codec Order : (ulaw:20,g729:20) > > CallWithUs (SIP trunk): > -- > disallow=all > allow=g729 > Codecs : 0x100 (g729) > Codec Order : (g729:20) > > When I place an outbound call from the Polycom to callwithus, the invite > from the pcom shows both ulaw and g729 in the SDP: > INVITE sip:@192.168.0.1;user=phone SIP/2.0 > Via: SIP/2.0/UDP 192.168.0.201;branch=z9hG4bKc8aa981a8B8FF58D > From: "Office" ;tag=4CD2B2A0-B94A2531 > To: > [...] > m=audio 2258 RTP/AVP 18 0 8 101 > a=rtpmap:18 G729/8000 > a=fmtp:18 annexb=no > a=rtpmap:0 PCMU/8000 > a=rtpmap:8 PCMA/8000 > a=rtpmap:101 telephone-event/8000 > > Asterisk sees this: > [Aug 2 15:00:31] VERBOSE[1918] chan_sip.c: Capabilities: us - 0x104 > (ulaw|g729), peer - audio=0x10c (ulaw|alaw|g729)/video=0x0 > (nothing)/text=0x0 (nothing), combined - 0x104 (ulaw|g729) > > The call goes out the callwithus trunk: > [Aug 2 15:00:31] VERBOSE[1315] pbx.c: -- Executing > [s@macro-dialout-trunk:19] Dial("SIP/2001-0047", > "SIP/CallWithUs/**,300,tTwW") in new stack > > And then this, no INVITE goes out to callwithus at all: > [Aug 2 15:00:31] WARNING[1315] chan_sip.c: No audio format found to offer. > Cancelling call to ** > [Aug 2 15:00:31] VERBOSE[1315] app_dial.c: -- Couldn't call > SIP/CallWithUs/** > > Similarly, if I set the Grandstream FXO trunk to ulaw only, the call fails > as well. It seems as if allowing only a single codec is the issue, if I > change the priorities of all codecs to g729 first and ulaw second, the call > goes through as g729 successfully. > > Smells like a bug to me, but I may be overlooking something in my config. > > Thanks, > > -Ryan > -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Codec negotiation
Hi, If you will send call without answering on asterisk and have directrtpsetup=yes in sip.conf codec negociation will always be between UAs so any matched codec will work fine. If you are answering call on asterisk then dialing it out to next UA then you need to add canreinvite=yes for both UAs. Regards, Faisal P peers calling each other: A (g722, alaw) calls B (alaw,ulaw) via asterisk. My setup: allow=g722,alaw preferred_codec_only=no Note that when B calls A, codec alaw is used on both ends, fine, but it does not seem to work the reverse way (A is using g722, B is using alaw, asterisk is doing transcoding). Is it possible? Thanks, Ondrej -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Codec negotiation : expecting G726, getting G711a (alaw)
> Only when I configure my Grandstream to use only G726 (I have 8 > choices), I see that the g726-codec is used. > When I configure 7 x g726 and 1 x alaw, then again alaw is used ! > > Is it normal that Asterisk has such a great preference for alaw ?! The > moment the peer suggests codec alaw (even if it is last choice), alaw is > chosen by Asterisk for the communication. Please look at the first part of my last message (order of codecs in the [general] section) and apply changes there, followed by a "sip reload". Philipp -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Codec negotiation : expecting G726, getting G711a (alaw)
On 08/03/2010 04:21 PM, Philipp von Klitzing wrote: > Also: > > There are at least two implementations of the g726 codec, i.e. g726 and > g726aal2. For this also look at the g726nonstandard setting in sip.conf. > It is quite possible that your problem is here. > I have the following setting in sip.conf : g726nonstandard = no ; If the peer negotiates G726-32 audio, use AAL2 packing ; order instead of RFC3551 packing order (this is required ; for Sipura and Grandstream ATAs, among others). This is ; contrary to the RFC3551 specification, the peer _should_ ; be negotiating AAL2-G726-32 instead (so it uses RFC3551) > For quick testing to see if the codec works at all: Configure your phones > to do g726 only (so no alaw/ualaw at all). > Only when I configure my Grandstream to use only G726 (I have 8 choices), I see that the g726-codec is used. When I configure 7 x g726 and 1 x alaw, then again alaw is used ! Is it normal that Asterisk has such a great preference for alaw ?! The moment the peer suggests codec alaw (even if it is last choice), alaw is chosen by Asterisk for the communication. Kind regards, Jonas. -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Codec negotiation : expecting G726, getting G711a (alaw)
Hi! > In the [general] section of sip.conf I have : > > disallow=all > allow=g726 > allow=alaw > allow=g729 > allow=gsm So change the order there and see what happens. > > * look at the variable SIP_CODEC for the inbound (first) call leg, and > > in Asterisk 1.8 (or 1.6.2?) also at SIP_CODEC_OUTBOUND > > When I read the value of this variable just before the Dial()-statement, > it is empty. You need to set it, not read it. Philipp -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Codec negotiation : expecting G726, getting G711a (alaw)
Also: There are at least two implementations of the g726 codec, i.e. g726 and g726aal2. For this also look at the g726nonstandard setting in sip.conf. It is quite possible that your problem is here. For quick testing to see if the codec works at all: Configure your phones to do g726 only (so no alaw/ualaw at all). Philipp -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Codec negotiation : expecting G726, getting G711a (alaw)
Hello Philipp, thank you for your answer. On 08/03/2010 01:21 PM, Philipp von Klitzing wrote: >> Question 3 : >> How can I get g726 as first preferred codec ?? >> > Which Asterisk version are you using? > Using Asterisk 1.4.30 > * check if you have disallow/allow settings in the [general] section of > sip.conf. Depending on your Asterisk version only the order in [general] > would be respected, but not the order in the individual sip peer/user > definition > In the [general] section of sip.conf I have : disallow=all allow=g726 allow=alaw allow=g729 allow=gsm > * look at the variable SIP_CODEC for the inbound (first) call leg, and in > Asterisk 1.8 (or 1.6.2?) also at SIP_CODEC_OUTBOUND > When I read the value of this variable just before the Dial()-statement, it is empty. Jonas. -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Codec negotiation : expecting G726, getting G711a (alaw)
Hi! > Question 1 : > [Aug 2 13:56:57] Capabilities: us - 0x90a (gsm|alaw|g726|g729), peer - > audio=0x808 (alaw|g726)/video=0x0 (nothing), combined - 0x808 (alaw|g726) > why is combined alaw|g726 and not g726|alaw (reverse) ?? Guess: Here the order presented has no meaning for the order of codec negotiation. > Question 2 : > why do I see on my Grandstream phone that the codec being used is alaw in > stead of g726 ?? Because that is what the phone and Asterisk have negotiated. ;-) > Question 3 : > How can I get g726 as first preferred codec ?? Which Asterisk version are you using? * check if you have disallow/allow settings in the [general] section of sip.conf. Depending on your Asterisk version only the order in [general] would be respected, but not the order in the individual sip peer/user definition * look at the variable SIP_CODEC for the inbound (first) call leg, and in Asterisk 1.8 (or 1.6.2?) also at SIP_CODEC_OUTBOUND * many Asterisk operators have applied the third party "codec negotiation patch" Philipp -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Codec negotiation
On Tue, Jun 29, 2010 at 6:42 PM, Philipp von Klitzing wrote: > Hi! > >> Because the codec is already chosen before the call is made, and you >> told it that g722 is permitted. >> >> There are all sorts of discussions in play about codec negotiation, >> but at this point in time, if you want different behaviour you'll need to >> go and code it yourself > > Look at the list archive - there is a codec negotiation patch around: > > http://lists.digium.com/pipermail/asterisk-users/2010- > February/244835.html > > The OP might also want to consider to use different lines to the same > PBX, one for normal narrowband, and another one for g722. > > Philipp > > > -- Thanks! I'm going to try setting the _SIP_CODEC variable for outbound calls to force ulaw. This should solve the issue. Having two lines would work but I can't sell this to a customer. There has got to be a better way to have Asterisk handle this. With Asterisk in the middle of the RTP stream it knows what both parties support. If it turns out Asterisk is transcoding it could check for a common codec and renegotiate one endpoint. Ryan -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Codec negotiation
Hi! > Does the 1.4.26.2-patch also work with asterisk 1.4.30 ?? Most probably - who on this list would you like to test it for you? ;-> Philipp -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Codec negotiation
Hi! > Because the codec is already chosen before the call is made, and you > told it that g722 is permitted. > > There are all sorts of discussions in play about codec negotiation, > but at this point in time, if you want different behaviour you'll need to > go and code it yourself Look at the list archive - there is a codec negotiation patch around: http://lists.digium.com/pipermail/asterisk-users/2010- February/244835.html The OP might also want to consider to use different lines to the same PBX, one for normal narrowband, and another one for g722. Philipp -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Codec negotiation
Does the 1.4.26.2-patch also work with asterisk 1.4.30 ?? I have reported a codec-issue, but there is no solution. Will this patch also answer my question ?? https://issues.asterisk.org/view.php?id=17020 Jonas. On 06/29/2010 09:42 PM, Mindaugas Kezys wrote: Try this: http://www.b2bua.org/wiki/AsteriskCodecNegotiationPatch Regards, Mindaugas Kezys Kolmisoft UAB VoIP Billing Solutions e-mail: i...@kolmisoft.com URL: http://www.kolmisoft.com -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Codec negotiation
>From what I have seen if your sip provider does not take g722 then you will have problems with outgoing calls. When I tried this, the same way you did, I could make calles externally but had no audio each way reguardless of what I tried to pass to the sip provider. Best bet is to use what your sip provider can use or find another provider that that can do g722. That's what I did when I wanted to use g726. my2cents On Tue, Jun 29, 2010 at 2:42 PM, Mindaugas Kezys wrote: > Try this: http://www.b2bua.org/wiki/AsteriskCodecNegotiationPatch > > Regards, > Mindaugas Kezys > > Kolmisoft UAB > VoIP Billing Solutions > e-mail: i...@kolmisoft.com > URL: http://www.kolmisoft.com > > > -Original Message- > From: asterisk-users-boun...@lists.digium.com > [mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Steve Davies > Sent: Tuesday, June 29, 2010 7:51 PM > To: Asterisk Users Mailing List - Non-Commercial Discussion > Subject: Re: [asterisk-users] Codec negotiation > > On 26 June 2010 22:08, Ryan Wagoner wrote: > > I have Polycom phones that support the g722 codec. Adding allow=g722 > > to the [general] section of sip.conf works great and I can make calls > > between the phones using g722. However Asterisk is negotiating g722 > > for calls going out my voip provider and transcoding these to ulaw. In > > sip.conf for the provider I have deny=all and allow=ulaw. This can > > cause potential audio degrading and wastes cpu cycles. If Asterisk > > knows the trunk only supports ulaw why would it offer g722 to the > > phone. > > > > Ryan > > Because the codec is already chosen before the call is made, and you > told it that g722 is permitted. > > There are all sorts of discussions in play about codec negotiation, > but at this point in time, if you want different behaviour you'll need > to go and code it yourself, and cross-channeltype this is not going to > be trivial :) > > Cheers, > Steve > > -- > _ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > New to Asterisk? Join us for a live introductory webinar every Thurs: > http://www.asterisk.org/hello > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users > > > -- > _ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > New to Asterisk? Join us for a live introductory webinar every Thurs: > http://www.asterisk.org/hello > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users > -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Codec negotiation
Try this: http://www.b2bua.org/wiki/AsteriskCodecNegotiationPatch Regards, Mindaugas Kezys Kolmisoft UAB VoIP Billing Solutions e-mail: i...@kolmisoft.com URL: http://www.kolmisoft.com -Original Message- From: asterisk-users-boun...@lists.digium.com [mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Steve Davies Sent: Tuesday, June 29, 2010 7:51 PM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] Codec negotiation On 26 June 2010 22:08, Ryan Wagoner wrote: > I have Polycom phones that support the g722 codec. Adding allow=g722 > to the [general] section of sip.conf works great and I can make calls > between the phones using g722. However Asterisk is negotiating g722 > for calls going out my voip provider and transcoding these to ulaw. In > sip.conf for the provider I have deny=all and allow=ulaw. This can > cause potential audio degrading and wastes cpu cycles. If Asterisk > knows the trunk only supports ulaw why would it offer g722 to the > phone. > > Ryan Because the codec is already chosen before the call is made, and you told it that g722 is permitted. There are all sorts of discussions in play about codec negotiation, but at this point in time, if you want different behaviour you'll need to go and code it yourself, and cross-channeltype this is not going to be trivial :) Cheers, Steve -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Codec negotiation
On 26 June 2010 22:08, Ryan Wagoner wrote: > I have Polycom phones that support the g722 codec. Adding allow=g722 > to the [general] section of sip.conf works great and I can make calls > between the phones using g722. However Asterisk is negotiating g722 > for calls going out my voip provider and transcoding these to ulaw. In > sip.conf for the provider I have deny=all and allow=ulaw. This can > cause potential audio degrading and wastes cpu cycles. If Asterisk > knows the trunk only supports ulaw why would it offer g722 to the > phone. > > Ryan Because the codec is already chosen before the call is made, and you told it that g722 is permitted. There are all sorts of discussions in play about codec negotiation, but at this point in time, if you want different behaviour you'll need to go and code it yourself, and cross-channeltype this is not going to be trivial :) Cheers, Steve -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Codec negotiation for Thomson ST2030 and g729
On Mon, Jul 7, 2008 at 12:18 PM, Olivier <[EMAIL PROTECTED]> wrote: > If my memory serves me right, we could use Thomson ST2030 and Asterisk 1.4. > Have you tried with another soft or hardphone ? Why not??? ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Codec negotiation for Thomson ST2030 and g729
If my memory serves me right, we could use Thomson ST2030 and Asterisk 1.4. Have you tried with another soft or hardphone ? 2008/7/7 Vinz486 <[EMAIL PROTECTED]>: > Hi all, > > i'm trouble with codec setup on an asterisk machine 1.4.18 and some > Thomson ST2030 as extensions. > > In the users.conf file for internal extension i have: > > disallow=all > allow=g729 > allow=alaw > allow=ulaw > > Without any codec installed (i mean with original g729 of asterisk) > all go fine, calling from an extension to one other: > > Peer User/ANRCall ID Seq (Tx/Rx) Format > Hold Last Message > 10.9.9.9 202 11a6323d2ff 00102/0 0x100 (g729) > No Tx: ACK > 10.9.9.10201 a8749-c0a80 00101/1 0x100 (g729) > No Rx: ACK > > > Installing the open source binary of g279 (codec_g729.so in modules > dir) and restarting asterisk, the same call require transcoding: > > Peer User/ANRCall ID Seq (Tx/Rx) Format > Hold Last Message > 10.9.9.9 202 1992c2d149e 00102/0 0x8 (alaw) > No Tx: ACK > 10.9.9.10201 140a6d-c0a8 00101/1 0x100 (g729) > No Rx: ACK > > The CALLED extension uses alaw instead of g729. > > This uses a lot of CPU (up to 10% in my P3 machine). > > Where is the trouble? Asterisk bug? Thomson do not recognize g729 GPL > as standard g729? I must set the framebuffer size? > > If i set ONLY g729 as allowed codec all go fine: all calls uses the g729 > codec. > > Why codec negotian in the allow= list is not respected? Depends on > codec binary? It's strange... > > > Thanks to all... > > > > > --- > PicoStreamer - the real WEB live streaming software > vinz486.com > > ___ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > > AstriCon 2008 - September 22 - 25 Phoenix, Arizona > Register Now: http://www.astricon.net > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users > ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Codec Negotiation
I do not need g723.1 codec, this is not the problem, here is another description of the problem: The client offer 2 codecs (g729 and g723) for all calls, my server accept only g729, so normally the client & server will negotiate the codec and both sides agrees on g729, but this does not happened always, sometimes for some reason, my server reject the call giving a codec error below, which means that both sides did not nogotiate the codec correctly. On 7/12/07, Jared Smith <[EMAIL PROTECTED]> wrote: On Thu, 2007-07-12 at 14:39 -0400, Al Bochter wrote: > So who do you pay to use the G723 codec? It's possible to use the G.723.1 codec with Asterisk by buying a Digium TC400B transcoder card[1]. Without that card, the best Asterisk can do is to pass through the packets, but it can't doing any transcoding to/from G.723.1 without the hardware card. --- Jared Smith Community Relations Manager Digium, Inc. [1] http://www.digium.com/en/products/hardware/tc400b.php ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Codec Negotiation
On Thu, 2007-07-12 at 14:39 -0400, Al Bochter wrote: > So who do you pay to use the G723 codec? It's possible to use the G.723.1 codec with Asterisk by buying a Digium TC400B transcoder card[1]. Without that card, the best Asterisk can do is to pass through the packets, but it can't doing any transcoding to/from G.723.1 without the hardware card. --- Jared Smith Community Relations Manager Digium, Inc. [1] http://www.digium.com/en/products/hardware/tc400b.php ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Codec Negotiation
On 7/12/07, O. Kamal <[EMAIL PROTECTED]> wrote: I am having a problem with my asterisk gateway, it is accepting only G729, the client is offering G729 and G723.1, however for some reasons, around 15% of calls are rejected due to failed codec negotiation giving an codec error "No compatible codecs, not accepting this offer". Anyone gone through this before? you can allow UA to accept other codecs by adding allow=ulaw.others in sip.conf ram ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Codec Negotiation
So who do you pay to use the G723 codec? Best regards, Al Bochter http://www.BochterServices.com --- See what we are selling at auction http://www.epier.com/auctions.asp?bochterservices --- Take a look at our online store http://www.bochterservices.com/onlinestore/ --- O.Kamal wrote: I am having a problem with my asterisk gateway, it is accepting only G729, the client is offering G729 and G723.1, however for some reasons, around 15% of calls are rejected due to failed codec negotiation giving an codec error "No compatible codecs, not accepting this offer". Anyone gone through this before? ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users Inbound (clean). Database: 000756-0, 07/12/2007 - 7/12/2007 2:21:04 PM ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Codec Negotiation
- Douglas Garstang <[EMAIL PROTECTED]> wrote: > I expected Asterisk to send G711 instead, as that's what is set in > [general] in sip.conf And as you've already learned, Asterisk will reorder the codecs in the outbound INVITE so that the codec used on the incoming channel is listed as first preference on the INVITE, so that it can minimize the number of times that transcoding is necessary. -- Kevin P. Fleming Senior Software Engineer Digium, Inc. ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Codec Negotiation
On Fri July 21 2006 18:33, "Woodoo People .pGa!" <[EMAIL PROTECTED]> wrote: > don't forget the following: > if canreinvite=yes, asterisk will NOT stay in mediapath, so, it going to > ask both parties to negotiate codec, and say hello to the stream. (if > both parties supports g729, and can negotiate it, no licence will be > used) if canreinvite=no, * will STAY in mediapath, so both parties will > negotiate with asterisk itself, and will not care about other side. that > means, if caller has g729, and callee has g711, asterisk WILL transcode. > if both parties have g729, asterisk will NOT transcode, but 2 licence > will be used! Hi there. In your last example, why would any g729 licenses be used? If both parties use g729, wouldn't the call just pass through Asterisk without any licenses being used? Cheers, -- Nick e: [EMAIL PROTECTED] p: +61 7 5591 3588 f: +61 7 5591 6588 If you receive this email by mistake, please notify us and do not make any use of the email. We do not waive any privilege, confidentiality or copyright associated with it. ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
RE: [asterisk-users] Codec Negotiation
> -Original Message- > From: Joshua Colp [mailto:[EMAIL PROTECTED] > Sent: Friday, July 21, 2006 9:38 AM > To: Asterisk Users Mailing List - Non-Commercial Discussion > Subject: RE: [asterisk-users] Codec Negotiation > > > - Original Message - > From: Douglas Garstang > [mailto:[EMAIL PROTECTED] > To: [EMAIL PROTECTED], Asterisk > Users Mailing List - Non-Commercial Discussion > [mailto:[EMAIL PROTECTED] > Sent: Fri, 21 Jul 2006 16:21:15 > -0300 > Subject: RE: [asterisk-users] Codec Negotiation > > > > Well, I wish someone would tell Kevin Fleming that. > > > > So... the realtime architecture can work when shared between > servers - but not all the time, and it depends on certain > variables. Multiple servers can grab the same information > from the database, but it doesn't mean they will be able to > contact the phone for example. This is what Kevin was talking > about. If a phone is behind NAT and registers to one Asterisk > machine, the device doing the NAT will setup in it's memory a > mapping of the external port to the internal IP+port. > Depending on the implementation and setup, only the server > that the phone registered to will be able to send packets > back. Thus if you have failover to another server for > example, that server will not be able to contact the phone. > > Like I said, there's too many variables to make it work all > the time... > > Now - you can pull information in order for them to be able > to place calls. That should be fine. Don't know about that. I'm not sure why he brought NAT up, as I didn't mention it. Might be a red herring I think. ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
RE: [asterisk-users] Codec Negotiation
- Original Message - From: Douglas Garstang [mailto:[EMAIL PROTECTED] To: [EMAIL PROTECTED], Asterisk Users Mailing List - Non-Commercial Discussion [mailto:[EMAIL PROTECTED] Sent: Fri, 21 Jul 2006 16:21:15 -0300 Subject: RE: [asterisk-users] Codec Negotiation > Well, I wish someone would tell Kevin Fleming that. > So... the realtime architecture can work when shared between servers - but not all the time, and it depends on certain variables. Multiple servers can grab the same information from the database, but it doesn't mean they will be able to contact the phone for example. This is what Kevin was talking about. If a phone is behind NAT and registers to one Asterisk machine, the device doing the NAT will setup in it's memory a mapping of the external port to the internal IP+port. Depending on the implementation and setup, only the server that the phone registered to will be able to send packets back. Thus if you have failover to another server for example, that server will not be able to contact the phone. Like I said, there's too many variables to make it work all the time... Now - you can pull information in order for them to be able to place calls. That should be fine. Joshua Colp Digium ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
RE: [asterisk-users] Codec Negotiation
Well, I wish someone would tell Kevin Fleming that. > -Original Message- > From: olivier.taylor [mailto:[EMAIL PROTECTED] > Sent: Friday, July 21, 2006 1:04 PM > To: Asterisk Users Mailing List - Non-Commercial Discussion > Subject: Re: [asterisk-users] Codec Negotiation > > > I must agree, > > we use 2 Ser in front of 4 asterisk sharing the same database cluster. > > Olivier > > Brian Capouch a écrit : > > Douglas Garstang wrote: > > > >> > >> > >> Would you like me to dig up the posts from Keving Fleming stating > >> that this is known not to work Brian? > > > > As I recall those posts have to do with the way your > particular setup > > required ARA to work with a failover/redundant cluster > system you were > > building. > > > > Beyond that I'm not really interested in getting into a pissing > > contest. I have ONE SQL table called "extensions_table" on ONE SQL > > server, but have maybe 20 SIP phones using that same > database, placing > > calls from 10-12 separate Asterisk instances. > > > > I was calling into question your presenting a "well-known > fact" that > > appears to be incorrect. If Kevin sees this and wants to > chime in to > > support your statement and tell me that my experience is somehow an > > illusion, he's certainly welcome to do so. I have experienced the > > taste of crow, and eat it when needed. You? > > > > Can certain situations be construed where ARA will not do > exactly what > > the administrator wants? Apparently, from reading some of > your posts, > > true. > > > > Can multiple Asterisk servers be set up to use a single database > > instance to store common configuration information? > Certainly true, > > from my and many other people's experiences. > > > > The thrust of my post was to refute the "fact," and to suggest you > > perhaps adopt a little less inflammatory rhetoric when you post to > > this list. > > > > B. > > > ___ > --Bandwidth and Colocation provided by Easynews.com -- > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: >http://lists.digium.com/mailman/listinfo/asterisk-users > ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Codec Negotiation
I must agree, we use 2 Ser in front of 4 asterisk sharing the same database cluster. Olivier Brian Capouch a écrit : Douglas Garstang wrote: Would you like me to dig up the posts from Keving Fleming stating that this is known not to work Brian? As I recall those posts have to do with the way your particular setup required ARA to work with a failover/redundant cluster system you were building. Beyond that I'm not really interested in getting into a pissing contest. I have ONE SQL table called "extensions_table" on ONE SQL server, but have maybe 20 SIP phones using that same database, placing calls from 10-12 separate Asterisk instances. I was calling into question your presenting a "well-known fact" that appears to be incorrect. If Kevin sees this and wants to chime in to support your statement and tell me that my experience is somehow an illusion, he's certainly welcome to do so. I have experienced the taste of crow, and eat it when needed. You? Can certain situations be construed where ARA will not do exactly what the administrator wants? Apparently, from reading some of your posts, true. Can multiple Asterisk servers be set up to use a single database instance to store common configuration information? Certainly true, from my and many other people's experiences. The thrust of my post was to refute the "fact," and to suggest you perhaps adopt a little less inflammatory rhetoric when you post to this list. B. ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
RE: [asterisk-users] Codec Negotiation
> -Original Message- > From: Brian Capouch [mailto:[EMAIL PROTECTED] > Sent: Friday, July 21, 2006 12:08 PM > To: Asterisk Users Mailing List - Non-Commercial Discussion > Subject: Re: [asterisk-users] Codec Negotiation > > > Douglas Garstang wrote: > > > > > > > Would you like me to dig up the posts from Keving Fleming > stating that this is known not to work Brian? > > As I recall those posts have to do with the way your particular setup > required ARA to work with a failover/redundant cluster system > you were > building. > > Beyond that I'm not really interested in getting into a > pissing contest. > I have ONE SQL table called "extensions_table" on ONE SQL > server, but > have maybe 20 SIP phones using that same database, placing calls from > 10-12 separate Asterisk instances. > > I was calling into question your presenting a "well-known fact" that > appears to be incorrect. If Kevin sees this and wants to chime in to > support your statement and tell me that my experience is somehow an > illusion, he's certainly welcome to do so. I have > experienced the taste > of crow, and eat it when needed. You? > > Can certain situations be construed where ARA will not do > exactly what > the administrator wants? Apparently, from reading some of > your posts, true. > > Can multiple Asterisk servers be set up to use a single database > instance to store common configuration information? Certainly true, > from my and many other people's experiences. > > The thrust of my post was to refute the "fact," and to suggest you > perhaps adopt a little less inflammatory rhetoric when you > post to this > list. Here's a post Kevin Fleming made to the group on Dec 12, 2005, in response to my question on this subject. I was quite clear about my question, and does not involve clustering, only N number of Asterisk boxes all pointed to the same database. It seems his reply is also quite clear. It's good that it's working for you. I guess you got lucky. "Douglas Garstang wrote: > Thanks while we're on the topic of realtime. Can realtime sipusers be > shared amongst multiple Asterisk boxes, to share a common location database? > I'm sitting here on a Sunday jerking around with it, having problems. I'd > like to know before I spend more Sundays doing the same thing if it's even > supposed to work or not. Uhhh... you already quoted my previous message on that topic stating that it was not supported at this time. In any given situation, it may or may not work properly, depending on exactly what the servers and clients are doing. Even if the code had been written, there will still be many issues involved in actually implementing it, including (but not limited to) NAT traversal, call limit handling, registration expiration and others. It also mandates that there can be _no_ caching of peer/user information in memory, which currently means there is no 'qualify' or MWI notification possible." Doug ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Codec Negotiation
Douglas Garstang wrote: Would you like me to dig up the posts from Keving Fleming stating that this is known not to work Brian? As I recall those posts have to do with the way your particular setup required ARA to work with a failover/redundant cluster system you were building. Beyond that I'm not really interested in getting into a pissing contest. I have ONE SQL table called "extensions_table" on ONE SQL server, but have maybe 20 SIP phones using that same database, placing calls from 10-12 separate Asterisk instances. I was calling into question your presenting a "well-known fact" that appears to be incorrect. If Kevin sees this and wants to chime in to support your statement and tell me that my experience is somehow an illusion, he's certainly welcome to do so. I have experienced the taste of crow, and eat it when needed. You? Can certain situations be construed where ARA will not do exactly what the administrator wants? Apparently, from reading some of your posts, true. Can multiple Asterisk servers be set up to use a single database instance to store common configuration information? Certainly true, from my and many other people's experiences. The thrust of my post was to refute the "fact," and to suggest you perhaps adopt a little less inflammatory rhetoric when you post to this list. B. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
RE: [asterisk-users] Codec Negotiation
> -Original Message- > From: Brian Capouch [mailto:[EMAIL PROTECTED] > Sent: Friday, July 21, 2006 11:33 AM > To: Asterisk Users Mailing List - Non-Commercial Discussion > Subject: Re: [asterisk-users] Codec Negotiation > > > Douglas Garstang wrote: > > Can't put it in a realtime database. We have multiple > Asterisk boxes in a cluster, and it's a well known fact that > multiple Asterisk boxes using realime cannot query a common > MySQL database. Sounds crazy, but true. > > > > You spread some amazing "well-known facts" on this list. As usual > salted with your typical choice of words that implies that > Asterisk has > "crazy" flaws that no sane programmer would countenance. > > I have a dozen or more Asterisk boxes that all query the exact same > Realtime database. The setup works fine, and the "time to > deploy" a new > station with very elaborate functionality is reduced to minutes. The > ability to rearrange behaviors on the fly is also a great feature. I > love ARA. > > I use Postgres and not MySQL, but I can't believe that the > choice is SQL > engine would make a difference. > > I think you confuse the requirements of your deployment > scenario, which > a few minutes ago on this list you yourself characterized as > "ridiculous," with underlying common features of Asterisk used in > quotidian circumstances. Would you like me to dig up the posts from Keving Fleming stating that this is known not to work Brian? ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Codec Negotiation
Douglas Garstang wrote: Can't put it in a realtime database. We have multiple Asterisk boxes in a cluster, and it's a well known fact that multiple Asterisk boxes using realime cannot query a common MySQL database. Sounds crazy, but true. You spread some amazing "well-known facts" on this list. As usual salted with your typical choice of words that implies that Asterisk has "crazy" flaws that no sane programmer would countenance. I have a dozen or more Asterisk boxes that all query the exact same Realtime database. The setup works fine, and the "time to deploy" a new station with very elaborate functionality is reduced to minutes. The ability to rearrange behaviors on the fly is also a great feature. I love ARA. I use Postgres and not MySQL, but I can't believe that the choice is SQL engine would make a difference. I think you confuse the requirements of your deployment scenario, which a few minutes ago on this list you yourself characterized as "ridiculous," with underlying common features of Asterisk used in quotidian circumstances. B. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
RE: [asterisk-users] Codec Negotiation
Can't put it in a realtime database. We have multiple Asterisk boxes in a cluster, and it's a well known fact that multiple Asterisk boxes using realime cannot query a common MySQL database. Sounds crazy, but true. Doug. > -Original Message- > From: Marco Mouta [mailto:[EMAIL PROTECTED] > Sent: Friday, July 21, 2006 4:14 AM > To: Asterisk Users Mailing List - Non-Commercial Discussion > Subject: Re: [asterisk-users] Codec Negotiation > > > Just an idea: > > Put this Slow-Phone sip account into sip realtime database, and > outside of asterisk manage to verify G729 licenses availability and > script it to your SIP-realtime. > > This way every call to this SIP account will go to SIP realtime > database that is being changed by an external script that just > monitors your G729 licences, and keeps on track which codec is going > to be used: Ulaw or G729. > > Don't know if this is a good idea, just a suggestion. > > Best regards, > Marco Mouta > > On 7/21/06, Woodoo People .pGa! <[EMAIL PROTECTED]> wrote: > > > >No, we aren't intending to check for available g729 codecs > > > >that's why we wanted to have ulaw as a backup when no g729 codecs > > > >where available. > > > > > > > That won't work. If it's trying to use G729, it will > still try even > > > when the licenses are all in use. So you need to either > force it g729 > > > and make sure there are always licenses for it available, > or use ulaw > > > and make sure there is enough bandwidth. > > > > > > The other option is to write your own code that checks to > verify the > > > licenses are free somehow, and then tampers with the codec > > > preferences? I think Brett (trixter) has some ideas/work in this > > > direction already. > > > > i heard somewhere, when g729 licences are gone, it will > work as g711, > > is this info FAKE? > > > > > > -- > > WoodOO-[P]an[G]alaktikan[A]gent-People <][> http://shadow.pganet.com > > > [EMAIL PROTECTED] > [EMAIL PROTECTED] > > ___ > > --Bandwidth and Colocation provided by Easynews.com -- > > > > asterisk-users mailing list > > To UNSUBSCRIBE or update options visit: > >http://lists.digium.com/mailman/listinfo/asterisk-users > > > > > -- > Com os melhores cumprimentos, > > Marco Mouta > ___ > --Bandwidth and Colocation provided by Easynews.com -- > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: >http://lists.digium.com/mailman/listinfo/asterisk-users > ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Codec Negotiation
On Jul 21, 2006, at 3:01 AM, Woodoo People .pGa! wrote: No, we aren't intending to check for available g729 codecs that's why we wanted to have ulaw as a backup when no g729 codecs where available. That won't work. If it's trying to use G729, it will still try even when the licenses are all in use. So you need to either force it g729 and make sure there are always licenses for it available, or use ulaw and make sure there is enough bandwidth. The other option is to write your own code that checks to verify the licenses are free somehow, and then tampers with the codec preferences? I think Brett (trixter) has some ideas/work in this direction already. i heard somewhere, when g729 licences are gone, it will work as g711, is this info FAKE? I believe that's incorrect. ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Codec Negotiation
Just an idea: Put this Slow-Phone sip account into sip realtime database, and outside of asterisk manage to verify G729 licenses availability and script it to your SIP-realtime. This way every call to this SIP account will go to SIP realtime database that is being changed by an external script that just monitors your G729 licences, and keeps on track which codec is going to be used: Ulaw or G729. Don't know if this is a good idea, just a suggestion. Best regards, Marco Mouta On 7/21/06, Woodoo People .pGa! <[EMAIL PROTECTED]> wrote: > >No, we aren't intending to check for available g729 codecs > >that's why we wanted to have ulaw as a backup when no g729 codecs > >where available. > > > That won't work. If it's trying to use G729, it will still try even > when the licenses are all in use. So you need to either force it g729 > and make sure there are always licenses for it available, or use ulaw > and make sure there is enough bandwidth. > > The other option is to write your own code that checks to verify the > licenses are free somehow, and then tampers with the codec > preferences? I think Brett (trixter) has some ideas/work in this > direction already. i heard somewhere, when g729 licences are gone, it will work as g711, is this info FAKE? -- WoodOO-[P]an[G]alaktikan[A]gent-People <][> http://shadow.pganet.com [EMAIL PROTECTED]@RedHat.users ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users -- Com os melhores cumprimentos, Marco Mouta ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Codec Negotiation
> >No, we aren't intending to check for available g729 codecs > >that's why we wanted to have ulaw as a backup when no g729 codecs > >where available. > > > That won't work. If it's trying to use G729, it will still try even > when the licenses are all in use. So you need to either force it g729 > and make sure there are always licenses for it available, or use ulaw > and make sure there is enough bandwidth. > > The other option is to write your own code that checks to verify the > licenses are free somehow, and then tampers with the codec > preferences? I think Brett (trixter) has some ideas/work in this > direction already. i heard somewhere, when g729 licences are gone, it will work as g711, is this info FAKE? -- WoodOO-[P]an[G]alaktikan[A]gent-People <][> http://shadow.pganet.com [EMAIL PROTECTED]@RedHat.users ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Codec Negotiation
> I have two polycom phones. One on a slow link, and one on a fast one. > I'm trying to set the phone on the slow link to use G729 as it's first > preference, and the phone on the fast link to use G711 as it's first > preference. > > sip.conf has: > [general] > allow=ulaw > allow=g729 > > [slow-link] ; Override codecs for slow link phone. > allow = g729 > allow = ulaw > > When the slow link phone dialls the fast link phone, it sends G729 as it's > first preference in the INVITE to Asterisk. Asterisk then sends G729 as the > first preference in the INVITE to the fast link phone. Why doesn't Asterisk > send G711 instead? > > This raises an interesting question. If one phone uses G729, and one G711, > then Asterisk is going to have to transcode, and I am going to use up a G729 > license. It would seem more beneficial for it to work the way it is now. That > is, both legs are using G729. Why is this better? It doesn't chew up a G729 > license as there is no transcoding, and heck, if one of your call legs is > G729, then the G711 party isn't going to hear anything better anyway. > > Thoughts? don't forget the following: if canreinvite=yes, asterisk will NOT stay in mediapath, so, it going to ask both parties to negotiate codec, and say hello to the stream. (if both parties supports g729, and can negotiate it, no licence will be used) if canreinvite=no, * will STAY in mediapath, so both parties will negotiate with asterisk itself, and will not care about other side. that means, if caller has g729, and callee has g711, asterisk WILL transcode. if both parties have g729, asterisk will NOT transcode, but 2 licence will be used! as i experienced, the codec order in sip.conf [general] will take priority over [user] -- WoodOO-[P]an[G]alaktikan[A]gent-People <][> http://shadow.pganet.com [EMAIL PROTECTED]@RedHat.users ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Codec Negotiation
On Jul 20, 2006, at 11:41 AM, Douglas Garstang wrote: Sorry for the top posting. My email client is misbehaving. Can't use gsm. The polycom phones only support g711/ulaw and g729. No, we aren't intending to check for available g729 codecs that's why we wanted to have ulaw as a backup when no g729 codecs where available. That won't work. If it's trying to use G729, it will still try even when the licenses are all in use. So you need to either force it g729 and make sure there are always licenses for it available, or use ulaw and make sure there is enough bandwidth.The other option is to write your own code that checks to verify the licenses are free somehow, and then tampers with the codec preferences? I think Brett (trixter) has some ideas/work in this direction already.Marty -Original Message-From: Martin Joseph [mailto:[EMAIL PROTECTED]]Sent: Thursday, July 20, 2006 12:34 PMTo: Asterisk Users Mailing List - Non-Commercial DiscussionSubject: Re: [asterisk-users] Codec NegotiationOn Jul 20, 2006, at 11:00 AM, Douglas Garstang wrote: Subject: Re: [asterisk-users] Codec NegotiationOn Jul 20, 2006, at 10:16 AM, Douglas Garstang wrote: I'm a little confused about Asterisk codec negotiation. Hopefully someone can help. I have two phones, one on a slow link where I'd like to use G729, and one on a fast link where I'd like to use ulaw. My sip.conf has: [general]allow=ulawallow=g729...[slow-phone]allow=g729allow=ulaw Firstly, does setting the codec for the slow-link phone override the general settings? Of course it's not actually documented anywhere. When the fast link phone calls the slow link phone, it sends ulaw and G729 in that order to Asterisk. When Asterisk relays the INVITE to the slow link phone, it does not change the codec preference, and sends ulaw followed by G729. I end up with a call that's ulaw on both legs, which isn't what I want. I guess the settings in [slow-phone] aren't overriding the settings in [general]. That's bad...How can I work around this?As you already stated in your previous post the slow phone codec pref does override general when it's the caller. I think the calling parties codec preferences are respected. That is why I suggested the last time you posted this that you "force" the slow link to g729 (allow that only), as that will cause the calling party (fast) to choose g729 also...I remember reading this described somewhere, but can't find the docs at the moment.HTH, Marty Marty, Ahhh I wasn't thinking about the fact that it would be keyed of the callers settings, rather than the callee's. However, setting the slow-link phone to g729 isn't a very workable solution. We want to have ulaw as a backup, in case all of our g729 licenses are in use. Having the call completely fail in this case would be very bad. We should be able to have the slow-link phone negotiate to ulaw. Are you intending to implement some logic to check for available g729 codecs? Because asterisk doesn't do this for you... What about using some form of unrestricted codec like GSM instead for the slow link?Don't know any great solutions for you... Marty ___--Bandwidth and Colocation provided by Easynews.com --asterisk-users mailing listTo UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
RE: [asterisk-users] Codec Negotiation
Sorry for the top posting. My email client is misbehaving. Can't use gsm. The polycom phones only support g711/ulaw and g729. No, we aren't intending to check for available g729 codecs that's why we wanted to have ulaw as a backup when no g729 codecs where available. -Original Message-From: Martin Joseph [mailto:[EMAIL PROTECTED]Sent: Thursday, July 20, 2006 12:34 PMTo: Asterisk Users Mailing List - Non-Commercial DiscussionSubject: Re: [asterisk-users] Codec Negotiation On Jul 20, 2006, at 11:00 AM, Douglas Garstang wrote: Subject: Re: [asterisk-users] Codec Negotiation On Jul 20, 2006, at 10:16 AM, Douglas Garstang wrote: I'm a little confused about Asterisk codec negotiation. Hopefully someone can help. I have two phones, one on a slow link where I'd like to use G729, and one on a fast link where I'd like to use ulaw. My sip.conf has: [general] allow=ulawallow=g729 ... [slow-phone] allow=g729 allow=ulaw Firstly, does setting the codec for the slow-link phone override the general settings? Of course it's not actually documented anywhere. When the fast link phone calls the slow link phone, it sends ulaw and G729 in that order to Asterisk. When Asterisk relays the INVITE to the slow link phone, it does not change the codec preference, and sends ulaw followed by G729. I end up with a call that's ulaw on both legs, which isn't what I want. I guess the settings in [slow-phone] aren't overriding the settings in [general]. That's bad... How can I work around this?As you already stated in your previous post the slow phone codec pref does override general when it's the caller. I think the calling parties codec preferences are respected. That is why I suggested the last time you posted this that you "force" the slow link to g729 (allow that only), as that will cause the calling party (fast) to choose g729 also... I remember reading this described somewhere, but can't find the docs at the moment. HTH, Marty Marty, Ahhh I wasn't thinking about the fact that it would be keyed of the callers settings, rather than the callee's. However, setting the slow-link phone to g729 isn't a very workable solution. We want to have ulaw as a backup, in case all of our g729 licenses are in use. Having the call completely fail in this case would be very bad. We should be able to have the slow-link phone negotiate to ulaw. Are you intending to implement some logic to check for available g729 codecs? Because asterisk doesn't do this for you... What about using some form of unrestricted codec like GSM instead for the slow link? Don't know any great solutions for you... Marty ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Codec Negotiation
On Jul 20, 2006, at 11:00 AM, Douglas Garstang wrote:Subject: Re: [asterisk-users] Codec NegotiationOn Jul 20, 2006, at 10:16 AM, Douglas Garstang wrote:I'm a little confused about Asterisk codec negotiation. Hopefully someone can help. I have two phones, one on a slow link where I'd like to use G729, and one on a fast link where I'd like to use ulaw. My sip.conf has: [general]allow=ulawallow=g729...[slow-phone]allow=g729allow=ulaw Firstly, does setting the codec for the slow-link phone override the general settings? Of course it's not actually documented anywhere. When the fast link phone calls the slow link phone, it sends ulaw and G729 in that order to Asterisk. When Asterisk relays the INVITE to the slow link phone, it does not change the codec preference, and sends ulaw followed by G729. I end up with a call that's ulaw on both legs, which isn't what I want. I guess the settings in [slow-phone] aren't overriding the settings in [general]. That's bad...How can I work around this?As you already stated in your previous post the slow phone codec pref does override general when it's the caller.I think the calling parties codec preferences are respected. That is why I suggested the last time you posted this that you "force" the slow link to g729 (allow that only), as that will cause the calling party (fast) to choose g729 also...I remember reading this described somewhere, but can't find the docs at the moment.HTH,Marty Marty, Ahhh I wasn't thinking about the fact that it would be keyed of the callers settings, rather than the callee's. However, setting the slow-link phone to g729 isn't a very workable solution. We want to have ulaw as a backup, in case all of our g729 licenses are in use. Having the call completely fail in this case would be very bad. We should be able to have the slow-link phone negotiate to ulaw. Are you intending to implement some logic to check for available g729 codecs? Because asterisk doesn't do this for you... What about using some form of unrestricted codec like GSM instead for the slow link?Don't know any great solutions for you...Marty___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
RE: [asterisk-users] Codec Negotiation
Marty, Ahhh I wasn't thinking about the fact that it would be keyed of the callers settings, rather than the callee's. However, setting the slow-link phone to g729 isn't a very workable solution. We want to have ulaw as a backup, in case all of our g729 licenses are in use. Having the call completely fail in this case would be very bad. We should be able to have the slow-link phone negotiate to ulaw. Doug. -Original Message-From: Martin Joseph [mailto:[EMAIL PROTECTED]Sent: Thursday, July 20, 2006 11:31 AMTo: Asterisk Users Mailing List - Non-Commercial DiscussionSubject: Re: [asterisk-users] Codec Negotiation On Jul 20, 2006, at 10:16 AM, Douglas Garstang wrote: I'm a little confused about Asterisk codec negotiation. Hopefully someone can help. I have two phones, one on a slow link where I'd like to use G729, and one on a fast link where I'd like to use ulaw. My sip.conf has: [general] allow=ulawallow=g729 ... [slow-phone] allow=g729 allow=ulaw Firstly, does setting the codec for the slow-link phone override the general settings? Of course it's not actually documented anywhere. When the fast link phone calls the slow link phone, it sends ulaw and G729 in that order to Asterisk. When Asterisk relays the INVITE to the slow link phone, it does not change the codec preference, and sends ulaw followed by G729. I end up with a call that's ulaw on both legs, which isn't what I want. I guess the settings in [slow-phone] aren't overriding the settings in [general]. That's bad... How can I work around this?As you already stated in your previous post the slow phone codec pref does override general when it's the caller. I think the calling parties codec preferences are respected. That is why I suggested the last time you posted this that you "force" the slow link to g729 (allow that only), as that will cause the calling party (fast) to choose g729 also... I remember reading this described somewhere, but can't find the docs at the moment. HTH, Marty ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Codec Negotiation
On Jul 20, 2006, at 10:16 AM, Douglas Garstang wrote: I'm a little confused about Asterisk codec negotiation. Hopefully someone can help. I have two phones, one on a slow link where I'd like to use G729, and one on a fast link where I'd like to use ulaw. My sip.conf has: [general] allow=ulawallow=g729 ... [slow-phone] allow=g729 allow=ulaw Firstly, does setting the codec for the slow-link phone override the general settings? Of course it's not actually documented anywhere. When the fast link phone calls the slow link phone, it sends ulaw and G729 in that order to Asterisk. When Asterisk relays the INVITE to the slow link phone, it does not change the codec preference, and sends ulaw followed by G729. I end up with a call that's ulaw on both legs, which isn't what I want. I guess the settings in [slow-phone] aren't overriding the settings in [general]. That's bad... How can I work around this?As you already stated in your previous post the slow phone codec pref does override general when it's the caller.I think the calling parties codec preferences are respected. That is why I suggested the last time you posted this that you "force" the slow link to g729 (allow that only), as that will cause the calling party (fast) to choose g729 also...I remember reading this described somewhere, but can't find the docs at the moment.HTH,Marty___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
RE: [asterisk-users] Codec Negotiation
> -Original Message- > From: Martin Joseph [mailto:[EMAIL PROTECTED] > Sent: Monday, July 17, 2006 11:40 AM > To: Asterisk Users Mailing List - Non-Commercial Discussion > Subject: Re: [asterisk-users] Codec Negotiation > > > > On Jul 17, 2006, at 9:25 AM, Douglas Garstang wrote: > > > I have two polycom phones. One on a slow link, and one on a > fast one. > > I'm trying to set the phone on the slow link to use G729 as > it's first > > preference, and the phone on the fast link to use G711 as > it's first > > preference. > > > > sip.conf has: > > [general] > > allow=ulaw > > allow=g729 > > > > [slow-link] ; Override codecs for slow link phone. > > allow = g729 > > allow = ulaw > > > > When the slow link phone dialls the fast link phone, it > sends G729 as > > it's first preference in the INVITE to Asterisk. Asterisk > then sends > > G729 as the first preference in the INVITE to the fast link > phone. Why > > doesn't Asterisk send G711 instead? > Because you set the calling to prefer g729? What did you expect? I expected Asterisk to send G711 instead, as that's what is set in [general] in sip.conf ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Codec Negotiation
On Jul 17, 2006, at 9:25 AM, Douglas Garstang wrote: I have two polycom phones. One on a slow link, and one on a fast one. I'm trying to set the phone on the slow link to use G729 as it's first preference, and the phone on the fast link to use G711 as it's first preference. sip.conf has: [general] allow=ulaw allow=g729 [slow-link] ; Override codecs for slow link phone. allow = g729 allow = ulaw When the slow link phone dialls the fast link phone, it sends G729 as it's first preference in the INVITE to Asterisk. Asterisk then sends G729 as the first preference in the INVITE to the fast link phone. Why doesn't Asterisk send G711 instead? Because you set the calling to prefer g729? What did you expect? This raises an interesting question. If one phone uses G729, and one G711, then Asterisk is going to have to transcode, and I am going to use up a G729 license. It would seem more beneficial for it to work the way it is now. Exactly. In fact I would generally force g729 in that case (ie disallow all but g729). That is, both legs are using G729. Why is this better? It doesn't chew up a G729 license as there is no transcoding, and heck, if one of your call legs is G729, then the G711 party isn't going to hear anything better anyway. Yes this is clearly a win. ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
RE: [Asterisk-Users] Codec negotiation
Yes, But without going deeper into OpenSer (since this IS a Asterisk list): With OpenSer I'm using RTPPRoxy. I don't think i can manage rtpproxy to bind to multiple addresses. I'll look for that anyway. Thanks, Regards, Ronald. -Oorspronkelijk bericht- Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Namens Florian Overkamp Verzonden: donderdag 9 februari 2006 23:38 Aan: Asterisk Users Mailing List - Non-Commercial Discussion Onderwerp: Re: [Asterisk-Users] Codec negotiation Hi Ronald, Ronald Voermans wrote: > What exactly do you mean by seperating traffic in to differt SIP peers? > > The situation is as follows: > > I have OpenSer connected to our SIP provider/PSTN Provider (the answer > to your question: Enertel). Ah 'kay. > Asterisk registers to OpenSer, which then forwards the call to PSTN. > Asterisk registers two numbers at OpenSer; one phonenumber and one > faxnumber. I also made two entries in sip.conf. However, the host=... > Is the same for both numbers. So incoming calls are always matched to > one > (1) peer/entry in sip.conf. Hence the problem with negotiating the > right codec (g.729 for voice, g.711 for fax). Hrm, yes for inbound the problem is with the host=.. matching. Maybe Olle has a good suggestion on this :-P. However, if you control the OpenSer yourself you could easily bind another IP, or perhaps use OpenSer rules to do the trick ? Asterisk SIP stack doesn't seem suited for this type of traffic separation I guess... Florian ___ --Bandwidth and Colocation provided by Easynews.com -- Asterisk-Users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ --Bandwidth and Colocation provided by Easynews.com -- Asterisk-Users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] Codec negotiation
Hi Ronald, Ronald Voermans wrote: What exactly do you mean by seperating traffic in to differt SIP peers? The situation is as follows: I have OpenSer connected to our SIP provider/PSTN Provider (the answer to your question: Enertel). Ah 'kay. Asterisk registers to OpenSer, which then forwards the call to PSTN. Asterisk registers two numbers at OpenSer; one phonenumber and one faxnumber. I also made two entries in sip.conf. However, the host=... Is the same for both numbers. So incoming calls are always matched to one (1) peer/entry in sip.conf. Hence the problem with negotiating the right codec (g.729 for voice, g.711 for fax). Hrm, yes for inbound the problem is with the host=.. matching. Maybe Olle has a good suggestion on this :-P. However, if you control the OpenSer yourself you could easily bind another IP, or perhaps use OpenSer rules to do the trick ? Asterisk SIP stack doesn't seem suited for this type of traffic separation I guess... Florian ___ --Bandwidth and Colocation provided by Easynews.com -- Asterisk-Users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
RE: [Asterisk-Users] Codec negotiation
Florian, What exactly do you mean by seperating traffic in to differt SIP peers? The situation is as follows: I have OpenSer connected to our SIP provider/PSTN Provider (the answer to your question: Enertel). Asterisk registers to OpenSer, which then forwards the call to PSTN. Asterisk registers two numbers at OpenSer; one phonenumber and one faxnumber. I also made two entries in sip.conf. However, the host=... Is the same for both numbers. So incoming calls are always matched to one (1) peer/entry in sip.conf. Hence the problem with negotiating the right codec (g.729 for voice, g.711 for fax). Met vriendelijke groet, --- R.L.L.M. Voermans Access & Hosting E-mail: [EMAIL PROTECTED] Tel.: +31 (0)161 - 88.88.88 Fax: +31 (0)161 - 88.88.99 Global-e Raadhuisstraat 32 5126 CJ GILZE http://www.global-e.nl --- -Oorspronkelijk bericht- Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Namens Florian Overkamp Verzonden: donderdag 9 februari 2006 18:27 Aan: Asterisk Users Mailing List - Non-Commercial Discussion Onderwerp: Re: [Asterisk-Users] Codec negotiation Hi, Ronald Voermans wrote: > I've set up an Asterisk box with a SIP trunk to our PSTN provider. > I've configured two incoming phonenumbers. One phonenumber is for > voice-calls, the other one for receiving faxes. I want the incoming > voice-calls to be coded by the G.729 codec, and the fax-number by G.711. > Can I make a codec-negotation based on the called number? Nope, but maybe you could separate the traffic in to different SIP peers. > If you need more info on this, i can send it to you. If you want we could figure something out. Just curious: Which PSTN provider are you using ? Florian ___ --Bandwidth and Colocation provided by Easynews.com -- Asterisk-Users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ --Bandwidth and Colocation provided by Easynews.com -- Asterisk-Users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] Codec negotiation
Hi, Ronald Voermans wrote: I've set up an Asterisk box with a SIP trunk to our PSTN provider. I've configured two incoming phonenumbers. One phonenumber is for voice-calls, the other one for receiving faxes. I want the incoming voice-calls to be coded by the G.729 codec, and the fax-number by G.711. Can I make a codec-negotation based on the called number? Nope, but maybe you could separate the traffic in to different SIP peers. If you need more info on this, i can send it to you. If you want we could figure something out. Just curious: Which PSTN provider are you using ? Florian ___ --Bandwidth and Colocation provided by Easynews.com -- Asterisk-Users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] Codec negotiation
Further to this, does anyone know if there is a simple way to set the party priority in codec negotiation? (NOT the codec priority) In other words, I want the calling (client) preferences to be considered FIRST. Currently, my logs show Accepting AUTHENTICATED call from 203.89.xxx.xx: > requested format = ulaw, > requested prefs = (), > actual format = ilbc, > host prefs = (ilbc|g729|gsm|speex|g726|alaw|ulaw), > priority = mine As can be seen, the request was for ulaw, which IS in the list, but the request is ignored because "priority = mine". Can "priority = caller"? Or is this caused by the fact that "requested prefs" is empty? - Original Message - From: "Mark Eissler" <[EMAIL PROTECTED]> Sent: Wednesday, January 26, 2005 8:51 AM Subject: [Asterisk-Users] Codec negotiation Can't you just create a different context for inbound and outbound calls? Then specify your codec preference order in there. I don't think you can specify the bandwidth= parameter within a context other than the global one though. -mark On Jan 25, 2005, at 6:13 PM, <[EMAIL PROTECTED]> wrote: I don't want that... because - for outbound calls I want priority to be g729 first - for inbound calls I want no priority at all (e.g. the calling asterisk to decide which codec we will use) The last doesn't happen.. This by the way DID happen correctly with previous versions of asterisk (1.0.3 for example) the current CVS-HEAD version doesn't -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mohammed Salim Sent: dinsdag 25 januari 2005 22:10 To: 'Asterisk Users Mailing List - Non-Commercial Discussion' Subject: RE: [Asterisk-Users] Codec negotiation The order matters in asterisk so if you want GSM to take priority over G729, simply put that ahead of the G729... so your settings should be: Allow=all Allow=gsm Allow=g729 Allow=ulaw Allow=alaw Try that and see if it works. Regards, Mohammed Salim EZZI Telecom, Inc. -- Mark Eissler, [EMAIL PROTECTED] Mixtur Interactive, Inc. [EMAIL PROTECTED] http://www.mixtur.com ___ Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
RE: [Asterisk-Users] Codec negotiation
On Tue, 2005-01-25 at 16:10 -0500, Mohammed Salim wrote: > The order matters in asterisk so if you want GSM to take priority over G729, > simply put that ahead of the G729... so your settings should be: > > Allow=all This would allow everything so the next lines would be redundant. Disallow=all then: > Allow=gsm > Allow=g729 > Allow=ulaw > Allow=alaw -- Dave Cotton <[EMAIL PROTECTED]> ___ Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] Codec negotiation
Can't you just create a different context for inbound and outbound calls? Then specify your codec preference order in there. I don't think you can specify the bandwidth= parameter within a context other than the global one though. -mark On Jan 25, 2005, at 6:13 PM, <[EMAIL PROTECTED]> wrote: I don't want that... because - for outbound calls I want priority to be g729 first - for inbound calls I want no priority at all (e.g. the calling asterisk to decide which codec we will use) The last doesn't happen.. This by the way DID happen correctly with previous versions of asterisk (1.0.3 for example) the current CVS-HEAD version doesn't -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mohammed Salim Sent: dinsdag 25 januari 2005 22:10 To: 'Asterisk Users Mailing List - Non-Commercial Discussion' Subject: RE: [Asterisk-Users] Codec negotiation The order matters in asterisk so if you want GSM to take priority over G729, simply put that ahead of the G729... so your settings should be: Allow=all Allow=gsm Allow=g729 Allow=ulaw Allow=alaw Try that and see if it works. Regards, Mohammed Salim EZZI Telecom, Inc. -- Mark Eissler, [EMAIL PROTECTED] Mixtur Interactive, Inc. [EMAIL PROTECTED] http://www.mixtur.com ___ Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
RE: [Asterisk-Users] Codec negotiation
I don't want that... because - for outbound calls I want priority to be g729 first - for inbound calls I want no priority at all (e.g. the calling asterisk to decide which codec we will use) The last doesn't happen.. This by the way DID happen correctly with previous versions of asterisk (1.0.3 for example) the current CVS-HEAD version doesn't -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mohammed Salim Sent: dinsdag 25 januari 2005 22:10 To: 'Asterisk Users Mailing List - Non-Commercial Discussion' Subject: RE: [Asterisk-Users] Codec negotiation The order matters in asterisk so if you want GSM to take priority over G729, simply put that ahead of the G729... so your settings should be: Allow=all Allow=gsm Allow=g729 Allow=ulaw Allow=alaw Try that and see if it works. Regards, Mohammed Salim EZZI Telecom, Inc. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Eissler Sent: Tuesday, January 25, 2005 2:22 PM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [Asterisk-Users] Codec negotiation The codec is selected by asterisk depending upon the codecs that you have allowed for the particular channel context and your setting of the bandwidth= parameter. It would be nice if you could set things up so that an inbound call could force * to a higher bandwidth codec when needed (for example, an inbound fax call, let's say) but AFAIK this is not possible. -mark On Jan 25, 2005, at 10:18 AM, <[EMAIL PROTECTED]> wrote: > > Hello > > On every Incoming SIP and IAX call I see the following in asterisk > debug: > > Accepting AUTHENTICATED call from 10.10.10.10, requested format = gsm, > requested prefs = (), actual format = g729, my prefs = > (g729|gsm|g723|g726|ulaw|alaw) priority = mine > > The problem is that the codec preference on both parties is different > > The calling party has preference gsm/g729/etc > The called party (the one you see this debug from) has preference > g729/gsm/etc > > The problem is.. This call is now set up with G729... And I want it > rather to be decided by the callING party (thus want the call to be > negotiated GSM) > > What can I do about this? (I just want that if I receive a call the > calling party decides the codec, and not my side) > > My IAX.conf and SIP.conf have the following allow settings now > > Allow=all > Allow=g729 > Allow=gsm > Allow=ulaw > Allow=alaw > > > Help :-) > > > ___ > Asterisk-Users mailing list > Asterisk-Users@lists.digium.com > http://lists.digium.com/mailman/listinfo/asterisk-users > To UNSUBSCRIBE or update options visit: >http://lists.digium.com/mailman/listinfo/asterisk-users > -- Mark Eissler, [EMAIL PROTECTED] Mixtur Interactive, Inc. [EMAIL PROTECTED] http://www.mixtur.com ___ Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
RE: [Asterisk-Users] Codec negotiation
The order matters in asterisk so if you want GSM to take priority over G729, simply put that ahead of the G729... so your settings should be: Allow=all Allow=gsm Allow=g729 Allow=ulaw Allow=alaw Try that and see if it works. Regards, Mohammed Salim EZZI Telecom, Inc. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Eissler Sent: Tuesday, January 25, 2005 2:22 PM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [Asterisk-Users] Codec negotiation The codec is selected by asterisk depending upon the codecs that you have allowed for the particular channel context and your setting of the bandwidth= parameter. It would be nice if you could set things up so that an inbound call could force * to a higher bandwidth codec when needed (for example, an inbound fax call, let's say) but AFAIK this is not possible. -mark On Jan 25, 2005, at 10:18 AM, <[EMAIL PROTECTED]> wrote: > > Hello > > On every Incoming SIP and IAX call I see the following in asterisk > debug: > > Accepting AUTHENTICATED call from 10.10.10.10, requested format = gsm, > requested prefs = (), actual format = g729, my prefs = > (g729|gsm|g723|g726|ulaw|alaw) priority = mine > > The problem is that the codec preference on both parties is different > > The calling party has preference gsm/g729/etc > The called party (the one you see this debug from) has preference > g729/gsm/etc > > The problem is.. This call is now set up with G729... And I want it > rather to be decided by the callING party (thus want the call to be > negotiated GSM) > > What can I do about this? (I just want that if I receive a call the > calling party decides the codec, and not my side) > > My IAX.conf and SIP.conf have the following allow settings now > > Allow=all > Allow=g729 > Allow=gsm > Allow=ulaw > Allow=alaw > > > Help :-) > > > ___ > Asterisk-Users mailing list > Asterisk-Users@lists.digium.com > http://lists.digium.com/mailman/listinfo/asterisk-users > To UNSUBSCRIBE or update options visit: >http://lists.digium.com/mailman/listinfo/asterisk-users > -- Mark Eissler, [EMAIL PROTECTED] Mixtur Interactive, Inc. [EMAIL PROTECTED] http://www.mixtur.com ___ Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] Codec negotiation
The codec is selected by asterisk depending upon the codecs that you have allowed for the particular channel context and your setting of the bandwidth= parameter. It would be nice if you could set things up so that an inbound call could force * to a higher bandwidth codec when needed (for example, an inbound fax call, let's say) but AFAIK this is not possible. -mark On Jan 25, 2005, at 10:18 AM, <[EMAIL PROTECTED]> wrote: Hello On every Incoming SIP and IAX call I see the following in asterisk debug: Accepting AUTHENTICATED call from 10.10.10.10, requested format = gsm, requested prefs = (), actual format = g729, my prefs = (g729|gsm|g723|g726|ulaw|alaw) priority = mine The problem is that the codec preference on both parties is different The calling party has preference gsm/g729/etc The called party (the one you see this debug from) has preference g729/gsm/etc The problem is.. This call is now set up with G729... And I want it rather to be decided by the callING party (thus want the call to be negotiated GSM) What can I do about this? (I just want that if I receive a call the calling party decides the codec, and not my side) My IAX.conf and SIP.conf have the following allow settings now Allow=all Allow=g729 Allow=gsm Allow=ulaw Allow=alaw Help :-) ___ Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users -- Mark Eissler, [EMAIL PROTECTED] Mixtur Interactive, Inc. [EMAIL PROTECTED] http://www.mixtur.com ___ Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] Codec negotiation
On Sat, 2004-11-20 at 18:48 +0100, Tamas J wrote: > Hello! > > I would like to know wether it is possible to have end-to-end codec > negotiation in iax2? > What I mean is... > > In case the user dials a number available through PSTN, let's force to > use alaw (the client is in LAN) to overcome unneeded transcoding: > iaxphone->1st asterisk -> PSTN > > In case the same user dials a number available throug a chain of IAX2 > peers (e.g. 2 peers), try to negotiate the codec end-to-end to consume > less resources for transcoding on asterisk servers (of course, in that > case we don't want to use g711, but ilbc, speex or gsm). > iaxphone->1st asterisk->2nd asterisk->PSTN > Or maybe: > iaxphone->1st asterisk->2nd asterisk->iaxpohone > > Is there a way to do that? If yes, how? If 1st asterisk -> 2nd asterisk is a link that negotiates the ILBC, gsm, or speex, when the call transfers, it should negotiate the codec. Of course part of the interesting effect here is that unless there is NAT or something similar in the way, IAX is going to try and get out of each section if it can. So you may end up with the end result being iaxphone -> iaxphone and they might be negotiating with each other. -- Steven Critchfield <[EMAIL PROTECTED]> ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] codec negotiation
Why do you need 729? I just called your IAXTel number using GSM and connected fine. Michael On Wed, 18 Feb 2004 08:29:48 +0100, dkwok wrote: >I have outgoing connection to iaxtel and another iax server A. > >iax server A only accept g729 codec while iaxtel is something I am not >quite sure of. At the moment iaxtel only accepts gsm. I remember >previously it does accept g729. > >my problem due to the switching between codec when making outgoing calls >to these servers. > >my iax.conf has these lines: > >[general] > >disallow=all >allow=gsm >allow=g729 > >I believe the general context define the codec to be used when making >outgoing calls. The peer context below general context is to governed >codec to be used for incoming calls. Is this correct? > >now if I specificly disallow g729 in the general context I can make >calls to iaxtel. however i cannot make calls to server A as it only >accepts g729. After I allow g729, I can make call to server A but the >call made to iaxtel cannot go through. > >The console indicates that the call is accepted by iaxtel using codec >729A, then it says the circuit is too busy. > >Is there a clever way of governing the codec use for each outgoing >connection in order to avoid the issue in codec negotiation? > >-- >David Kwok > >Iaxtel/FWD # 17001813482 ext 1002 > >___ >Asterisk-Users mailing list >[EMAIL PROTECTED] >http://lists.digium.com/mailman/listinfo/asterisk-users >To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users > -- Michael Graves [EMAIL PROTECTED] Sr. Product Specialist www.pixelpower.com Pixel Power Inc. [EMAIL PROTECTED] "I believe there comes a time when everything just falls in line." - Pat Benatar, from All Fired Up. ** Tag(s) inserted by Bandit Tagger98 - http://www.gbar.dtu.dk/~c918704 ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] Codec Negotiation Does not seem to work as e xpected ?? Help Please !!
Title: Re: [Asterisk-Users] Codec Negotiation Does not seem to work as expected ?? Help Please !! Steve, My Problem is not a problem, with the codec negotiation between end points. But when asterisk does it with canreinvite=no, * do not do it right. I replied with a lengthy discussion about my findings here, This behavior can be reproduced. But '*' do not seem to do the negotiation correctly. http://lists.digium.com/pipermail/asterisk-users/2004-January/032197.html >I think your problem comes from a misunderstanding of how the calls are >placed. With your canreinvite=no in the ATA section, you end up with the >ATA negotiating with asterisk for a call leg. Then you have asterisk >negotiating for the other call leg. Since the RTP stream is going >through asterisk, it behaves with how asterisk is capable. If there had >been a reinvite, then the ATA and the remote end would then be able to >negotiate a different codec. On Mon, 2004-01-05 at 01:29, SamW wrote: > Hello, > > I have been trying to get my coders to work without a conversion. I have > read all the available asterisk documentation and support groups without > any luck. Here is my issue. (Please feel free to ask questions if you do > not understand what I am talking about.) > > I am using Cisco ATA-186 set to g729 codec. (But it will switch to g711 if > sip-server request g711) > > I have 2 SIP-services to which I have to deliver the call in 2 coder > formats. Lets call 2 sip-providers, SIP-A and SIP-B. SIP-A accept g729 and > g711, SIP-B only accept g711. > > I do not have any g729 licence, but I believe the * should negotiate to > have the correct passthrough coders as ATA is capable of both coders. (I > think even if you have the licenses, * should try avoid codec-conversions > when ever it can) > > > Here is my settings in sip.conf. I will only list the required codec > related lines, for easy understanding, > > [general] > disallow=all > allow=g729 > allow=ulaw > allow=alaw > > register => [EMAIL PROTECTED] > register => [EMAIL PROTECTED] > > [sip-a] > > disallow=all > allow=ulaw > > > [sip-b] > ... > disallow=all > allow=g729 > > [ATA] > . > canreinvite=no > > Here is what happens when I look at the SIP packets from linux. (ethereal) > > > Case 1 : ATA Dialing out through sip-a > > > > ATA indicate that it can have following, codecs in SDP packet, in following > order > ATA --> asterisk INVITE message > g729 > ulaw > alaw > asterisk --> sip-a INVITE message (Note that already the order of coders > are changed. Is this how it should be I do not know. And how * decide what > order of coders to send to sip-a) > alaw > ulaw > g729 > sip-a --> asterisk Session Progress Message > ulaw > asterisk --> ATA Session in Progress Message > ulaw > alaw > g729 > asterisk --> ATA send a BYE message and hang up. > > at this point asterisk indicate it cannot native bridge message. I do not > know why asterisk behaves like this, and I do think if asterisk send the > message back to ATA with g729 in its message it should have worked fith > nating bridging. > > WARNING[1248642112]: File channel.c, Line 1853 > (ast_channel_make_compatible): No path to translate from > SIP/sip-a-1e15(256) to SIP/4097-96d8(4) > > > > Case 2 : ATA calling sip-b > === > > ATA indicate that it can have following, codecs in SDP packet, in following > order > ATA --> asterisk INVITE message > g729 > ulaw > alaw > asterisk --> sip-b INVITE message (Note that unlike case 1, the decision > by * in this case is OK. * only send one available coder info to the sip-b, > which is correct as per my config) > ulaw > > sip-b --> asterisk Session Progress Message > ulaw > asterisk --> ATA Session in Progress Message (Here again * sending multiple > choices to the ATA, I expect this to be only one request as * already know > from sip-b, that sip-b can only do ulaw. * know from 2 ways here one from > Session Progress message above and other from sip-b context that sip-b can > only do ulaw.) I am confused > ulaw > alaw > g729 > > Asterisk send a BYE message to sip-b and send a 403 Forbidden Message to > ATA and hang-up the call here. > > asterisk --> sip-a send a BYE message and hang up. > asterisk -> ATA 403 Forbidden > >
RE: [Asterisk-Users] Codec Negotiation Does not seem to work as expected ?? Help Please !!
Thanks for all who is helping. I tried, canreinvite=yes on all contexts but that do not seem to work as well. But the issue is not related to negotiating between end points, but for me, asterisk do not have a proper configuration scheme which works, to the requirement of the user. The Code-Negotiation in * for me is buggy or featureless in Asterisk. The way to negotiate coders is to give priority to bridge-native without a coder translation/conversion when ever possible, if we do not hard tell * to do so. There could be users need to give priority to coder translation (If you pay royalty fees to g729 may be!!). So my expectation is we should have a way to tell * what order we like to have coders negotiated for different contexts (or end points). I did some more digging into the problem and here is what I see. I changed the configuration as follows, (added disallow/allow to ATA context, and I keep canreinvite=no as to show that * misbehaves in codec negotiation by it self) [general] disallow=all allow=g729 allow=ulaw allow=alaw register => [EMAIL PROTECTED] register => [EMAIL PROTECTED] [sip-a] canreinvite=no disallow=all allow=ulaw [sip-b] ... canreinvite=no disallow=all allow=g729 [ATA] . canreinvite=yes disallow=all allow=g729 When ever I only allow g729 in ATA-context, during a call setup asterisk send the SIP:Session Progress Message with only g729 listed in SDP headers. Then I can make calls through to sip-a. Then if I change [ATA] context to following(change allow=alaw), I can make calls through sip-b. But not sip-a. [This is expected and is OK] Here the * only send ulaw in its Session In progress request to ATA. * do not list g729 in its request to '*'. Then ATA switches to the correct codec and start sending rtp packets correctly. [ATA] . canreinvite=no disallow=all allow=ulaw My point now is if * can send only the negotiated codec from sip-a or sip-b then the ATA will act correctly. But when I configure for both coders, as below, [ATA] . canreinvite=no disallow=all allow=g729 allow=ulaw asterisk misbehaves, by sending both ulaw and g729 in the request to the ATA and '*' gets confused by it self and drop the call. Also I have noticed that allow order given in the [ATA] context have no effect. Example, if I change context to have the following order, I expect * to atleast send the request in the order it is shown in the context. But it always, send the request to ATA in the order, g729 and then ulaw. I do not understand where '*' is deciding the order of the coders to send. Ex. [ATA] . canreinvite=no disallow=all allow=ulaw allow=g729 I think sip-a, sip-b and ATA is acting correctly, but '*' do not have a way to configure the codec negotiation (There is but misbehave??). If we users can agree, on this and if it is a requirement for us, should we be able to file a bug-report? or send a request to the developers?? Lets talk? I am willing to participate in any test that needs to be carried out. Thanks, SamW ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users
RE: [Asterisk-Users] Codec Negotiation Does not seem to work as expected ?? Help Please !!
Try using canreinvite=yes in all three contexts. Would that screw-up ATA, I do not know, cause I have no Cisco's ? SW Message: 5 Date: Mon, 05 Jan 2004 02:29:49 -0500 From: SamW <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: [Asterisk-Users] Codec Negotiation Does not seem to work as expected ?? Help Please !! Reply-To: [EMAIL PROTECTED] Hello, I have been trying to get my coders to work without a conversion. I have read all the available asterisk documentation and support groups without any luck. Here is my issue. (Please feel free to ask questions if you do not understand what I am talking about.) I am using Cisco ATA-186 set to g729 codec. (But it will switch to g711 if sip-server request g711) I have 2 SIP-services to which I have to deliver the call in 2 coder formats. Lets call 2 sip-providers, SIP-A and SIP-B. SIP-A accept g729 and g711, SIP-B only accept g711. I do not have any g729 licence, but I believe the * should negotiate to have the correct passthrough coders as ATA is capable of both coders. (I think even if you have the licenses, * should try avoid codec-conversions when ever it can) Here is my settings in sip.conf. I will only list the required codec related lines, for easy understanding, [general] disallow=all allow=g729 allow=ulaw allow=alaw register => [EMAIL PROTECTED] register => [EMAIL PROTECTED] [sip-a] disallow=all allow=ulaw [sip-b] ... disallow=all allow=g729 [ATA] . canreinvite=no ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] Codec Negotiation Does not seem to work as expected ?? Help Please !!
I think your problem comes from a misunderstanding of how the calls are placed. With your canreinvite=no in the ATA section, you end up with the ATA negotiating with asterisk for a call leg. Then you have asterisk negotiating for the other call leg. Since the RTP stream is going through asterisk, it behaves with how asterisk is capable. If there had been a reinvite, then the ATA and the remote end would then be able to negotiate a different codec. On Mon, 2004-01-05 at 01:29, SamW wrote: > Hello, > > I have been trying to get my coders to work without a conversion. I have > read all the available asterisk documentation and support groups without > any luck. Here is my issue. (Please feel free to ask questions if you do > not understand what I am talking about.) > > I am using Cisco ATA-186 set to g729 codec. (But it will switch to g711 if > sip-server request g711) > > I have 2 SIP-services to which I have to deliver the call in 2 coder > formats. Lets call 2 sip-providers, SIP-A and SIP-B. SIP-A accept g729 and > g711, SIP-B only accept g711. > > I do not have any g729 licence, but I believe the * should negotiate to > have the correct passthrough coders as ATA is capable of both coders. (I > think even if you have the licenses, * should try avoid codec-conversions > when ever it can) > > > Here is my settings in sip.conf. I will only list the required codec > related lines, for easy understanding, > > [general] > disallow=all > allow=g729 > allow=ulaw > allow=alaw > > register => [EMAIL PROTECTED] > register => [EMAIL PROTECTED] > > [sip-a] > > disallow=all > allow=ulaw > > > [sip-b] > ... > disallow=all > allow=g729 > > [ATA] > . > canreinvite=no > > Here is what happens when I look at the SIP packets from linux. (ethereal) > > > Case 1 : ATA Dialing out through sip-a > > > > ATA indicate that it can have following, codecs in SDP packet, in following > order > ATA --> asterisk INVITE message > g729 > ulaw > alaw > asterisk --> sip-a INVITE message (Note that already the order of coders > are changed. Is this how it should be I do not know. And how * decide what > order of coders to send to sip-a) > alaw > ulaw > g729 > sip-a --> asterisk Session Progress Message > ulaw > asterisk --> ATA Session in Progress Message > ulaw > alaw > g729 > asterisk --> ATA send a BYE message and hang up. > > at this point asterisk indicate it cannot native bridge message. I do not > know why asterisk behaves like this, and I do think if asterisk send the > message back to ATA with g729 in its message it should have worked fith > nating bridging. > > WARNING[1248642112]: File channel.c, Line 1853 > (ast_channel_make_compatible): No path to translate from > SIP/sip-a-1e15(256) to SIP/4097-96d8(4) > > > > Case 2 : ATA calling sip-b > === > > ATA indicate that it can have following, codecs in SDP packet, in following > order > ATA --> asterisk INVITE message > g729 > ulaw > alaw > asterisk --> sip-b INVITE message (Note that unlike case 1, the decision > by * in this case is OK. * only send one available coder info to the sip-b, > which is correct as per my config) > ulaw > > sip-b --> asterisk Session Progress Message > ulaw > asterisk --> ATA Session in Progress Message (Here again * sending multiple > choices to the ATA, I expect this to be only one request as * already know > from sip-b, that sip-b can only do ulaw. * know from 2 ways here one from > Session Progress message above and other from sip-b context that sip-b can > only do ulaw.) I am confused > ulaw > alaw > g729 > > Asterisk send a BYE message to sip-b and send a 403 Forbidden Message to > ATA and hang-up the call here. > > asterisk --> sip-a send a BYE message and hang up. > asterisk -> ATA 403 Forbidden > > NOTICE[1248642112]: File channel.c, Line 1478 (ast_set_read_format): Unable > to find a path from G729A to ULAW > NOTICE[1248642112]: File channel.c, Line 1448 (ast_set_write_format): > Unable to find a path from ULAW to G729A > > > = > > Summery ; > Why this is happening this way, (Do I not understand how to configure or is > this a bug?) > As the coder negotiation is not well documented anywhere can you please > help me figure out how to configure the coder negotion. > > IMHO, I belive that for each context, we need to have a way to force which > coder to choose. True that * can code convert with license, but when you > code/decode it will always be lossy and will loose quality of sound. If > one side is fixed for a particular codec, and the other side is flexible > for a negotiation, I should see that flexible side should get adjusted to > the correct codec. It do not seem to happen. > > > Thank you in advance and appreciate your help. > > > - Sa
Re: [Asterisk-Users] codec negotiation
Hello Eduardo, Wednesday, December 17, 2003, 1:08:00 AM, you wrote: EG> Hi list, EG> I'm with a little problem on codec negotiation between a cisco827 and EG> asterisk. EG> My sip.conf is like that: EG> [general] EG> port = 5060 EG> bindaddr = 0.0.0.0 EG> context = default EG> amaflags = default EG> allow=g729 EG> allow=gsm EG> allow=alaw EG> allow=ulaw EG> ;disallow=all EG> and cisco like that: EG> dial-peer voice 6 voip EG> destination-pattern 0T EG> session protocol sipv2 EG> session target ipv4: EG> dtmf-relay rtp-nte EG> codec g711alaw EG> no vad EG> ! EG> When I try to make a call, cisco shows codec g711alaw, but asterisk EG> shows codec g729A (i have the licenses) and there is no audio. When I EG> try disallow=g729, the same occurs, but this time asterisk shows codec EG> gsm. EG> The only way to make a call is allowing only alaw. But this is not EG> convenience, since i need to use g279 with another endpoint (working EG> ok). EG> Why this negotiation problem happens? Try to add to cisco peer (not shown in your mail) [cisco] disallow=all allow=alaw -- Best regards, Nguyenmailto:[EMAIL PROTECTED] ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] codec negotiation
- Original Message - From: "Eduardo Goncalves" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, December 16, 2003 1:08 PM Subject: [Asterisk-Users] codec negotiation > Hi list, > > I'm with a little problem on codec negotiation between a cisco827 and > asterisk. > > My sip.conf is like that: > > [general] > port = 5060 > bindaddr = 0.0.0.0 > context = default > amaflags = default > allow=g729 > allow=gsm > allow=alaw > allow=ulaw > ;disallow=all > > and cisco like that: > > dial-peer voice 6 voip > destination-pattern 0T > session protocol sipv2 > session target ipv4: > dtmf-relay rtp-nte > codec g711alaw > no vad > ! > > When I try to make a call, cisco shows codec g711alaw, but asterisk > shows codec g729A (i have the licenses) and there is no audio. When I > try disallow=g729, the same occurs, but this time asterisk shows codec > gsm. > > The only way to make a call is allowing only alaw. But this is not > convenience, since i need to use g279 with another endpoint (working > ok). > You could try setting the codec before dialing that particular provider. Except I don't see the command now that I'm trying to find it... > Why this negotiation problem happens? Can't help on that one... > > Thanks > Eduardo - Andrew Thompson http://aktzero.com/ Your eyes are weary from staring at the CRT. You feel sleepy. Notice how restful it is to watch the cursor blink. Close your eyes. The opinions stated above are yours. You cannot imagine why you ever felt otherwise. ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users