T 38 Outbound Fax Problem (bearer capability not implemented (65) )

[Fikri FIRAT]

Hi all,

We don't have any issues with inbound fax transfer but when the client tries to send a document to an outbound number, right after the receiver hears the fax tone, the call drops. We use SIP trunk. We see the following debug messages :

192C : 730 412070610ms.616 +7560 +13420 pid:75 Answer no_from_info

dur 00:00:05 tx:1/160 rx:295/46702 41  (bearer capability not implemented (65))

IP 10.145.2.145:56858 SRTP: off rtt:3312ms pl:2460/0ms lost:0/1/0 delay:65/65/75ms g711ulaw TextRelay: off

  media inactive detected:n media contrl rcvd:n/a timestamp:n/a

  long duration call detected:n long dur callduration :n/a timestamp:n/a

192C : 731 412070700ms.617 +7470 +13420 pid:12 Originate 002124784075

dur 00:00:05 tx:292/49056 rx:353/56480 41  (bearer capability not implemented (65))

Telephony 7/0:D (731) [7/0.1] tx:13320/7130/0ms g711ulaw noise:-84dBm acom:6dBm

  long duration call detected:n long dur callduration :n/a timestamp:n/a

[paolo bevilacqua]

Take the complete SIP trace.

[Fikri FIRAT]

Complete SIP trace is attached.

[paolo bevilacqua]

This appears to be the problem:

Nov 29 14:12:09.993: //772/CEDD229087B6/SIP/Info/sipSPIValidateConnectionAddress: dead stream since destination port is 0 for the m-line : 2

Nov 29 14:12:09.993: //772/CEDD229087B6/SIP/Error/sipSPIDoMediaNegotiation:

no valid fax or audio streams

Nov 29 14:12:09.993: //772/CEDD229087B6/SIP/Error/ccsip_api_response_answer: Media Negotiation failure in 200 OK

Nov 29 14:12:09.993: //772/CEDD229087B6/SIP/Info/ccsip_set_cc_cause_for_spi_err: Categorized cause:65, category:278

Which exact IOS are you using ? Do you have "voip rtp send-recv" ? This latter actually may not be need, just a wild guess.

[rajesh.kumar]

Hi

Thanks a lot

simply remove pcma and leave pcmu on rightfax is resolved the issue.

Rgds

Rajesh

[Ayodeji Okanlawon]

In the logs there are a few things that I see

1. I do not see the negotiation between the SIP gateway and your ITSP provider. When the CUBE receives and invite from the dialogic, It has to send an outbound invite to the provider....If you are using a sip dial-peer then we must see this

2. The audio part of the call didnt agree on any particular codec for the call. The Audio logic sends and invite with

Invite received from dialogic

Received:
INVITE sip:06576150@10.112.45.80 SIP/2.0
From: 3352959 <3352959>;tag=8af2e40-8882720a-13c4-55013-f333-79206b09-f333
To: <06576150>
Call-ID: 827c098-8882720a-13c4-55013-f333-442e35b3-f333
CSeq: 1 INVITE
Via: SIP/2.0/UDP 10.114.130.136:5060;branch=z9hG4bK-f333-3b6023f-4726b75e
Contact: <10.114.130.136:5060>
Max-Forwards: 70
User-Agent: Brktsip/6.5.2B5 (Dialogic)
Content-Type: application/sdp
Content-Length: 224

v=0
o=- 2209052474 0762116000 IN IP4 10.114.130.136
s=no_session_name
t=0 0
m=audio 56088 RTP/AVP 0----------codec g711ulaw advertised
c=IN IP4 10.114.130.136
a=rtpmap:0 pcmu/8000

m=audio 56088 RTP/AVP 8---------codec g711alaw advertised
c=IN IP4 10.114.130.136
a=rtpmap:8 pcma/8000

By the time the CUBE sends a 200 okay back to dialogic..it just advertises the same set of codecs.

ent:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.114.130.136:5060;branch=z9hG4bK-f333-3b6023f-4726b75e
From: 3352959 <3352959>;tag=8af2e40-8882720a-13c4-55013-f333-79206b09-f333
To: <06576150>;tag=18FD75F4-5FB
Date: Thu, 29 Nov 2012 12:11:58 GMT
Call-ID: 827c098-8882720a-13c4-55013-f333-442e35b3-f333
CSeq: 1 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Remote-Party-ID: <6576150>;party=called;screen=no;privacy=off
Contact: <06576150>
Supported: replaces
Supported: sdp-anat
Server: Cisco-SIPGateway/IOS-12.x
Supported: timer
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 245

v=0
o=CiscoSystemsSIP-GW-UserAgent 5073 2568 IN IP4 10.112.45.80
s=SIP Call
c=IN IP4 10.112.45.80
t=0 0
m=audio 20044 RTP/AVP 0
c=IN IP4 10.112.45.80
a=rtpmap:0 PCMU/8000

m=audio 0 RTP/AVP 8
c=IN IP4 10.112.45.80
a=rtpmap:8 PCMA/8000

Under normal circumstances, th CUBE should respond with the codec noegotiated with the provider. either g711u or g711a. So we need to see whats happening on the leg of your ITSP..This is not normal..and thats why we see two media streams for a single call..

Please rate all useful posts

"'Nature is too thin a screen, the glory of the omnipresent God bursts through it everywhere"-Ralph Waldo Emerson

[Fikri FIRAT]

The following is what I suspected :

Nov 29 14:11:58.521: //772/CEDD229087B6/SIP/Error/sipSPISearchForForkingCodec: Non-conforming codec (g711alaw) in stream 2; the stream will be rejected.

Nov 29 14:11:58.521: //772/CEDD229087B6/SIP/Error/sipSPICheckForkedStreamCriteria: Invalid mainStream (g711ulaw) forking (g711alaw) codec combination

So it appears there's a mismatch between the two legs, so how to fix this?

[Jorge Armijo · Accepted solution]

Hi Guys,

I found this defect: CSCsi10343

http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCsi10343

T.38 negot fails if two m lines are sent in the offer from 3rd part serv.

Hope this helps

--

Jorge Armijo

[Ayodeji Okanlawon]

Jorge, +5

I though that the m-line looks a bit strange..Never seen two m lines been sent before. Good find for us.

The work around is as follows: You  need to configure dialogic to send only one codec.

Symptom:

Fax calls from right fax fail using T38. Call tears down right after the T38 negotiation completes.

Conditions:

Rightfax sends 2 M lines in SDP.

Workaround:

Configure right fax to use only 1 codec. If configured for both PCMU and PCMA (g711ulaw and g711alaw) it will send 2 M lines (incorrectly).

Generic steps for changing rightfax:

In the configuration tool, in advanced mode, highlight the IP call control stack that you are using in the left pane, ( SIP or H323 )

Click on RTP parameters in the right pane, there is a drop down for the RTP

codec list. simply remove pcma and leave pcmu.

make sure that there is no spaces after pcmu.

Save and then apply. SDP offering after this should only reflect pcmu offering.

Symptom:Fax calls from right fax fail using T38. Call tears down right after the T38 negotiation completes.

Conditions:

Rightfax sends 2 M lines in SDP.

Workaround:

Configure right fax to use only 1 codec. If configured for both PCMU and PCMA (g711ulaw and g711alaw) it will send 2 M lines (incorrectly).

Generic steps for changing rightfax:

In the configuration tool, in advanced mode, highlight the IP call control stack that you are using in the left pane, ( SIP or H323 )

Click on RTP parameters in the right pane, there is a drop down for the RTP

codec list. simply remove pcma and leave pcmu.

make sure that there is no spaces after pcmu.

Save and then apply. SDP offering after this should only reflect pcmu offering.

Please rate all useful posts

"'Nature is too thin a screen, the glory of the omnipresent God bursts through it everywhere"-Ralph Waldo Emerson

[Fikri FIRAT]

First of all, thanks for quick and helpful replies, but still the problem exists.

The IOS version is "Cisco IOS Software, 5400 Software  Version 15.1(2)T4"

We changed the config so that the router would use only one codec but still we can't send outbound fax, here is some relevant configurations from the gateway :

!

voice service voip

allow-connections h323 to h323

allow-connections h323 to sip

allow-connections sip to h323

allow-connections sip to sip

fax protocol t38 version 0 ls-redundancy 5 hs-redundancy 2 fallback none

no fax-relay sg3-to-g3

sip

  bind control source-interface GigabitEthernet0/0

  bind media source-interface GigabitEthernet0/0

!

voice class codec 1

codec preference 1 g711ulaw

codec preference 2 g729r8

!

voice class codec 99

codec preference 1 g711ulaw

!

rule 1 /^.*\(3352950$\)$/ /2950/

rule 2 /^.*\(3352951$\)$/ /2951/

rule 3 /^.*\(3352952$\)$/ /3002/

!

voice translation-rule 2

rule 1 /^90212/ /0/

rule 2 /^90/ /00/

rule 3 /\(^[2-8]......$\)/ /00212\1/

rule 4 /^/ /0/

!

voice translation-rule 3

rule 1 /^3001$/ /2123352950/

rule 2 /^3002$/ /2123352951/

!

voice translation-rule 10

rule 1 /^$/ /2123352959/

!

!

voice translation-profile CIKIS

translate calling 3

!

voice translation-profile FAX

translate calling 10

!

!

dial-peer voice 12 pots

trunkgroup PRI

translation-profile incoming PRI

destination-pattern 0T

progress_ind setup enable 3

progress_ind alert enable 8

incoming called-number .

direct-inward-dial

dial-peer voice 75 voip

translation-profile outgoing FAX

huntstop

destination-pattern 3352959

session protocol sipv2

session target ipv4:10.114.130.136

session transport udp

incoming called-number .

voice-class codec 99 

fax-relay ecm disable

fax protocol t38 version 0 ls-redundancy 2 hs-redundancy 0 fallback none

!

[Ayodeji Okanlawon]

This config does not show the dial-peer pointing to your sip provider. Why not send the full config.

Please send the full config.

Do another test call and send only

debug ccsip messages.

Please rate all useful posts

"'Nature is too thin a screen, the glory of the omnipresent God bursts through it everywhere"-Ralph Waldo Emerson

[Fikri FIRAT]

Full configuration and "debug ccip messages" output is attached.

[Ayodeji Okanlawon]

The Dialogic device is still sending tow m lines...Please cnfigure only to use one codec.

v=0

o=- 2209058953 0052419000 IN IP4 10.114.130.136

s=no_session_name

t=0 0

m=audio 56160 RTP/AVP 0

c=IN IP4 10.114.130.136

a=rtpmap:0 pcmu/8000

m=audio 56160 RTP/AVP 8

c=IN IP4 10.114.130.136

a=rtpmap:8 pcma/8000

Please rate all useful posts

"'Nature is too thin a screen, the glory of the omnipresent God bursts through it everywhere"-Ralph Waldo Emerson

[Ayodeji Okanlawon]

I can see also that this call is not going over a SIP trunk...

The called fax number is 06576150

The dial-peer that is matched is this

dial-peer voice 12 pots

trunkgroup PRI

translation-profile incoming PRI

destination-pattern 0T

progress_ind setup enable 3

progress_ind alert enable 8

incoming called-number .

direct-inward-dial

So its not going over the sip trunk..Just to let you know

Please rate all useful posts

"'Nature is too thin a screen, the glory of the omnipresent God bursts through it everywhere"-Ralph Waldo Emerson

[Fikri FIRAT]

Hi all,

After the codecs are changed in the location's config, the issue has been resolved, we really appreciate your help very much, thank you all, have a nice day!

Regards,

Fikri