Re: [asterisk-users] FAX Issues
Unless your network is under load and you are seeing dropped packets and high jitter, I would absolutely not do T.38. The cheapest and easiest approach that I have found is to buy yourself an FXS gateway and just make sure you are using ulaw. Is this for personal use, or for business use? One feature that you may want to utilize is fax tone detection if you only have a single incoming line. If you use fax tone detection you can send the call directly to your FXS gateway. I've successfully faxed through my SIP provider as well as through an FXO gateway going to a DOCSIS modem (consumer grade "digital voice"). TDM and POTS are really synonymous by the way, TDM is just a more specific acronym (time-division multiplexing). You need not worry about the details though, if you are simply doing inband passthrough and you are using 711u on your VOIP legs you should be fine... YMMV of course. -Ryan On Tue, Aug 9, 2011 at 6:00 PM, Steve Totaro wrote: > On Tue, Aug 9, 2011 at 5:21 PM, C F wrote: >> On Tue, Aug 9, 2011 at 3:38 PM, Sassy Natan wrote: >>> Hi, >>> I would like to make sure I got it right: >>> 1. Asterisk 1.4 doesn't support FAX support. It do however works if u sent >>> fax from the PSTN and have anther FAX machine answer to it even if it is >>> behind asterisk. This works like any regular phone, and as far as I know >>> this mode known as T.38 pass through. >> >> No its not T.38 pass through. T.38 pass through is only if the 2 end >> points negotiated T.38, i.e. a provider that supports T.38 and an ATA >> that supports T.38. What you are describing will most likely fail if >> there is any VoIP in between, and should succeed over pure TDM using >> digium or similar cards. > > Fax was never officially supported by Asterisk/Digium using TDM cards. > > I works for the most part, but there is no comparison to a pure POTS > line. Much depends on the line quality, the sending and receiving fax > devices. Some places with good fax machines, PRIs coming in and some > FXS ports would work just fine. > > Others, are a nightmare and make you look bad. > > Depending on your customer's fax needs, sometimes it is better to tell > them to keep or have some POTS lines provisioned for reliable faxing > and to back that up, bring up being able to reach 911 if the phone > system is down and the company's liability, even though everyone has > cell phones. This is the best for TDM faxing with nothing fancy. > > I have sent people to www.trustfax.com > > TDM faxing is something that burned me more than once, so I don't suggest it. > >> >>> 2. If u want asterisk 1.4 to able to sent and receive emails you will have >>> to patch the source code using the spandsp patches. There are some other >>> ways to make this work like using IAX, hylafax but I need to know if this >>> is true. This mode is what know to be as NVFAX detected >> >> asterisk doesn't have the ability to send or receive emails. It does >> have the ability to use something like sendmail to send/receive >> emails. >> I'm assuming its a typo and you meant faxes. >> What exactly are you trying to accomplish? If you need to know >> something go ahead and try/test it and report back. After all that is >> what we all did to be able to answer it. Apparently the fact that >> others tried it and told you that it works still warrants a >> question:"I need to know if this is true" >> > > I have been advised that everyone must post their solutions to the > list so that you don't have to test. I think it was a self appointed > list moderator. People are required to come back, aknowledge that > something worked and give credit. Flaw: Just because something worked > for someone doesn't mean that your solution wouldn't work better. > > Anyways, I am with you. I learned this stuff with very little > documentation except .conf examples and code. Integration is where > things get really fun and creative. Logically testing and failing and > testing until you find your solution is extremely rewarding (at least > to me). Making a Definity G3 and Asterisk fully integrate can cause > severe rage followed by euphoria, so be warned. Being creative is > dangerous to some on the list. > > Try iaxmodem and hylafax. Alex B did a very nice writeup on how to > set that up so that it works very well. > >> >>> 3. Now version 1.6 support Fax in a better way then 1.4. There is app_fax.c >>> in the source code. Can someone please tell me what does this apps do? >> >> I assume you meant than not then, but I'm not sure if its a typo, you >> might just not know. >> app_fax.c does faxing. The question is what are YOU trying to do? >> >> >>> 4. Version 1.8 as two modes: SpanDSP mode and some other method, what is >>> the different between then can someone please help? >> >> Whats the other mode? >> > > The best mode for T38 is probably Freeswitch or Callweaver. > >> >>> >>> Thanks >>> Sassy >>> -- > > -- > _ > -- Ba
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)
>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
