[Home]

Summary:ASTERISK-11843: Asterisk negotiates only T.38 when answering even if the other end offers audio
Reporter:Marcelo M. Sosa Lugones (marsosa)Labels:
Date Opened:2008-04-14 08:31:15Date Closed:2010-09-08 11:55:31
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/T.38
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) called_no_reinvite
( 1) calling_no_reinvite
( 2) dumpfile2
( 3) sip.conf
( 4) sip-debug-t38.txt
( 5) t38-error.txt
( 6) teles_t38-error.txt
( 7) teles_ast_teles_called__asttrace.txt
( 8) teles_ast_teles_calling__asttrace.txt
( 9) TelesTeles_a-side.txt.bak
(10) TelesTeles_b-side.txt
Description:One of our gateways (audiocodes mp-118) offers ulaw,g729 and t.38 when an incoming call is sent to asterisk, and asterisk answer() with t.38 only, instead of using ulaw. T.38 is enabled on the gateway because this is needed for reinvites, if i disable it, the call works ok but fails later when the ata wants to do reinvite for receiving faxes with t.38 '488 not acceptable'.
The main problem here is that, after answering with t.38, asterisk sends invites with t.38 only to the ip phones, and they rejected with not acceptable.
Comments:By: pinga-fogo (pinga-fogo) 2008-06-11 03:28:58

I have the same problem with a nortel MCS Border, and my asterisk show a RTP error , if the call is a fax, all is fine, and if the call is voice call, asterisk only negotiates t38 call, and i get some error and i can execute app playback
By: Sam Deller (samdell3) 2008-06-16 16:54:17

Exact same problem here with Patton SmartNode. They offer T.38 in the initial invite (as well as audio codecs). Asterisk 'always' sets the call up as T.38, even if its only voice call.
Ideally, Asterisk should first setup as a vanilla audio call, and wait for the re-invite to T.38 when fax is detected by the receiving endpoint.

I dont think anyone is at fault. The so called T.38 'standard' can be interpreted many different ways.....

The most common standard is to *not* offer T.38 in the initial invite, and for the receiving party to offer the T.38 re-invite upon fax detection.
However, it would be a great bonus to have Asterisk compatible with T.38 offering in the initial SDP
By: wubbla (wubbla) 2008-06-28 09:25:29

@samdell3: How did you solve this problem? Or: have you found a workaround for the patton smartnodes?
By: Sam Deller (samdell3) 2008-06-28 15:01:53

Q) Wubbla: @samdell3: How did you solve this problem? Or: have you found a workaround for the patton smartnodes?

A) In the very latest patton 5.T Smartnode software build, Patton has removed the T.38 offering from the initial SDP, and it now re-invites for T.38 only when required. I dont think this latest build is on their website yet, someone from support@patton.com emailed it to me. We havent fully tested every possible call scenario either, but on the face of it so far, the Patton Smartnode series is now compatible with Asterisk T.38.
HOWEVER: 5.T.latest build seems to have lost DNS SRV functionality, so redundancy is now the problem.

All this aside, it would still be *really* nice for Asterisk to be able to negotiate fax or audio calls correctly when receiving the T.38 offering in the initial SDP. It's not just becasue of Patton devices... other client devices can work this way also.
By: Mazhar Abbas (mazhar996) 2008-07-22 18:20:34

Hi there,
   I have exactly the same problem with TELES.iSWITCH , TELES offers T.38 in the initial invite and Asterisk negotiates T.38, this causes a voice call to fail. Even IVRs could not be played.
    Its hard for me to convence my provider to enable T.38 but negotiate it in the reinvite instead of initial invite. They say thats their standard, either they can enable it on the whole or not at all.
     Please let me know if there is some fix.
By: JR Richardson (hubguru) 2008-09-09 12:40:03

Hi All,
I have the same issue with Asterisk 1.4.21.1 and Dialogic DMG 2000 firmware 6.0.103.
The DMG invite sends to asterisk:
m=audio 49016 RTP/AVP 0 101          [notice the m=audio]

And Asterisk responds with the 200 OK:
m=image 29475 udptl t38                   [notice the m=image]

Quote from Raj Jain:
That's how T.38 gateways typically work. This particular gateway seems
to have some advanced knowledge that the call may be converted into
T.38 later. They are offering m=image with port number set to 0 in the
INVITE. By doing this, they seem to be offering a sort "heads up" that
the call may be converted to T.38 later but no T.38 now because the
port number is zero. This hint is of no use to Asterisk. If you can
get the gateway to not send the m=image line in the first INVITE, they
you may be in luck.

This seems like a bug in Asterisk. Asterisk is encoding the SDP in 200
OK incorrectly on two fronts. It's dropping the m=audio line
completely and it's activating T.38 stream when the remote end hasn't
asked it to do so.


By: Csaba Lack (csabka) 2008-09-25 12:36:54

I have tested today the latest SVN (1.4-r144356) and Patton SmartNode 4638 4 BRI (R4.2 2008-07-11 release) but still has this problem.

Previous test was on 11th March 2008 and the same wrong result.

Do someone have any patch?
By: Csaba Lack (csabka) 2008-09-25 12:44:01

This bug should be the same, but I think it hasn't been solved, or changed after:

http://bugs.digium.com/bug_view_page.php?bug_id=9402

Normal incoming call is not working when t38 is enabled

From sip type=peer (Patton) -> sip type=friend (SIP phone) call is the problem,
The from sip type=friend -> to sip type=peer is working fine.


By: JR Richardson (hubguru) 2008-10-01 14:46:04

I am currently testing the Audiocodes Mediant 1000 Gateway with PRI and firmware version 5.20A.027.004.

I'm getting the same results as I did with the dialogic.  The ac1000 sends initial SDP with:
m=audio 6300 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=sendrecv
a=rtcp:6301 IN IP4 208.81.54.72
m=image 6302 udptl t38
a=T38FaxVersion:0
a=T38MaxBitRate:14400
a=T38FaxMaxBuffer:1024
a=T38FaxMaxDatagram:122
a=T38FaxRateManagement:transferredTCF
a=T38FaxUdpEC:t38UDPRedundancy

and Asterisk 1.4.21.1 responds back with only t38, no audio:
m=image 24420 udptl t38
a=T38FaxVersion:0
a=T38MaxBitRate:14400
a=T38FaxFillBitRemoval:0
a=T38FaxTranscodingMMR:0
a=T38FaxTranscodingJBIG:0
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxBuffer:122
a=T38FaxMaxDatagram:122
a=T38FaxUdpEC:t38UDPRedundancy

So I get this error at the CLI and the call drops:
ERROR[11074]: chan_sip.c:12399 handle_response_invite: Got error on T.38 initial invite. Bailing out.
By: Olivier Krief (okrief) 2008-10-06 04:33:42

An offtopic question to samdell3 :
Do you have any BugID we could use when exchanging info with Patton ?
I would like to double check that the firmware we're using includes whatever is needed to comply with Asterisk handling of T.38 ?
Thanks in advance
By: Sam Deller (samdell3) 2008-10-06 14:01:38

okrief:
We are now using smartnode 5.T public release (available from Patton website) and Smartnodes all work fine. The 4900 series channel banks, ISDN, and FXS units have all been tested here in production with Asterisk v1.4.14.
Whats your email? - I'll contact you offlist...
By: Olivier Krief (okrief) 2008-10-06 16:39:42

samdell3 :
My email is oza-4h07 at myamail dot com
By: pinga-fogo (pinga-fogo) 2008-10-10 08:14:44

I have tested now, and i have the same problem in 1.6 version.
By: GERD GERD (gerd1000) 2008-10-20 07:12:08

@marsosa, @Hubguru:
If you try not to use T.38 as a codec maybe then it will not appear
in the initial INVITE (AudioCodes only).
By: Csaba Lack (csabka) 2008-10-20 08:12:43

@gerd1000, I think they know it, just they need the T.38 funcionality as well.

Of course it is not so nice, that in the initial SDP the T38 codec as well coming, but I think this shouldn't broke asterisk's normal call. I think asterisk should ignore the initial SDP T.38, and only in case of fax should be accepted.

I have tested the newest firmware of Patton (5.x) and It works fine with asterisk (it sends t.38 sdp only when fax transmission detected...).

From the Patton side this issue have been solved in the newer release, but what is about asterisk side?

Will it be solved?
By: GERD GERD (gerd1000) 2008-10-20 08:55:17

@csabka: For AudioCodes: In the "General Settings" the FAX signalling method shall be T.38
 but in the Coders configuration do not add T.38 as a codec.
 Maybe this does not add T.38 in the initial INVITE.
By: Holger Witt (skytron) 2008-10-27 05:49:34

Is there a way, that asterisk handle the initial invite correctly ?
Asterisk should also reply to the offered audio stream like

   m=audio 0 RTP/AVP 0 96
   a=rtpmap:96 telephone-event/8000

not only
   m=image 24420 udptl t38
   ....
By: Olivier Krief (okrief) 2009-02-16 08:42:23.000-0600

@csabka or samdell3:
which Patton firmware solved this ?
By: Sam Deller (samdell3) 2009-02-16 14:04:30.000-0600

@csabka or samdell3:
which Patton firmware solved this ?

5.T and 5.2 both work fine with Asterisk T.38.
With 5.x if you use DNS SRV functionality for client-side failover you need to have NO sip password on both Patton and Asterisk due to interop authentication 'differences'.
By: Olivier Krief (okrief) 2009-02-17 01:30:15.000-0600

Thanks ! I used 4.T or 4.2.
By: Joshua C. Colp (jcolp) 2009-02-18 08:51:17.000-0600

I've created a branch at http://svn.digium.com/svn/asterisk/team/file/issue12437 that has a few changes to hopefully better handle an initial INVITE with T38.

chan_sip will now respond with SDP that includes the different media streams offered. For example if an INVITE comes in with both audio and T38 we will now respond back with audio and T38.

For the outgoing call from a channel that has both audio and T38 we will only offer audio initially. If T38 packets come in we will then trigger a reinvite to T38. I did it this way since reinvites seem to have the best compatibility between devices.

Please give it a go and provide any feedback. I've done what testing I can with what I have.
By: Olivier Krief (okrief) 2009-02-26 07:24:11.000-0600

I gave this http://svn.digium.com/svn/asterisk/team/file/issue12437 [^] branch a try but I get :
chan_sip.c:14870 handle_request_invite: RTP re-invite after T38 session not handled yet !

My setup is :
Patton SN4638 --- Asterisk --- Patton M-ATA or Linksys 3102 ATAs --- Fax machine

Thanks to samdell3's tip, Patton side seems OK (I used SmartWare 5.3) so I'm focusing on Asterisk here.

Does this branch suppose canreinvite to be set to yes, nonat or something else ?
By: Joshua C. Colp (jcolp) 2009-02-26 07:30:02.000-0600

It should not matter what canreinvite is set to. A sip debug of the above happening as an attachment would be helpful.
By: Joshua C. Colp (jcolp) 2009-02-26 14:04:24.000-0600

For those who are new to subversion you will have to install it and then check out the branch using:

svn co http://svn.digium.com/svn/asterisk/team/file/issue12437

The source code will bei n the issue12437 directory.
By: Olivier Krief (okrief) 2009-02-26 14:30:05.000-0600

At the moment, results are contrasted : some successful, some not. I'll try to formalize them before reporting here.
By: pinga-fogo (pinga-fogo) 2009-03-03 17:48:35.000-0600

I'll try this branch and sometings works sometings not...

Scenario 1

A Call from nortel mcs(always send t38 in the inicial invite)to asterisk, in the dialplan i do a Answer and play a audio file.. this works fine...the asterisk offers audio...

MCS ---> Asterisk --> file playback

Scenario 2

MCS ---> Asterisk --> Poycom Ip430
This scenario does not work, the

in the sip debug i see the codec negotiations is ok
Capabilities: us - 0x10c (ulaw|alaw|g729), peer - audio=0x108 (alaw|g729)/video=0x0 (nothing), combined - 0x108 (alaw|g729)
Non-codec capabilities (dtmf): us - 0x1 (telephone-event), peer - 0x1 (telephone-event), combined - 0x1 (telephone-event)
but after the dial command the asterisk shows
  -- Executing [s@macro-stdexten:2] Dial("SIP/ip4440015253f-0070d2d0", "SIP/5002&SIP/5008|30|tTj") in new stack
[Mar  3 14:07:46] WARNING[16420]: chan_sip.c:3081 sip_call: No audio format found to offer. Cancelling call to 5002
   -- Couldn't call 5002
[Mar  3 14:07:46] WARNING[16420]: chan_sip.c:3081 sip_call: No audio format found to offer. Cancelling call to 5008
   -- Couldn't call 5008

and the 5002 and 5008 is ok .. all are the codecs 729 and 711 enabled and configured

sorry about my english ...
i hope this can help us
By: Joshua C. Colp (jcolp) 2009-03-04 08:21:33.000-0600

pinga-fogo: Can you please upload the complete console output plus sip debug? Thanks. That should tell me what I need to know.
By: pinga-fogo (pinga-fogo) 2009-03-04 09:11:43.000-0600

<--- SIP read from 200.146.79.165:1571 --->
INVITE sip:FAX_SDI@189.114.245.124 SIP/2.0
Via: SIP/2.0/UDP 200.146.79.165:1571;branch=z9hG4bK5ibiuu204o301ggfv5k0.1
t: "Camilo MGA t38" <sip:0904430322095@gvt.com.br:5060;user=phone>
f: <sip:4433055130@gvt.com.br:5060;user=phone>;tag=SDeehl201-c0a-13c4-420681-2bb94f8c-420681
i: SDeehl201-dd829eb2bac4b242ca1a53cf2ba12e69-v300g00
CSeq: 1 INVITE
Max-Forwards: 138
x-nt-corr-id: 11fd2095f361670a523c580a9534ffc169a16c032@200.175.10.194
X-Nortel-Profile: CTA
x-nt-location: 120224
Allow: ACK,BYE,CANCEL,INVITE,OPTIONS,INFO,SUBSCRIBE,REFER,NOTIFY,PRACK
m: <sip:4433055130@200.146.79.165:1571;nt_end_pt=YM0+~K12.1zqa131CQit~Kb2P0~Rn2rcevNknice~NC_2SS1y8J+90~EbtYMig~WD9QOkbO.1j83Q8SD1MXU7t.BC1paf6.DbO9o1Tcb1M2tietG~~iE4q44894;nt_server_host=200.175.10.194;transport=udp>
Remote-Party-ID: <sip:4433055130@10.140.131.208;user=phone>;screen=yes;party=calling
k: 100rel,com.nortelnetworks.firewall,p-3rdpartycontrol,nosec
User-Agent: CS2000_NGSS/9.0
l: 420
c: application/sdp
X-Omni-User: sip:ip4440015253f@gvt.com.br

v=0
o=PVG 1236168590700 1236168590700 IN IP4 200.146.79.165
s=-
p=+1 6135555555
c=IN IP4 200.146.79.165
t=0 0
m=audio 10506 RTP/AVP 18 8 101
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=fmtp:18 annexb=no
m=image 11518 udptl t38
a=T38FaxVersion:0
a=T38FaxMaxBuffer:1100
a=T38FaxMaxDatagram:612
a=T38MaxBitRate:14400
a=T38FaxRateManagement:transferredTCF
a=T38FaxUdpEC:t38UDPRedundancy

<------------->
--- (18 headers 18 lines) ---
Sending to 200.146.79.165 : 1571 (no NAT)
Using INVITE request as basis request - SDeehl201-dd829eb2bac4b242ca1a53cf2ba12e69-v300g00
Found peer 'ip4440015253f'
Found RTP audio format 18
Found RTP audio format 8
Found RTP audio format 101
Got T.38 offer in SDP in dialog SDeehl201-dd829eb2bac4b242ca1a53cf2ba12e69-v300g00
Peer audio RTP is at port 200.146.79.165:10506
Found audio description format telephone-event for ID 101
Capabilities: us - 0x10c (ulaw|alaw|g729), peer - audio=0x108 (alaw|g729)/video=0x0 (nothing), combined - 0x108 (alaw|g729)
Non-codec capabilities (dtmf): us - 0x1 (telephone-event), peer - 0x1 (telephone-event), combined - 0x1 (telephone-event)
Peer audio RTP is at port 200.146.79.165:10506
Looking for FAX_SDI in sip-did (domain 189.114.245.124)
list_route: hop: <sip:4433055130@200.146.79.165:1571;nt_end_pt=YM0+~K12.1zqa131CQit~Kb2P0~Rn2rcevNknice~NC_2SS1y8J+90~EbtYMig~WD9QOkbO.1j83Q8SD1MXU7t.BC1paf6.DbO9o1Tcb1M2tietG~~iE4q44894;nt_server_host=200.175.10.194;transport=udp>

<--- Transmitting (no NAT) to 200.146.79.165:1571 --->
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 200.146.79.165:1571;branch=z9hG4bK5ibiuu204o301ggfv5k0.1;received=200.146.79.165
From: <sip:4433055130@gvt.com.br:5060;user=phone>;tag=SDeehl201-c0a-13c4-420681-2bb94f8c-420681
To: "Camilo MGA t38" <sip:0904430322095@gvt.com.br:5060;user=phone>
Call-ID: SDeehl201-dd829eb2bac4b242ca1a53cf2ba12e69-v300g00
CSeq: 1 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Contact: <sip:FAX_SDI@189.114.245.124>
Content-Length: 0


<------------>
   -- Executing [FAX_SDI@sip-did:1] NoOp("SIP/ip4440015253f-0069bf00", "") in new stack
   -- Executing [FAX_SDI@sip-did:2] Set("SIP/ip4440015253f-0069bf00", "pseudodid="Camilo MGA t38" <sip:0904430322095@gvt.com.br:5060;user=phone>") in new stack
   -- Executing [FAX_SDI@sip-did:3] Set("SIP/ip4440015253f-0069bf00", "pseudodid=Camilo MGA t38 <sip:0904430322095") in new stack
   -- Executing [FAX_SDI@sip-did:4] Set("SIP/ip4440015253f-0069bf00", "pseudodid=0904430322095") in new stack
   -- Executing [FAX_SDI@sip-did:5] NoOp("SIP/ip4440015253f-0069bf00", "2095") in new stack
   -- Executing [FAX_SDI@sip-did:6] Goto("SIP/ip4440015253f-0069bf00", "sip-did|2095|1") in new stack
   -- Goto (sip-did,2095,1)
   -- Executing [2095@sip-did:1] Goto("SIP/ip4440015253f-0069bf00", "entrante-analog|s|1") in new stack
   -- Goto (entrante-analog,s,1)
   -- Executing [s@entrante-analog:1] Wait("SIP/ip4440015253f-0069bf00", "2") in new stack
   -- Executing [s@entrante-analog:2] Set("SIP/ip4440015253f-0069bf00", "CIDName="Externa"") in new stack
   -- Executing [s@entrante-analog:3] Macro("SIP/ip4440015253f-0069bf00", "stdexten|s|SIP/5002&SIP/5008|tTj") in new stack
   -- Executing [s@macro-stdexten:1] SIPAddHeader("SIP/ip4440015253f-0069bf00", "Alert-Info: Bellcore-r1") in new stack
   -- Executing [s@macro-stdexten:2] Dial("SIP/ip4440015253f-0069bf00", "SIP/5002&SIP/5008|30|tTj") in new stack
[Mar  4 11:07:03] WARNING[27302]: chan_sip.c:3081 sip_call: No audio format found to offer. Cancelling call to 5002
   -- Couldn't call 5002
Scheduling destruction of SIP dialog '08640e3e4d83fac85cfc139c03665669@172.16.5.194' in 32000 ms (Method: INVITE)
[Mar  4 11:07:03] WARNING[27302]: chan_sip.c:3081 sip_call: No audio format found to offer. Cancelling call to 5008
   -- Couldn't call 5008
Scheduling destruction of SIP dialog '33c51f7b43cd0214355165cc3f41c9cb@172.16.5.194' in 32000 ms (Method: INVITE)
 == Everyone is busy/congested at this time (0:0/0/0)
   -- Executing [s@macro-stdexten:3] Goto("SIP/ip4440015253f-0069bf00", "s-CHANUNAVAIL|1") in new stack
   -- Goto (macro-stdexten,s-CHANUNAVAIL,1)
   -- Executing [s-CHANUNAVAIL@macro-stdexten:1] Goto("SIP/ip4440015253f-0069bf00", "s-NOANSWER|1") in new stack
   -- Goto (macro-stdexten,s-NOANSWER,1)
   -- Executing [s-NOANSWER@macro-stdexten:1] Playback("SIP/ip4440015253f-0069bf00", "/var/lib/asterisk/sounds/camilo/astcc-noanswer") in new stack
[Mar  4 11:07:03] NOTICE[27302]: chan_sip.c:6679 add_sdp: add audio = 1 add t38 = 1
Audio is at 189.114.245.124 port 14892
Adding codec 0x8 (alaw) to SDP
Adding codec 0x100 (g729) to SDP
Adding non-codec 0x1 (telephone-event) to SDP

<--- Reliably Transmitting (no NAT) to 200.146.79.165:1571 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 200.146.79.165:1571;branch=z9hG4bK5ibiuu204o301ggfv5k0.1;received=200.146.79.165
From: <sip:4433055130@gvt.com.br:5060;user=phone>;tag=SDeehl201-c0a-13c4-420681-2bb94f8c-420681
To: "Camilo MGA t38" <sip:0904430322095@gvt.com.br:5060;user=phone>;tag=as61d79fef
Call-ID: SDeehl201-dd829eb2bac4b242ca1a53cf2ba12e69-v300g00
CSeq: 1 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Contact: <sip:FAX_SDI@189.114.245.124>
Content-Type: application/sdp
Content-Length: 478

v=0
o=root 27158 27158 IN IP4 189.114.245.124
s=session
c=IN IP4 189.114.245.124
t=0 0
m=audio 14892 RTP/AVP 8 18 101
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv
m=image 27898 udptl t38
a=T38FaxVersion:0
a=T38MaxBitRate:9600
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxBuffer:612
a=T38FaxMaxDatagram:612
a=T38FaxUdpEC:t38UDPRedundancy

<------------>
   -- <SIP/ip4440015253f-0069bf00> Playing '/var/lib/asterisk/sounds/camilo/astcc-noanswer' (language 'en')
srvsmbig*CLI>
<--- SIP read from 200.146.79.165:1571 --->
ACK sip:FAX_SDI@189.114.245.124 SIP/2.0
Via: SIP/2.0/UDP 200.146.79.165:1571;branch=z9hG4bKdkrkmn0068i06i4q60s0.1
t: "Camilo MGA t38" <sip:0904430322095@gvt.com.br:5060;user=phone>;tag=as61d79fef
f: <sip:4433055130@gvt.com.br:5060;user=phone>;tag=SDeehl201-c0a-13c4-420681-2bb94f8c-420681
i: SDeehl201-dd829eb2bac4b242ca1a53cf2ba12e69-v300g00
CSeq: 1 ACK
Max-Forwards: 68
Allow: ACK,BYE,CANCEL,INVITE,OPTIONS,INFO,SUBSCRIBE,REFER,NOTIFY,PRACK,UPDATE
m: <sip:4433055130@200.146.79.165:1571;nt_end_pt=YM0+~K12.1zqa131CQit~Kb2P0~Rn2rcevNknice~NC_2SS1y8J+90~EbtYMig~WD9QOkbO.1j83Q8SD1MXU7t.BC1paf6.DbO9o1Tcb1M2tietG~~iE4q44894;nt_server_host=200.175.10.194;transport=udp>
k: 100rel
User-Agent: CS2000_NGSS/9.0
l: 0


<------------->
--- (12 headers 0 lines) ---
   -- Executing [s-NOANSWER@macro-stdexten:2] Goto("SIP/ip4440015253f-0069bf00", "entrante-analog|s|1") in new stack
   -- Goto (entrante-analog,s,1)
 == Channel 'SIP/ip4440015253f-0069bf00' jumping out of macro 'stdexten'
   -- Executing [s@entrante-analog:1] Wait("SIP/ip4440015253f-0069bf00", "2") in new stack
   -- Executing [s@entrante-analog:2] Set("SIP/ip4440015253f-0069bf00", "CIDName="Externa"") in new stack
   -- Executing [s@entrante-analog:3] Macro("SIP/ip4440015253f-0069bf00", "stdexten|s|SIP/5002&SIP/5008|tTj") in new stack
   -- Executing [s@macro-stdexten:1] SIPAddHeader("SIP/ip4440015253f-0069bf00", "Alert-Info: Bellcore-r1") in new stack
   -- Executing [s@macro-stdexten:2] Dial("SIP/ip4440015253f-0069bf00", "SIP/5002&SIP/5008|30|tTj") in new stack
[Mar  4 11:07:07] WARNING[27302]: chan_sip.c:3081 sip_call: No audio format found to offer. Cancelling call to 5002
   -- Couldn't call 5002
Scheduling destruction of SIP dialog '7b04956b3f054c2052a5dace38404ee9@172.16.5.194' in 32000 ms (Method: INVITE)
[Mar  4 11:07:07] WARNING[27302]: chan_sip.c:3081 sip_call: No audio format found to offer. Cancelling call to 5008
   -- Couldn't call 5008
Scheduling destruction of SIP dialog '1a0a549270aa43e526be1ad12f20d081@172.16.5.194' in 32000 ms (Method: INVITE)
 == Everyone is busy/congested at this time (0:0/0/0)
   -- Executing [s@macro-stdexten:3] Goto("SIP/ip4440015253f-0069bf00", "s-CHANUNAVAIL|1") in new stack
   -- Goto (macro-stdexten,s-CHANUNAVAIL,1)
   -- Executing [s-CHANUNAVAIL@macro-stdexten:1] Goto("SIP/ip4440015253f-0069bf00", "s-NOANSWER|1") in new stack
   -- Goto (macro-stdexten,s-NOANSWER,1)
   -- Executing [s-NOANSWER@macro-stdexten:1] Playback("SIP/ip4440015253f-0069bf00", "/var/lib/asterisk/sounds/camilo/astcc-noanswer") in new stack
   -- <SIP/ip4440015253f-0069bf00> Playing '/var/lib/asterisk/sounds/camilo/astcc-noanswer' (language 'en')
Really destroying SIP dialog 'BD21-16CF-46684823DBE7893D776A-005@SipHost' Method: REGISTER
Really destroying SIP dialog 'BD21-16CF-4668482379FABBEFDA77-007@SipHost' Method: REGISTER
Really destroying SIP dialog 'BD21-16CF-46684823EF67CE8DDEF0-008@SipHost' Method: REGISTER
srvsmbig*CLI>
<--- SIP read from 200.146.79.165:1571 --->
BYE sip:FAX_SDI@189.114.245.124 SIP/2.0
Via: SIP/2.0/UDP 200.146.79.165:1571;branch=z9hG4bKdkrkmn0068i06i4q60s0cd0000010.1
t: "Camilo MGA t38" <sip:0904430322095@gvt.com.br:5060;user=phone>;tag=as61d79fef
f: <sip:4433055130@gvt.com.br:5060;user=phone>;tag=SDeehl201-c0a-13c4-420681-2bb94f8c-420681
i: SDeehl201-dd829eb2bac4b242ca1a53cf2ba12e69-v300g00
CSeq: 2 BYE
Max-Forwards: 68
Allow: ACK,BYE,CANCEL,INVITE,OPTIONS,INFO,SUBSCRIBE,REFER,NOTIFY,PRACK,UPDATE
Reason: Q.850;cause=16;text="Normal call clearing"
k: 100rel,com.nortelnetworks.firewall,p-3rdpartycontrol,nosec
User-Agent: CS2000_NGSS/9.0
l: 0


<------------->
--- (12 headers 0 lines) ---
Sending to 200.146.79.165 : 1571 (no NAT)

<--- Transmitting (no NAT) to 200.146.79.165:1571 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 200.146.79.165:1571;branch=z9hG4bKdkrkmn0068i06i4q60s0cd0000010.1;received=200.146.79.165
From: <sip:4433055130@gvt.com.br:5060;user=phone>;tag=SDeehl201-c0a-13c4-420681-2bb94f8c-420681
To: "Camilo MGA t38" <sip:0904430322095@gvt.com.br:5060;user=phone>;tag=as61d79fef
Call-ID: SDeehl201-dd829eb2bac4b242ca1a53cf2ba12e69-v300g00
CSeq: 2 BYE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Content-Length: 0


<------------>
 == Spawn extension (macro-stdexten, s-NOANSWER, 1) exited non-zero on 'SIP/ip4440015253f-0069bf00' in macro 'stdexten'
 == Spawn extension (entrante-analog, s, 3) exited non-zero on 'SIP/ip4440015253f-0069bf00'
Really destroying SIP dialog 'SDeehl201-dd829eb2bac4b242ca1a53cf2ba12e69-v300g00' Method: BYE
Really destroying SIP dialog '287f4e10044a36207914f5a75f73e799@172.16.5.194' Method: INVITE
Really destroying SIP dialog '05c12fa00842f38f2deb608a4d8a846b@172.16.5.194' Method: INVITE
By: pinga-fogo (pinga-fogo) 2009-03-04 10:47:24.000-0600

Ps.. the sip channels "SIP/5002&SIP/5008" not support t38.. only audio...
By: Joshua C. Colp (jcolp) 2009-03-04 15:33:37.000-0600

I've just used your SIP traces in a test to see if I could reproduce the issue you are running into, but could not. Could you please *attach* the configuration for the phones you are trying to dial minus passwords and the output of "show modules" - Thanks.
By: pinga-fogo (pinga-fogo) 2009-03-04 17:21:48.000-0600

this sip trace is ok... the problem is i receive a call from gvt but asterisk does not invite the phones
[Mar 4 11:07:07] WARNING[27302]: chan_sip.c:3081 sip_call: No audio format found to offer. Cancelling call to 5002

i can see ane invite from asterisk to the phones... try this to reproduce the issue...

create a peer with t38(with the initial invite) and g711 support...
and create a peer with only g711 suppor and try to do a voice call...
i post my configs latter ok..
thanks
By: pinga-fogo (pinga-fogo) 2009-03-04 17:37:26.000-0600

Sorry, i see my config files and the peers 5002 and 5008 is only g729, and i dont have te 729 license in the test...
i try latter and works ... i can have a voice call .. its works.. i not tested the t38 reinvite after the voice call yet... i will try now
By: pinga-fogo (pinga-fogo) 2009-03-04 17:53:03.000-0600

aparently works... i testet with a nortel mcs and a dlink gateway... all works.. the voice first and latter the reinvite!! its great... you can have somethings to i try this in the 1.6 version ? with te Receivefax application..
By: Joshua C. Colp (jcolp) 2009-03-09 08:37:27

pinga-fogo: Glad to hear it. I don't yet have a 1.6 version, but it would work the same.

Has anyone else been doing any testing?
By: Andrea Borghi (aborghi) 2009-03-09 09:15:39

Iam suffering the very same problem with patton and t.38 on one of my installation where i route the calls though asterisk (while in others i have the pattons configured to route fax calls between each other bypassing asterisk altogether.)

I am planning to make some tests at the end of this week.
By: Olivier Krief (okrief) 2009-03-11 05:49:47

Partial report: Can't send fax from Zoiper softphone to Patton Gateway. Output is:
   -- Called patton/0123450026
   -- SIP/patton-081dfc68 is ringing
   -- SIP/patton-081dfc68 answered SIP/7533-081dab10
[Mar 11 11:43:59] NOTICE[2574]: chan_sip.c:6679 add_sdp: add audio = 1 add t38 = 0
[Mar 11 11:43:59] NOTICE[2449]: chan_sip.c:6679 add_sdp: add audio = 0 add t38 = 1
[Mar 11 11:43:59] NOTICE[2449]: chan_sip.c:6679 add_sdp: add audio = 0 add t38 = 1
[Mar 11 11:44:25] WARNING[2449]: chan_sip.c:14870 handle_request_invite: RTP re-invite after T38 session not handled yet !

Sending endpoint says "Successfully sent" but receiving endpoint says "Communication error".
By: Joshua C. Colp (jcolp) 2009-03-11 08:26:57

okrief: Please attach a file containing complete console output with sip debug.
By: Olivier Krief (okrief) 2009-03-11 08:50:38

I have attached 2 files called dumpfile1 and dumpfile2.
dumpfile1 is useless (I don't know how to remove it).
dumpfile2 is a wireshark capture file.
Is it OK with it and shall I capture from console as requested ?
By: Joshua C. Colp (jcolp) 2009-03-11 09:33:32

These are fine although it looks like you aren't actually having the problem this issue is about but just another design limitation. I'll see if I can come up with a solution for it though and incorporate it.
By: Olivier Krief (okrief) 2009-03-11 09:57:05

Which design limitation are refering to ?
The "RTP re-invite after T38 session not handled yet !" one ?
By: Joshua C. Colp (jcolp) 2009-03-11 10:00:17

okrief: I've made a change that should hopefully allow the call to go back to audio, which should hopefully make stuff happy. Please update and try again.
By: Olivier Krief (okrief) 2009-03-11 11:00:26

Does it help if I attach here a successful fax transmission between 2 endpoints on the same Asterisk server ?
That could be used as a reference.
By: Joshua C. Colp (jcolp) 2009-03-11 11:02:23

Not really, I just want to see problems really.
By: Olivier Krief (okrief) 2009-03-11 11:06:18

Is this change available, now ?
If positive, how can I download it ?
By: Joshua C. Colp (jcolp) 2009-03-11 11:11:53

It is available in the branch that I mentioned a few notes ago. Instructions are also there for checking it out.
By: Olivier Krief (okrief) 2009-03-11 12:49:49

OK I installed and tested a bit : no regression at first sight.
By: Olivier Krief (okrief) 2009-03-11 13:22:02

One positive note as a case that failed before today's change in code, now somehow works : out of 6 attempts, 5 worked OK.
Comparing with previous behaviour shows (or seems to show) that when Patton SN4638 wants to end a T.38, it reverts back to G711 on SIP side before acking communication on BRI side.
Do you think its correct ?
If positive, is it standard practice ?
By: Joshua C. Colp (jcolp) 2009-03-11 13:24:35

I would not say it is standard practice... this is the first time I've actually heard of someone running into that.
By: Joshua C. Colp (jcolp) 2009-03-12 10:46:35

I've created a branch for those using 1.6.0 that would like to test these changes. It is available at http://svn.digium.com/svn/asterisk/team/file/issue12437-1.6.0 - and please remember if you have an issue to please attach complete console output and sip debug output.
By: afu (afu) 2009-03-25 10:09:37

Hi file!
The reinvite of T38 seem to work, but there is another issue. Teles sends codec + T38 for every call, even if its voice.

verbose says: add audio = 1 add t38 = 0
but Autodestruct on dialog '2cf6ffdd63b70b40308d84f75506b793@ip-asterisk' with owner in place (Method: INVITE)

so a voice call would last only 32 secs.

see attached file teles_t38-error.txt with verbose 3, and sip traces for outgoing and incoming side

thanks!

greetings from austria, andy

PS: please remove the first upload, thanks!


By: Joshua C. Colp (jcolp) 2009-03-25 10:36:38

Should be fixed in SVN. Update and give it a go!
By: afu (afu) 2009-03-26 07:24:26

first thanks for fast reply. Much better, but there is another issue:
as seen in the attached files, teles answers with an "Session Progress" with g729 only, but this is forwarded to the caller als "Session Progress" with g729 AND T38. After "Ringing" the call is destroyed.

Any idea?

greetings, andy
By: Joshua C. Colp (jcolp) 2009-03-26 10:26:37

afu: That is to be expected. That is the way the change works. Now the question is - if you configure the entry in sip.conf with canreinvite=no does the problem go away?
By: afu (afu) 2009-03-26 10:57:15

hello again!

reinvite to no on all peers doen't change anything (and i think, t38 wouldn't go any longer, because it would need reinvite, if i'm right...)

did more tests:
2 Sides Teles Gateways direct connect works fine.
proxy through asterisk has funny options.

phone rings, b takes the call. a hears b because of inband info, gets no connect! of cause its an one way audio.
after about a minute a is released by asterisk.
if b drops the line within about 30 seconds the call leg to a is setup again!
(this part is not in the trace file)

see attached files
teles ast teles calling  (asttrace).txt
and
teles ast teles called  (asttrace).txt

greetings andy


By: Joshua C. Colp (jcolp) 2009-03-26 11:05:16

Are you sure you set the canreinvite option to no? I'm still seeing reinvites (and T38 will work without reinvites). If you set the 'reinvite' option to no, then that would have no effect since the option is 'canreinvite'.
By: afu (afu) 2009-03-26 11:32:33

in the old trace reinvite was on, but i did new traces. (and included sip.conf)
for all peers in db sip_peers canreinvite is set to no


By: Joshua C. Colp (jcolp) 2009-03-26 11:37:08

Okay, so now explain to me the exact scenario of what is happening/what you are doing so I can try to understand this more. What do each debug logs represent? What is the network topology?
By: Joshua C. Colp (jcolp) 2009-03-26 11:42:45

Nevermind! Found it. I'll add a note once I have a fix in SVN.
By: afu (afu) 2009-03-26 11:45:45

scenario is:

TelesGW -> Asterisk -> TelesGW

Teles has enabled G729 and T38.

ip-teles-a dials out,
ip-teles-b gets the call.
The files are sip trace for the two sides (one taken after the other)

a direct call from teles to teles works fine (so teles itself should be no problem)
By: Joshua C. Colp (jcolp) 2009-03-26 11:49:01

Okay, please update and test.
By: afu (afu) 2009-03-26 16:06:49

Thanks a lot!
First try seems fine, but it's now 22:06, so i will do deep testing tomorrow
By: Joshua C. Colp (jcolp) 2009-03-30 08:19:25

How have things been going?
By: afu (afu) 2009-03-30 09:16:20

till now no problems found, good job!

only thin is this warning:
WARNING[30388]: res_config_mysql.c:360 update_mysql: MySQL RealTime: Failed to query database. Check debug for more info.

would it be enough to change the channel_sip.* to the release version?
By: Digium Subversion (svnbot) 2009-03-30 09:35:49

Repository: asterisk
Revision: 184947

U   branches/1.4/channels/chan_sip.c

------------------------------------------------------------------------
r184947 | file | 2009-03-30 09:35:48 -0500 (Mon, 30 Mar 2009) | 14 lines

Improve our handling of T38 in the initial INVITE from a device.

We now answer with matching media streams to what is requested. If an INVITE
is received with both a T38 and RTP media stream this means we answer with both.
For any outgoing calls created as a result of this inbound one no T38 is requested
in the initial INVITE. Instead if we start receiving udptl packets we trigger a
reinvite on the outbound side.

(closes issue ASTERISK-11843)
Reported by: marsosa
Tested by: pinga-fogo, okrief, file, afu

Review: http://reviewboard.digium.com/r/208/

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=184947
By: Digium Subversion (svnbot) 2009-03-30 09:37:48

Repository: asterisk
Revision: 184948

_U  trunk/
U   trunk/channels/chan_sip.c

------------------------------------------------------------------------
r184948 | file | 2009-03-30 09:37:47 -0500 (Mon, 30 Mar 2009) | 21 lines

Merged revisions 184947 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
 r184947 | file | 2009-03-30 11:35:47 -0300 (Mon, 30 Mar 2009) | 14 lines
 
 Improve our handling of T38 in the initial INVITE from a device.
 
 We now answer with matching media streams to what is requested. If an INVITE
 is received with both a T38 and RTP media stream this means we answer with both.
 For any outgoing calls created as a result of this inbound one no T38 is requested
 in the initial INVITE. Instead if we start receiving udptl packets we trigger a
 reinvite on the outbound side.
 
 (closes issue ASTERISK-11843)
 Reported by: marsosa
 Tested by: pinga-fogo, okrief, file, afu
 
 Review: http://reviewboard.digium.com/r/208/
........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=184948
By: Digium Subversion (svnbot) 2009-03-30 09:39:33

Repository: asterisk
Revision: 184949

_U  branches/1.6.0/
U   branches/1.6.0/channels/chan_sip.c

------------------------------------------------------------------------
r184949 | file | 2009-03-30 09:39:32 -0500 (Mon, 30 Mar 2009) | 28 lines

Merged revisions 184948 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
 r184948 | file | 2009-03-30 11:37:47 -0300 (Mon, 30 Mar 2009) | 21 lines
 
 Merged revisions 184947 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.4
 
 ........
   r184947 | file | 2009-03-30 11:35:47 -0300 (Mon, 30 Mar 2009) | 14 lines
   
   Improve our handling of T38 in the initial INVITE from a device.
   
   We now answer with matching media streams to what is requested. If an INVITE
   is received with both a T38 and RTP media stream this means we answer with both.
   For any outgoing calls created as a result of this inbound one no T38 is requested
   in the initial INVITE. Instead if we start receiving udptl packets we trigger a
   reinvite on the outbound side.
   
   (closes issue ASTERISK-11843)
   Reported by: marsosa
   Tested by: pinga-fogo, okrief, file, afu
   
   Review: http://reviewboard.digium.com/r/208/
 ........
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=184949
By: Digium Subversion (svnbot) 2009-03-30 09:41:14

Repository: asterisk
Revision: 184950

_U  branches/1.6.1/
U   branches/1.6.1/channels/chan_sip.c

------------------------------------------------------------------------
r184950 | file | 2009-03-30 09:41:13 -0500 (Mon, 30 Mar 2009) | 28 lines

Merged revisions 184948 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
 r184948 | file | 2009-03-30 11:37:47 -0300 (Mon, 30 Mar 2009) | 21 lines
 
 Merged revisions 184947 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.4
 
 ........
   r184947 | file | 2009-03-30 11:35:47 -0300 (Mon, 30 Mar 2009) | 14 lines
   
   Improve our handling of T38 in the initial INVITE from a device.
   
   We now answer with matching media streams to what is requested. If an INVITE
   is received with both a T38 and RTP media stream this means we answer with both.
   For any outgoing calls created as a result of this inbound one no T38 is requested
   in the initial INVITE. Instead if we start receiving udptl packets we trigger a
   reinvite on the outbound side.
   
   (closes issue ASTERISK-11843)
   Reported by: marsosa
   Tested by: pinga-fogo, okrief, file, afu
   
   Review: http://reviewboard.digium.com/r/208/
 ........
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=184950
By: Digium Subversion (svnbot) 2009-03-30 09:43:13

Repository: asterisk
Revision: 184951

_U  branches/1.6.2/
U   branches/1.6.2/channels/chan_sip.c

------------------------------------------------------------------------
r184951 | file | 2009-03-30 09:43:12 -0500 (Mon, 30 Mar 2009) | 28 lines

Merged revisions 184948 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
 r184948 | file | 2009-03-30 11:37:47 -0300 (Mon, 30 Mar 2009) | 21 lines
 
 Merged revisions 184947 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.4
 
 ........
   r184947 | file | 2009-03-30 11:35:47 -0300 (Mon, 30 Mar 2009) | 14 lines
   
   Improve our handling of T38 in the initial INVITE from a device.
   
   We now answer with matching media streams to what is requested. If an INVITE
   is received with both a T38 and RTP media stream this means we answer with both.
   For any outgoing calls created as a result of this inbound one no T38 is requested
   in the initial INVITE. Instead if we start receiving udptl packets we trigger a
   reinvite on the outbound side.
   
   (closes issue ASTERISK-11843)
   Reported by: marsosa
   Tested by: pinga-fogo, okrief, file, afu
   
   Review: http://reviewboard.digium.com/r/208/
 ........
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=184951