[Asterisk-Users] Tenor AS cancells calls through Asterisk

Sun Oct 3 16:06:50 MST 2004

Hello,

Maybe some of you tried the SIP support recently introduced by Quintum
in their AS devices.

I have one Asterisk machine connected to PSTN via E1. It works properly.
On the other side I got an ADSL line, with NAT and few devices behind it,
like computer with X-Lite client installed or mentioned Quintum device.
It works great - calls initiated from there are OK, as well as PSTN
originated ones. So it lookes like the network configuration is OK.
When I follow the instructions from Quintum's howto on making a first
SIP call with Tenor AS - it works. But it doesn't work when I'm trying
to use my Asterisk based gateway. Tenor registers on my Asterisk
properly. While debugging the SIP traffic on both sides I see normal SIP
conversation trying to call a PSTN number from Tenor attached phone.
But when it comes to exchange the RTP traffic (for voice or progress
tone), something goes wrong. Tenor receives a message like that from *:

 SIP/2.0 183 Session Progress
 Via: SIP/2.0/UDP XXX.XXX.154.228:5080;branch=z9hG4bK-tenor-c0a8-010c-017b
 From: <sip:1013 at XXX.XXX.154.228:5080>;tag=c0a8010c-135
 To: <sip:607290950 at XXX.XXX.200.242>;tag=as6d0f8240
 Call-ID: call-00DA512B-97BE-D311-000C-43 at XX.XX.154.228
 CSeq: 2 INVITE
 User-Agent: Asterisk PBX
 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER
 Contact: <sip:607290950 at XXX.XXX.200.242>
 Content-Type: application/sdp
 Content-Length: 194

 v=0
 o=root 3722 3722 IN IP4 XXX.XXX.200.242
 s=session
 c=IN IP4 XXX.XXX.200.242
 t=0 0
 m=audio 15078 RTP/AVP 101
 a=rtpmap:101 telephone-event/8000
 a=fmtp:101 0-16
 a=silenceSupp:off - - - -

and this is the place when Tenor refuses to cooperate. Its call handler
somehow figures, that provided media list is wrong:

ch     |01/01| 2000/01/01|08:57:52:985 sip[0/0]: chsipTG: SIP CallID
:call-00DA512B-97BE-D311-000C-43
ch     |01/01| 2000/01/01|08:57:52:985 sip[0/0]: SipProgress rcvd at
SipTermCall
ch     |01/01| 2000/01/01|08:57:52:985 sip[64/0]: tsipcall:RcvProgress
ch     |01/01| 2000/01/01|08:57:53:000 checkIPMedia called
pMedia=0x96123164
ch     |01/01| 2000/01/01|08:57:53:000 CheckIPMedia Media #: 0 Type: 2
ch     |01/01| 2000/01/01|08:57:53:000 VerifySipMedia Inc Media Type: 38
FPP723: 101 FPPxxx: 101
ch     |01/01| 2000/01/01|08:57:53:000 CheckIPMedia Media #: 1 Type: 2
ch     |01/01| 2000/01/01|08:57:53:000 VerifySipMedia Inc Media Type: 38
FPP723: 101 FPPxxx: 101
ch     |01/01| 2000/01/01|08:57:53:000 CheckIPMedia Media #: 2 Type: 16
ch     |01/01| 2000/01/01|08:57:53:000 VerifySipMedia Inc Media Type: 38
FPP723: 101 FPPxxx: 101
ch     |01/01| 2000/01/01|08:57:53:000 CheckIPMedia Media #: 3 Type: 16
ch     |01/01| 2000/01/01|08:57:53:000 VerifySipMedia Inc Media Type: 38
FPP723: 101 FPPxxx: 101
ch     |01/01| 2000/01/01|08:57:53:000 CheckIPMedia Media #: 4 Type: 12
ch     |01/01| 2000/01/01|08:57:53:000 VerifySipMedia Inc Media Type: 38
FPP723: 101 FPPxxx: 101
ch     |01/01| 2000/01/01|08:57:53:000 CheckIPMedia Media #: 5 Type: 12
ch     |01/01| 2000/01/01|08:57:53:000 VerifySipMedia Inc Media Type: 38
FPP723: 101 FPPxxx: 101
ch     |01/01| 2000/01/01|08:57:53:000 CheckIPMedia Media #: 6 Type: 11
ch     |01/01| 2000/01/01|08:57:53:000 VerifySipMedia Inc Media Type: 38
FPP723: 101 FPPxxx: 101
ch     |01/01| 2000/01/01|08:57:53:000 CheckIPMedia Media #: 7 Type: 11
ch     |01/01| 2000/01/01|08:57:53:005 VerifySipMedia Inc Media Type: 38
FPP723: 101 FPPxxx: 101
ch     |01/01| 2000/01/01|08:57:53:005 checkIpMedia::[64] Incompatible
media list received: 8.
ch     |01/01| 2000/01/01|08:57:53:005 TBCSM[64]: abortCall.
ch     |01/01| 2000/01/01|08:57:53:005 OBCSM[64]: Release from
peer=0x963277e4 cause=0x29 redir=.
ch     |01/01| 2000/01/01|08:57:53:005 TBCSM [64]: Release complete from
peer=0x963267d8.
ch     |01/01| 2000/01/01|08:57:53:005 OBCSM[64]: Trying another route.
ch     |01/01| 2000/01/01|08:57:53:005 Route response [64]: result=0
cause=34.
ch     |01/01| 2000/01/01|08:57:53:005 CallInfo[64]: fail event. cause=41
legno=0.

ch     |01/01| 2000/01/01|08:57:53:005 CallInfo[64]: sendFailed leg=0 0.
ch     |01/01| 2000/01/01|08:57:53:005 tsi    connect: 000 1009 10
ch     |01/01| 2000/01/01|08:57:53:055 CasManager: [2,0,1,1] Sent message
to cas: Alert.
ch     |01/01| 2000/01/01|08:57:53:055 sip[64/0]:
tsipcall:stackSendRelease
ch     |01/01| 2000/01/01|08:57:53:065 sent message to sip: msg=4; ua=1
ch     |01/01| 2000/01/01|08:57:53:065 sip[0/0]: sipTG::term
releaseCall:remove call from list

So, as I suppose, something is wrong with the codecs configuration. But I
tried to force g729, ulaw and alaw on Asterisk, and on Tenor, so there
were many times, when they SHOULD match. But they don't and Tenor sends
CANCEL messages to the * right after that check.

As I mentioned before, Quintum gives access to their test gateway for the
first call, which works good. It delivers following SDP for comparison:

sproto |01/01| 2000/01/01|08:09:27:930 v=0
sproto |01/01| 2000/01/01|08:09:27:930 o=Quintum 392 24 IN IP4
208.226.140.40
sproto |01/01| 2000/01/01|08:09:27:930 s=VoipCall
sproto |01/01| 2000/01/01|08:09:27:930 c=IN IP4 208.226.140.40
sproto |01/01| 2000/01/01|08:09:27:930 t=0 0
sproto |01/01| 2000/01/01|08:09:27:930 m=audio 10656 RTP/AVP 18 101
sproto |01/01| 2000/01/01|08:09:27:930 c=IN IP4 208.226.140.40
sproto |01/01| 2000/01/01|08:09:27:930 a=rtpmap:18 g729/8000/1
sproto |01/01| 2000/01/01|08:09:27:930 a=rtpmap:101 telephone-event/8000/1

Any ideas?

(Of course I run up-to-date asterisk version, as well as last Tenor
firmware)

--
Henryk Brys