[Home]

Summary:ASTERISK-05160: Incorrect rtp protocol map for telephone event for native bridge between 2 SIP devices.
Reporter:Sergey Okhapkin (sokhapkin)Labels:
Date Opened:2005-09-27 08:27:55Date Closed:2005-09-28 23:55:14
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/RTP
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) log.txt
Description:I have a pingtel phone (10.10.30.217) connected to asterisk 1.2_beta1 server (10.10.30.168). Extension 100 forwards the call to another asterisk server at sokhapkin.com (24.149.137.157,192.168.2.161). Pingtel sends rtpmap to map telephone event to protocol 98 instead of standard 101.

Here is the event sequence (I'll skip all SIP headers except for important ones):

<-- SIP read from 10.10.30.217:2784:
INVITE sip:100@10.10.30.168 SIP/2.0
a=rtpmap:98 telephone-event/8000/1
-------------------
Transmitting (no NAT) to 10.10.30.217:5060:
SIP/2.0 100 Trying

   -- Executing SIPDtmfMode("SIP/6825-1161", "rfc2833") in new stack
   -- Executing Dial("SIP/6825-1161", "SIP/100@sokhapkin.com|20") in new stack
-------------------
Reliably Transmitting (no NAT) to 24.149.137.157:5060:
INVITE sip:100@sokhapkin.com SIP/2.0
a=rtpmap:101 telephone-event/8000
----------------
<-- SIP read from 192.168.2.161:5060:
SIP/2.0 100 Trying
----------------
<-- SIP read from 192.168.2.161:5060:
SIP/2.0 200 OK
a=rtpmap:101 telephone-event/8000
----------------
Transmitting (no NAT) to 24.149.137.157:5060:
ACK sip:100@24.149.137.157 SIP/2.0
-----------------
Reliably Transmitting (no NAT) to 10.10.30.217:5060:
SIP/2.0 200 OK
a=rtpmap:98 telephone-event/8000
-----------------
   -- Attempting native bridge of SIP/6825-1161 and SIP/sokhapkin.com-39ce
set_destination: Parsing <sip:100@24.149.137.157> for address/port to send to
set_destination: set destination to 24.149.137.157, port 5060
-----------------
Reliably Transmitting (no NAT) to 24.149.137.157:5060:
INVITE sip:100@24.149.137.157 SIP/2.0
o=root 16698 16699 IN IP4 10.10.30.217
a=rtpmap:101 telephone-event/8000

This is already incorrect! Pingtel reported phone event on protocol 98 but non 101!

---------------
<-- SIP read from 192.168.2.161:5060:
SIP/2.0 200 OK
a=rtpmap:101 telephone-event/8000
---------------
Transmitting (no NAT) to 24.149.137.157:5060:
ACK sip:100@24.149.137.157 SIP/2.0
---------------
<-- SIP read from 10.10.30.217:2784:
ACK sip:100@10.10.30.168 SIP/2.0
---------------
Reliably Transmitting (no NAT) to 10.10.30.217:5060:
INVITE sip:6825@10.10.30.217 SIP/2.0
o=root 16698 16699 IN IP4 24.149.137.157
a=rtpmap:98 telephone-event/8000
---------------
<-- SIP read from 10.10.30.217:2784:
SIP/2.0 200 OK
a=rtpmap:98 telephone-event/8000/1
---------------
Transmitting (no NAT) to 10.10.30.217:5060:
ACK sip:6825@10.10.30.217 SIP/2.0

Oops... RTP map for native bridge set up incorrectly, asterisk server on 24.149.137.157 can't recognize dtmf tones and complaints:

Sep 27 08:44:59 NOTICE[9960]: Unknown RTP codec 98 received                    
Sep 27 08:44:59 NOTICE[9960]: Unknown RTP codec 98 received                    
Sep 27 08:44:59 NOTICE[9960]: Unknown RTP codec 98 received                    
Sep 27 08:44:59 NOTICE[9960]: Unknown RTP codec 98 received                    
Sep 27 08:44:59 NOTICE[9960]: Unknown RTP codec 98 received                    
Sep 27 08:44:59 NOTICE[9960]: Unknown RTP codec 98 received                    
Sep 27 08:44:59 NOTICE[9960]: Unknown RTP codec 98 received                    
Sep 27 08:44:59 NOTICE[9960]: Unknown RTP codec 98 received                    
etc.



****** ADDITIONAL INFORMATION ******

Attached is the full asterisk log of the SIP session.
Comments:By: Brian West (bkw918) 2005-09-27 09:05:39

Actually the native bridge is going to fail from what I see becaue you have one behind nat and the other not?  If I read this correctly a reinvite can't take place.

/b
By: Sergey Okhapkin (sokhapkin) 2005-09-27 09:15:02

The bridge should not fail - all IP addresses are on the same VPN and can talk to each other. The voice packets are running fine, only DTMS packets are not recognized.
By: Mark Spencer (markster) 2005-09-27 10:37:03

This is really an ugly design flaw within SIP.  Our choices here can only get us asymptotically closer to a workable solution.

Of course the best solution is to make sure everything uses the same RTP map.  That's the *only* solution that will work in all cases.  <rant>The whole dynamic mapping concept is a useless disaster.</rant>

Alternative #1: Reinvite with the desired mapping of the other side.  This sounds tempting, but if we have already invited with a different assignment for 98, for example, we *cannot* issue a new invite with 98 used for something new.  It's simply not permitted.  I do not know how many devices will react properly if we reinvite with a different mapping than originally specified.  This would be the easier (relatively speaking) to implement.

Alternative #2: Send initial invite with the desired mapping of the *calling* channel.  While this *sounds* like it would always work, it really only works with traditional call flows.  This method cannot allow *arbitrary* SIP connections to talk to one another, and requires that one be based on the result of the first.  Of course, there exists no way in SIP to have arbitrary SIP channels to deterministically talk to one another without a session border controller anyway.
By: Kevin P. Fleming (kpfleming) 2005-09-28 23:51:38

In other words... Asterisk cannot solve this problem. If you want these devices to be able to talk directly to each other, you will either have to configure them to use the same RTP mappings, or have them talk through a proxy (not a back to back user agent).