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
[asterisk-users] codec negotiation or transcoding issue
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
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
[asterisk-users] Codec Negotiation problem
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 --- (12 headers 9 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) Non-codec capabilities (dtmf): us - 0x1 (telephone-event|), peer - 0x1 (telephone-event|), combined - 0x1 (telephone-event|) Peer audio RTP is at port 10.10.10.129:53188 Peer doesn't provide video Here is a sip show peer output and log when making calls. localhost*CLI> sip show peer 1003 * Name : 1003 Description : Secret : MD5Secret: Remote Secret: Context : video-users Subscr.Cont. : Language : AMA flags: Unknown Transfer mode: open CallingPres : Presentation Allowed, Not Screened Callgroup: Pickupgroup : MOH Suggest : Mailbox : 1003@device VM Extension : asterisk LastMsgsSent : 0/0 Call limit : 2147483647 Max forwards : 0 Dynamic : Yes Callerid : "device" <1003> MaxCallBR: 384 kbps Expire : 3605 Insecure : no Force rport : Yes ACL : Yes DirectMedACL : No T.38 support : No T.38 EC mode : Unknown T.38 MaxDtgrm: -1 DirectMedia : Yes PromiscRedir : No User=Phone : No Video Support: Yes Text Support : No Ign SDP ver : No Trust RPID : No Send RPID: No Subscriptions: Yes Overlap dial : No DTMFmode : rfc2833 Timer T1 : 500 Timer B : 32000 ToHost : Addr->IP : 10.10.10.129:48464 Defaddr->IP : (null) Prim.Transp. : UDP Allowed.Trsp : UDP Def. Username: 1003 SIP Options : (none) Codecs : (alaw|h263p) Codec Order : (alaw:20,h263p:0) Auto-Framing : No Status : OK (8 ms) Useragent: X-Lite release 4.5.2 stamp 70142 Reg. Contact : sip:1003@10.10.10.129:48464;rinstance=cf0c3558f05c89dc Qualify Freq : 6 ms Sess-Timers : Accept Sess-Refresh : uas Sess-Expires : 1800 secs Min-Sess : 90 secs RTP Engine : asterisk Parkinglot : Use Reason : No Encryption : No localhost*CLI> sip show peer 1004 * Name : 1004 Description : Secret : MD5Secret: Remote Secret: Context : video-users Subscr.Cont. : Language : AMA flags: Unknown Transfer mode: open CallingPres : Presentation Allowed, Not Screened Callgroup: Pickupgroup : MOH Suggest : Mailbox : 1004@device VM Extension : asterisk LastMsgsSent : 0/0 Call limit : 2147483647 Max forwards : 0 Dynamic : Yes Callerid : "device" <1004> MaxCallBR: 384 kbps Expire : 893 Insecure : no Force rport : Yes ACL : Yes DirectMedACL : No T.38 support : No T.38 EC mode : Unknown T.38 MaxDtgrm: -1 DirectMedia : Yes PromiscRedir : No User=Phone : No Video Support: Yes Text Support : No Ign SDP ver : No Trust RPID : No Send RPID: No Subscriptions: Yes Overlap dial : No DTMFmode : rfc2833 Timer T1 : 500 Timer B : 32000 ToHost : Addr->IP : 10.10.10.107:21769 Defaddr->IP : (null) Prim.Transp. : UDP Allowed.Trsp : UDP Def. Username: 1004 SIP Options : (none) Codecs : (alaw|h263p) Codec Order : (alaw:20,h263p:0) Auto-Framing : No Status : OK (2 ms) Useragent: Grandstream GXV3175v2 1.0.1.19 Reg. Contact : sip:1004@10.10.10.107:21769 Qualify Freq : 6 ms Sess-Timers : Accept Sess-Refresh : uas Sess-Expires : 1800 secs Min-Sess : 90 secs RTP Engine : asterisk Parkinglot : Use Reason : No Encryption : No localhost*CLI> <-> --- (8 headers 0 lines) --- <--- SIP read from UDP:10.10.10.129:48464 ---> INVITE sip:1004@10.10.10.105 SIP/2.0 Via: SIP/2.0/UDP 10.10.10.129:48464;branch=z9hG4bK-d8754z-25f65c322686d22e-1---d8754z-;rport Max-Forwards: 70 Contact: To: From: "SAM";tag=0c90cc0c Call-ID: MmNjOTczNDU5YjZmYjAyNWMxY2Q1MDZjODdhYzQwZjA CSeq: 2 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO Content-Type: application/sdp Supported: replaces User-Agent: X-Lite release 4.5.2 stamp 70142 Authorization: Digest username="1003",realm="10.10.10.105",nonce="05e8af6e",uri="sip:1004@10.10.10.105",response="20e63a04aa86d6ec1d1e045c05159b39",algorithm=MD5 Content-Length: 418 v=0 o=- 13015615910543193 1 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 0 101 a=rtpmap:101 tel
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
[asterisk-users] Codec negotiation issue (no audio format found to offer)
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
[asterisk-users] Codec negotiation
Hi List, I am using asterisk 1.8.1. and I want to avoid transcoding when 2 SIP 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
[asterisk-users] Codec negotiation : expecting G726, getting G711a (alaw)
Hello list, Grandstream GXP2010 phone calling to Snom 320, Asterisk in the middle. Grandstream allows for 8 different codec specifications. I have defined them as 4 x G726 & 4 x alaw. Snom allow for 7 different codec specifications. I have defined them as 3 x G726 & 4 x G729. The SIP peers are both defined as : disallow=all allow=g726 allow=alaw allow=g729 allow=gsm This is the SIP trace : INVITE sip:2...@192.168.1.150 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.102:5062;branch=z9hG4bK1dc39a962389c1a9 From: "User" ;tag=2383fb163ee6befa To: Contact: Supported: replaces, timer, path Proxy-Authorization: Digest username="user", realm="domain.be", algorithm=MD5, uri="sip:2...@192.168.1.150", nonce="1ae22736", response="c90d0d9bf1f3c2bbc020651a5b67b608" Call-ID: 8910dbc6f2d5f...@192.168.1.102 CSeq: 35396 INVITE *User-Agent: Grandstream GXP2010 1.2.1.4* Max-Forwards: 70 Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE,UPDATE,PRACK,MESSAGE Content-Type: application/sdp Content-Length: 250 v=0 o=user 8000 8001 IN IP4 192.168.1.102 s=SIP Call c=IN IP4 192.168.1.102 t=0 0 m=audio 10126 RTP/AVP 2 8 101 a=sendrecv *a=rtpmap:2 G726-32/8000 a=rtpmap:8 PCMA/8000* a=ptime:20 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-11 <-> [Aug 2 13:56:57] --- (14 headers 12 lines) --- [Aug 2 13:56:57] Sending to 192.168.1.102 : 5062 (NAT) [Aug 2 13:56:57] Using INVITE request as basis request - 8910dbc6f2d5f...@192.168.1.102 [Aug 2 13:56:57] Found user 'user' [Aug 2 13:56:57] Found RTP audio format 2 [Aug 2 13:56:57] Found RTP audio format 8 [Aug 2 13:56:57] Found RTP audio format 101 [Aug 2 13:56:57] Found audio description format G726-32 for ID 2 [Aug 2 13:56:57] Found audio description format PCMA for ID 8 [Aug 2 13:56:57] Found audio description format telephone-event for ID 101 *[Aug 2 13:56:57] Capabilities: us - 0x90a (gsm|alaw|g726|g729), peer - audio=0x808 (alaw|g726)/video=0x0 (nothing), combined - 0x808 (alaw|g726)* [Aug 2 13:56:57] Non-codec capabilities (dtmf): us - 0x1 (telephone-event), peer - 0x1 (telephone-event), combined - 0x1 (telephone-event) [Aug 2 13:56:57] Peer audio RTP is at port 192.168.1.102:10126 [Aug 2 13:56:57] Looking for 20 in from-STERKEN (domain 192.168.1.150) [Aug 2 13:56:57] list_route: hop: [Aug 2 13:56:57] <--- Transmitting (NAT) to 192.168.1.102:5062 ---> SIP/2.0 100 Trying Via: SIP/2.0/UDP 192.168.1.102:5062;branch=z9hG4bK1dc39a962389c1a9;received=192.168.1.102 From: "User" ;tag=2383fb163ee6befa To: Call-ID: 8910dbc6f2d5f...@192.168.1.102 CSeq: 35396 INVITE User-Agent: my-asterisk-server Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO Supported: replaces Contact: Content-Length: 0 <-> [Aug 2 13:56:57] --- (11 headers 0 lines) --- [Aug 2 13:56:57] SIP Response message for INCOMING dialog NOTIFY arrived [Aug 2 13:56:57] -- SIP/sterkendries2-0054 is ringing [Aug 2 13:56:57] <--- Transmitting (NAT) to 192.168.1.102:5062 ---> SIP/2.0 180 Ringing Via: SIP/2.0/UDP 192.168.1.102:5062;branch=z9hG4bK1dc39a962389c1a9;received=192.168.1.102 From: "User" ;tag=2383fb163ee6befa To: ;tag=as655a8251 Call-ID: 8910dbc6f2d5f...@192.168.1.102 CSeq: 35396 INVITE *User-Agent: my-asterisk-server* Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO Supported: replaces Contact: Content-Length: 0 --- [Aug 2 13:57:00] Extension Changed 20[105002-blf] new state InUse for Notify User user [Aug 2 13:57:00] -- SIP/sterkendries2-0054 answered SIP/user-0053 [Aug 2 13:57:00] Audio is at 192.168.1.150 port 11500 [Aug 2 13:57:00] Adding codec 0x8 (alaw) to SDP [Aug 2 13:57:00] Adding codec 0x800 (g726) to SDP [Aug 2 13:57:00] Adding non-codec 0x1 (telephone-event) to SDP [Aug 2 13:57:00] <--- Reliably Transmitting (NAT) to 192.168.1.102:5062 ---> SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.1.102:5062;branch=z9hG4bK1dc39a962389c1a9;received=192.168.1.102 From: "User" ;tag=2383fb163ee6befa To: ;tag=as655a8251 Call-ID: 8910dbc6f2d5f...@192.168.1.102 CSeq: 35396 INVITE *User-Agent: my-asterisk-server* Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO Supported: replaces Contact: Content-Type: application/sdp Content-Length: 267 v=0 o=root 1947 1947 IN IP4 192.168.1.150 s=session c=IN IP4 192.168.1.150 t=0 0 m=audio 11500 RTP/AVP 8 2 101 *a=rtpmap:8 PCMA/8000 a=rtpmap:2 G726-32/8000* a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=silenceSupp:off - - - - a=ptime:20 a=sendrecv <-> [Aug 2 13:57:00] --- (11 headers 0 lines) --- [Aug 2 13:57:00] SIP Response message for INCOMING dialog NOTIFY arrived [Aug 2 13:57:00] <--- SIP read from 192.168.1.102:5062 ---> ACK sip:2...@192.168.1.150 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.102:5062;branch=z9hG4bK76a685e83ba8aef8 From: "User" ;tag=2383fb163ee6befa To: ;tag=as655a8251 Contact: Supported: path Proxy-Authorization: Digest username="user", realm="domain.be", algorithm=MD5, uri="sip:2.
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
[asterisk-users] Codec negotiation
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 -- _ -- 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
[asterisk-users] Codec negotiation for Thomson ST2030 and g729
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
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
[asterisk-users] Codec Negotiation
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
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
[asterisk-users] Codec Negotiation
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? 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
> -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
[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? ___ --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
[Asterisk-Users] Codec negotiation
If I have an incoming call which uses G.711u, which then gets transferred to a phone which has G.729 selected as its first preference (with 711 as a third). Is it normal behaviour for asterisk to transcode the call to G.729 rather than keep it as 711? Does anyone know if when T.38 support is complete, it can be treated as if it were a codec, ie. can put allow=g729 allow=t38 in sip/iax.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
[Asterisk-Users] codec negotiation
We have four settings for the codec. How will it be negotiated? How should it be negotiated in relation to the available bandwidth? Is there an influence by using canreinvite=yes ? Phone A has a setting for the priority of codec Sip.conf has (maybe even different) settings for the priority of codec of this phone A Sip.conf has codec settings for the destination phone B Phone B has (maybe even different) settings for the priority of codec Which codec will be taken? a. if the call goes via * ? b. if the call will be completed with canreinvite=yes ? Which codec should be enforce depending on the bandwidth? Thanks for thinking with me ;-) bye Ronald Wiplinger ___ --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
[Asterisk-Users] codec negotiation with SPA-3K
I'm having trouble with Asterisk-1.2.4 negotiating codecs with a Sipura 3000 which is running the latest v3 firmware. The SPA-3K seems to use the "preferred" codec only and doesn't negotiate? The SPA is set to no in "use only preferred codec". Does anyone know if Sipura will support gsm at some point? I this a bug with the SPA or codec negotiation stuff? Thanks Steve -- NetTek Ltd UK mob +44-(0)7775 755503 UK +44-(0)20 79932612 / US +1-(310)8577715 / Fax +44-(0)20 7483 2455 Skype/GoogleTalk/AIM/Gizmo stevekennedyuk / MSN [EMAIL PROTECTED] Euro Tech News Blog http://eurotechnews.blogspot.com ___ --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
[Asterisk-Users] Codec negotiation
Hi All, 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? If you need more info on this, i can send it to you. Thank you all for your answer(s)! Regards, Ronald Voermans ___ --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
[Asterisk-Users] Codec negotiation (not the same old stuff)
Title: Codec negotiation (not the same old stuff) I have a H.323 device, let's call it stupid, that supports all variants of G.729. That should be good, but no. When it negotiates a call between Asterisk and a phone that supports all varients of G.729, it gets it wrong. Asterisk sends G.729A and the phone sends G.729, at which point the device transcodes the call, but changes the packetization. I'm looking for a way to get Asterisk to offer plain old G.729, so the device (stupid) can just bridge the RTP. My research shows this should not be required, since G.729 and G.729A are compatible and don't need transcoding. I'm trying to get an answer from the device manufacturer, but I do not have high hopes. If it matters, I am using chan_ooh323 with Asterisk 1.2.0. Thanks, Dan ___ --Bandwidth and Colocation sponsored by Easynews.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] codec negotiation with CISCO 7960 and Firefly softphone
Hi all, When I am making call with with my Cisco 7960 SIP phone, I found only codec g711 works. The network call is like this: CISCO AS5300 ---sip> Asterisk sip---> CISCO7960 Peer User/ANR Call ID Seq (Tx/Rx) Formatcisco7960 30511694 152828207b0 00102/0 ulaw ciscoAS5300 34169980 31A6EE0B-AF 00101/00101 gsm Codec in CISCO AS5300 g711alaw G.711 A Law 64000 bps g711ulaw G.711 u Law 64000 bps g723ar53 G.723.1 ANNEX-A 5300 bps g723ar63 G.723.1 ANNEX-A 6300 bps g723r53 G.723.1 5300 bps g723r63 G.723.1 6300 bps g729br8 G.729 ANNEX-B 8000 bps g729r8 G.729 8000 bps gsmefr GSMEFR 12200 bps gsmfr GSMFR 13200 bps I already did the following config in sip.conf allow=g723allow=g729allow=gsmallow=ulawallow=alaw However, it seems that only codec gsm work fines. However, it still occupy more bandwidth. Just would like to know if asterisk can do codec g723 or g729? Anyone has encountered this problem or am I missing any config in asterisk? Thanks. Raymond ___ 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
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
[Asterisk-Users] Codec negotiation problems
My PBX seems to have just started showing wierd codec negotiation problems. I'm not all of a sudden getting this on certain phone numbers on my system: Feb 8 22:19:19 NOTICE[1125329728]: channel.c:1683 ast_set_read_format: Unable to find a path from ULAW to G729A Feb 8 22:19:19 NOTICE[1125329728]: channel.c:1650 ast_set_write_format: Unable to find a path from G729A to ULAW -- SIP/2101-aaf2 answered SIP/19544342000-375a -- Attempting native bridge of SIP/19544342000-375a and SIP/2101-aaf2 -- Attempting native bridge of SIP/19544342000-375a and SIP/2101-aaf2 Feb 8 22:19:19 NOTICE[1225991488]: channel.c:1683 ast_set_read_format: Unable to find a path from G729A to ULAW Feb 8 22:19:19 NOTICE[1225991488]: channel.c:1650 ast_set_write_format: Unable to find a path from ULAW to G729A Feb 8 22:19:19 WARNING[1225991488]: chan_sip.c:1797 sip_write: Asked to transmit frame type 256, while native formats is 4 (read/write = 4/4) Regards, Daniel ___ 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
[Asterisk-Users] Codec negotiation
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
[Asterisk-Users] Codec Negotiation Problem
Hi there, i had installed on all my servers the codec_g729b which is the old voiceage, so a month ago i updated the codec to codec_g729a. After that i started to get this message on my asterisk console: Dec 16 09:19:26 NOTICE[1288699200]: rtp.c:293 process_rfc3389: Don't know how to handle RFC3389 for receive codec 256Dec 16 09:19:26 NOTICE[1288699200]: rtp.c:264 process_rfc3389: RFC3389 support incomplete. Turn off on client if possible Im only using g729 on all my servers, i have some IAX conections with only g729 too. I think its a negotiation problem but with the old version i didnt have this error. If anyone knows how to fix this would be very helpful. Thanks for your help Carlos Andres Medina Do you Yahoo!? Send holiday email and support a worthy cause. Do good.___ 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[2]: [Asterisk-Users] Codec negotiation
Saturday, November 20, 2004, 7:03:53 PM, Steven wrote: SC> 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 If 1st asterisk ->> negotiates the ILBC, gsm, SC> or speex, when the call transfers, it should negotiate the codec. Of SC> course part of the interesting effect here is that unless there is NAT SC> or something similar in the way, IAX is going to try and get out of each SC> section if it can. So you may end up with the end result being iaxphone ->> iaxphone and they might be negotiating with each other. Thanks for the fast response! Yes, when the call is transfered, it's logical that parties can negotiate codecs. However is there a way to negotiate end-to-end without call transfer? Is it possible to make this? iaxComm -> asterisk -> E1 PSTN +--> IAX operator When the softphone dials to local PSTN number, let's choose alaw or ulaw codec (to avoid speex/ilbc/gsm -> alaw/ulaw transcoding) and if the call goes out through IAX, let's choose low bandwidth codec (there should be a preferred one, e.g. softphone and iax trunk use speex). What I would like is to avoid unneeded transcoding and save on CPU resources. What I tryed is to put for sofphone: disallow=all allow=speex allow=alaw allow=ulaw When the call went to PSTN it used speex. How can I tell to asterisk to use alaw (or ulaw while iaxComm looks not supporting alaw) in this case? I guess when I would exchange the order and put speex to the and, it will chose ulaw (oops, I tryed and it selected Speex again), but in this case who will do g711<->speex? What is my goal with this? I would like to encode to speex at the softphone's side, thus I can save CPU power on asterisk box. (and if I put 10-20... more softphones, I won't run out with CPU, because when it comes to local call, there won't be transcoding either and when it will go out to iax peer, it will just pass-through). Any idea, hint? Thanks in advance, Tamas ps: sorry for the possible a newbie or/and dumb question... ___ 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
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
[Asterisk-Users] Codec negotiation
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? Thanks in advance, TamasJ ___ 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
[Asterisk-Users] Codec negotiation
It seems that older version of asterisk does the codec negotiation fine. I have one machine running CVS-12/19/03 and this can negotiate codec g729 and gsm fine. The newer version cvs-1/27/04 does not negotiate codec correctly. The ougoing connection can only go either g729 or gsm. -- David Kwok FWD#/IAXTEL# : 17001813482 ext 1002 smime.p7s Description: S/MIME Cryptographic Signature
[Asterisk-Users] codec negotiation prob solved?
FYI - bug 1043 has been fixed on Feb 18: "From my log, below, you will see that ast_rtp_bridge is not comparing the codecs properly. Asterisk is currently comparing the integers, and not the bits of the codec. In the below example codec0 = 260. That means Codec0 allows both 256 (g729) and 4 (uLaw). So that would mean that Codec0 and Codec1 do have a "Codec Match". Asterisk needs to do a bit compare, and not a int compare in this case." -- SIP/dialnet-8bac answered SIP/chris0-df00 -- Attempting native bridge of SIP/chris0-df00 and SIP/dialnet-8bac Feb 16 11:27:48 WARNING[68889520]: rtp.c:1204 ast_rtp_bridge: codec0 = 260 is not codec1 = 256, cannot native bridge. Feb 16 11:27:50 NOTICE[68889520]: rtp.c:264 process_rfc3389: RFC3389 support incomplete. Turn off on client if possible Feb 16 11:27:50 NOTICE[68889520]: rtp.c:293 process_rfc3389: Don't know how to handle RFC3389 for receive codec 256 ___ 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
[Asterisk-Users] codec negotiation
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
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
[Asterisk-Users] Codec Negotiation Does not seem to work as expected ?? Help Please !!
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. - Sam ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users
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
[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). Why this negotiation problem happens? Thanks Eduardo ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users