Henryk Brys
2004-Oct-03 16:06 UTC
[Asterisk-Users] Tenor AS cancells calls through Asterisk
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@XXX.XXX.154.228:5080>;tag=c0a8010c-135 To: <sip:607290950@XXX.XXX.200.242>;tag=as6d0f8240 Call-ID: call-00DA512B-97BE-D311-000C-43@XX.XX.154.228 CSeq: 2 INVITE User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER Contact: <sip:607290950@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
Possibly Parallel Threads
Wisdom of the Ancients
