[Home]

Summary:ASTERISK-11180: RTPs not sent to the correct IP
Reporter:David Villasmil (davidcsi)Labels:
Date Opened:2008-01-08 15:25:38.000-0600Date Closed:2011-06-07 14:02:40
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/RTP
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:When outgoing call to a gateway with 2 IPs, 1 for signalling and 1 or more for RTPs, asterisk sends the RTPs to the signalling IP ignoring the media connection IP.

The session progress says its RTP IP is .20, so does Ringing. Though on 200 OK it says it is .18

Why would Asterisk change the RTP IP because of an ackwoledge?



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

192.168.1.20 - Asterisk
192.168.1.18 - GW (signalling)
192.168.1.28 - GW (RTP)
192.168.1.180 - UA

UA->ASTERISK->GW

Trace from ethereal:

192.168.1.180 -> 192.168.1.28  SIP/SDP Request: INVITE sip:915425193@192.168.1.28;transport=udp, with session description
192.168.1.28 -> 192.168.1.180 SIP Status: 100 Trying
192.168.1.28 -> 192.168.1.18  SIP/SDP Request: INVITE sip:34915425193@192.168.1.18, with session description
192.168.1.18 -> 192.168.1.28  SIP Status: 100 Trying
192.168.1.18 -> 192.168.1.28  SIP/SDP Status: 183 Session Progress, with session description
192.168.1.28 -> 192.168.1.180 SIP/SDP Status: 183 Session Progress, with session description
192.168.1.18 -> 192.168.1.28  SIP/SDP Status: 180 Ringing, with session description
192.168.1.28 -> 192.168.1.180 SIP Status: 180 Ringing
.
.
.
192.168.1.180 -> 192.168.1.28  UDP Source port: 1024  Destination port: 10250
192.168.1.28 -> 192.168.1.18  UDP Source port: 18828  Destination port: 5590
192.168.1.20 -> 192.168.1.28  UDP Source port: 5590  Destination port: 18828
192.168.1.28 -> 192.168.1.180 UDP Source port: 10250  Destination port: 1024
192.168.1.28 -> 192.168.1.180 UDP Source port: 10250  Destination port: 1024
192.168.1.180 -> 192.168.1.28  UDP Source port: 1024  Destination port: 10250
192.168.1.28 -> 192.168.1.18  UDP Source port: 18828  Destination port: 5590
192.168.1.180 -> 192.168.1.28  UDP Source port: 1024  Destination port: 10250
192.168.1.28 -> 192.168.1.18  UDP Source port: 18828  Destination port: 5590
192.168.1.20 -> 192.168.1.28  UDP Source port: 5590  Destination port: 18828

Asterisk Trace:

   -- Executing Dial("SIP/7059998-0819a280", "SIP/34915425193@192.168.1.18|60") in new stack
We're at 192.168.1.28 port 13216
Adding codec 0x100 (g729) to SDP
Adding codec 0x400 (ilbc) to SDP
Adding codec 0x2 (gsm) to SDP
Adding codec 0x4 (ulaw) to SDP
Adding codec 0x8 (alaw) to SDP
Adding non-codec 0x1 (telephone-event) to SDP
13 headers, 15 lines
Reliably Transmitting (no NAT) to 192.168.1.18:5060:
INVITE sip:34915425193@192.168.1.18 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.28:5060;branch=z9hG4bK0a2c4b20;rport
From: "7059998" <sip:7059998@192.168.1.28>;tag=as2e3ad229
To: <sip:34915425193@192.168.1.18>
Contact: <sip:7059998@192.168.1.28>
Call-ID: 31de19eb444d6efe73f409e40b24fd10@192.168.1.28
CSeq: 102 INVITE
User-Agent: Asterisk PBX
Max-Forwards: 70
Date: Tue, 08 Jan 2008 21:17:05 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Content-Type: application/sdp
Content-Length: 334

v=0
o=root 11399 11399 IN IP4 192.168.1.28
s=session
c=IN IP4 192.168.1.28
t=0 0
m=audio 13216 RTP/AVP 18 97 3 0 8 101
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:97 iLBC/8000
a=rtpmap:3 GSM/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -

---
   -- Called 34915425193@192.168.1.18
fwTS*CLI>
<-- SIP read from 192.168.1.18:1113:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.1.28:5060;branch=z9hG4bK0a2c4b20;rport=5060;received=192.168.1.28
From: "7059998" <sip:7059998@192.168.1.28>;tag=as2e3ad229
To: <sip:34915425193@192.168.1.18>
Call-ID: 31de19eb444d6efe73f409e40b24fd10@192.168.1.28
CSeq: 102 INVITE
Content-Length:     0


--- (7 headers 0 lines) ---
fwTS*CLI>
<-- SIP read from 192.168.1.18:1113:
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP 192.168.1.28:5060;branch=z9hG4bK0a2c4b20;rport=5060;received=192.168.1.28
From: "7059998" <sip:7059998@192.168.1.28>;tag=as2e3ad229
To: <sip:34915425193@192.168.1.18>;tag=00E0F51004DB29F29AC8000004BA
Call-ID: 31de19eb444d6efe73f409e40b24fd10@192.168.1.28
CSeq: 102 INVITE
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, INFO, REFER, NOTIFY, SUBSCRIBE, UPDATE
Content-Type: application/sdp
Content-Length:   200

v=0
o=- 70376519700004744 1 IN IP4 192.168.1.18
s=session
c=IN IP4 192.168.1.20
t=0 0
m=audio 6090 RTP/AVP 18 101
a=rtpmap:18 G729/8000
a=ptime:40
a=sendrecv
a=rtpmap:101 telephone-event/8000

--- (9 headers 10 lines) ---
Found RTP audio format 18
Found RTP audio format 101
Peer audio RTP is at port 192.168.1.20:6090
Found description format G729
Found description format telephone-event
Capabilities: us - 0x50e (gsm|ulaw|alaw|g729|ilbc), peer - audio=0x100 (g729)/video=0x0 (nothing), combined - 0x100 (g729)
Non-codec capabilities: us - 0x1 (telephone-event), peer - 0x1 (telephone-event), combined - 0x1 (telephone-event)
   -- SIP/192.168.1.18-08192bf0 is making progress passing it to SIP/7059998-0819a280
fwTS*CLI>
<-- SIP read from 192.168.1.18:1113:
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 192.168.1.28:5060;branch=z9hG4bK0a2c4b20;rport=5060;received=192.168.1.28
From: "7059998" <sip:7059998@192.168.1.28>;tag=as2e3ad229
To: <sip:34915425193@192.168.1.18>;tag=00E0F51004DB29F29AC8000004BA
Call-ID: 31de19eb444d6efe73f409e40b24fd10@192.168.1.28
CSeq: 102 INVITE
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, INFO, REFER, NOTIFY, SUBSCRIBE, UPDATE
Content-Type: application/sdp
Content-Length:   200

v=0
=- 70376519700004744 2 IN IP4 192.168.1.18
s=session
c=IN IP4 192.168.1.20
t=0 0
m=audio 6090 RTP/AVP 18 101
a=rtpmap:18 G729/8000
a=ptime:40
a=sendrecv
a=rtpmap:101 telephone-event/8000

--- (9 headers 10 lines) ---
Found RTP audio format 18
Found RTP audio format 101
Peer audio RTP is at port 192.168.1.20:6090
Found description format G729
Found description format telephone-event
Capabilities: us - 0x50e (gsm|ulaw|alaw|g729|ilbc), peer - audio=0x100 (g729)/video=0x0 (nothing), combined - 0x100 (g729)
Non-codec capabilities: us - 0x1 (telephone-event), peer - 0x1 (telephone-event), combined - 0x1 (telephone-event)
   -- SIP/192.168.1.18-08192bf0 is ringing
    -- SIP/192.168.1.18-08192bf0 is making progress passing it to SIP/7059998-0819a280
fwTS*CLI>
<-- SIP read from 192.168.1.18:1113:
SIP/2.0 200 Ok
Via: SIP/2.0/UDP 192.168.1.28:5060;branch=z9hG4bK0a2c4b20;rport=5060;received=192.168.1.28
From: "7059998" <sip:7059998@192.168.1.28>;tag=as2e3ad229
To: <sip:34915425193@192.168.1.18>;tag=00E0F51004DB29F29AC8000004BA
Call-ID: 31de19eb444d6efe73f409e40b24fd10@192.168.1.28
CSeq: 102 INVITE
Contact: <sip:192.168.1.18:5060>
Allow-Events: refer
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, INFO, REFER, NOTIFY, SUBSCRIBE, UPDATE
Content-Type: application/sdp
Supported: 100rel, timer, replaces
P-Asserted-Identity: <sip:915425193@192.168.1.18:1113>
Content-Length:   200

v=0
o=- 70376519700004744 3 IN IP4 192.168.1.18
s=session
c=IN IP4 192.168.1.18
t=0 0
m=audio 6090 RTP/AVP 18 101
a=rtpmap:18 G729/8000
a=ptime:40
a=sendrecv
a=rtpmap:101 telephone-event/8000

--- (13 headers 10 lines) ---
Found RTP audio format 18
Found RTP audio format 101
Peer audio RTP is at port 192.168.1.18:6090
Found description format G729
Found description format telephone-event
Capabilities: us - 0x50e (gsm|ulaw|alaw|g729|ilbc), peer - audio=0x100 (g729)/video=0x0 (nothing), combined - 0x100 (g729)
Non-codec capabilities: us - 0x1 (telephone-event), peer - 0x1 (telephone-event), combined - 0x1 (telephone-event)
list_route: hop: <sip:192.168.1.18:5060>
set_destination: Parsing <sip:192.168.1.18:5060> for address/port to send to
set_destination: set destination to 192.168.1.18, port 5060
Transmitting (no NAT) to 192.168.1.18:5060:
ACK sip:192.168.1.18:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.28:5060;branch=z9hG4bK71b57646;rport
From: "7059998" <sip:7059998@192.168.1.28>;tag=as2e3ad229
To: <sip:34915425193@192.168.1.18>;tag=00E0F51004DB29F29AC8000004BA
Contact: <sip:7059998@192.168.1.28>
Call-ID: 31de19eb444d6efe73f409e40b24fd10@192.168.1.28
CSeq: 102 ACK
User-Agent: Asterisk PBX
Max-Forwards: 70
Content-Length: 0


---
   -- SIP/192.168.1.18-08192bf0 answered SIP/7059998-0819a280
    -- Attempting native bridge of SIP/7059998-0819a280 and SIP/192.168.1.18-08192bf0
Scheduling destruction of call '31de19eb444d6efe73f409e40b24fd10@192.168.1.28' in 32000 ms
set_destination: Parsing <sip:192.168.1.18:5060> for address/port to send to
set_destination: set destination to 192.168.1.18, port 5060
Reliably Transmitting (no NAT) to 192.168.1.18:5060:
BYE sip:192.168.1.18:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.28:5060;branch=z9hG4bK78819f16;rport
From: "7059998" <sip:7059998@192.168.1.28>;tag=as2e3ad229
To: <sip:34915425193@192.168.1.18>;tag=00E0F51004DB29F29AC8000004BA
Call-ID: 31de19eb444d6efe73f409e40b24fd10@192.168.1.28
CSeq: 103 BYE
User-Agent: Asterisk PBX
Max-Forwards: 70
Content-Length: 0


---
  == Spawn extension (callshops, 915425193, 1) exited non-zero on 'SIP/7059998-0819a280'
    -- Executing Hangup("SIP/7059998-0819a280", "") in new stack
  == Spawn extension (callshops, h, 1) exited non-zero on 'SIP/7059998-0819a280'
fwTS*CLI>
<-- SIP read from 192.168.1.18:1113:
SIP/2.0 200 Ok
Via: SIP/2.0/UDP 192.168.1.28:5060;branch=z9hG4bK78819f16;rport=5060;received=192.168.1.28
From: "7059998" <sip:7059998@192.168.1.28>;tag=as2e3ad229
To: <sip:34915425193@192.168.1.18>;tag=00E0F51004DB29F29AC8000004BA
Call-ID: 31de19eb444d6efe73f409e40b24fd10@192.168.1.28
CSeq: 103 BYE
Contact: <sip:192.168.1.18:5060>
Content-Length:     0


Comments:By: Joshua C. Colp (jcolp) 2008-01-08 15:31:57.000-0600

This looks perfectly normal. The 200 OK, which is an acknowledge of answer, contains SDP which provides a .18 address where RTP should be sent. Is something actually not working?
By: David Villasmil (davidcsi) 2008-01-08 18:01:03.000-0600

Yes, like i wrote, rtps are being sent to the wrong ip. they should be send to the IP where the "progress" and "ring" came from, not from where the 200 OK was sent.

RESULT?

NO AUDIO caller->calle, of course.


By: Olle Johansson (oej) 2008-01-09 09:24:10.000-0600

No, the 200 OK is a definitive answer and replaces whatever happened before. The 18x is only provisional, meaning that they apply as long as we haven't got a 200 OK.
By: Mark Michelson (mmichelson) 2008-01-09 09:25:41.000-0600

Asterisk is doing exactly what it is told to do. The problem is that the 200 OK should not direct Asterisk to send RTP to the incorrect address. Reconfigure whatever is sending the 200 OK to place the proper IP in its SDP, or just don't send a new SDP on the 200 OK.
By: Joshua C. Colp (jcolp) 2008-01-09 09:28:17.000-0600

Per discussion and notes from oej/putnopvut Asterisk is doing nothing wrong. Please check the whatever is sitting in between Asterisk and the gateway.
By: David Villasmil (davidcsi) 2008-01-21 10:35:04.000-0600

I must reopen this issue, as after looking at ngreps/sip debug, it seems to me asterisk is not extracting the connection info ip right, this is the 200 OK packet comming from the gateway:


===================================================================
and this is the info asterisk "sees":



<-- SIP read from 192.168.1.18:3247:
SIP/2.0 200 Ok
Via: SIP/2.0/UDP 192.168.1.28:5060;branch=z9hG4bK4d5c61dd
From: "7059998" <sip:niai7059998@192.168.1.28>;tag=as3ec98fe9
To: <sip:13058883456@192.168.1.18>;tag=00E0F51004DB308A7EE800001738
Call-ID: 47e962f570da272f3479bfcb0f01b71c@192.168.1.28
CSeq: 102 INVITE
Contact: <sip:192.168.1.18:5060>
Allow-Events: refer
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, INFO, REFER, NOTIFY, SUBSCRIBE, UPDATE
Content-Type: application/sdp
Supported: 100rel, timer, replaces
P-Asserted-Identity: <sip:192.168.1.18>
Privacy: id
Content-Length:   200

v=0
o=- 81438282700007173 3 IN IP4 192.168.1.18
s=session
c=IN IP4 192.168.1.18        <------ THIS IS NOT RIGHT!
t=0 0
m=audio 4380 RTP/AVP 18 101
a=rtpmap:18 G729/8000
a=ptime:40
a=sendrecv
a=rtpmap:101 telephone-event/8000


===================================================================
and this is the actual packet 200 OK:


Session Initiation Protocol
   Status-Line: SIP/2.0 200 Ok
       Status-Code: 200
       [Resent Packet: False]
   Message Header
       Via: SIP/2.0/UDP 192.168.1.28:5060;branch=z9hG4bK4d5c61dd
           Transport: UDP
           Sent-by Address: 192.168.1.28
           Sent-by port: 5060
           Branch: z9hG4bK4d5c61dd
       From: "7059998" <sip:niai7059998@192.168.1.28>;tag=as3ec98fe9
           SIP Display info: "7059998"
           SIP from address: sip:niai7059998@192.168.1.28
           SIP tag: as3ec98fe9
       To: <sip:13058883456@192.168.1.18>;tag=00E0F51004DB308A7EE800001738
           SIP to address: sip:13058883456@192.168.1.18
           SIP tag: 00E0F51004DB308A7EE800001738
       Call-ID: 47e962f570da272f3479bfcb0f01b71c@192.168.1.28
       CSeq: 102 INVITE
           Sequence Number: 102
           Method: INVITE
       Contact: <sip:192.168.1.18:5060>
           Contact Binding: <sip:192.168.1.18:5060>
               URI: <sip:192.168.1.18:5060>
                   SIP contact address: sip:192.168.1.18:5060
       Allow-Events: refer
       Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, INFO, REFER, NOTIFY, SUBSCRIBE, UPDATE
       Content-Type: application/sdp
       Supported: 100rel, timer, replaces
       P-Asserted-Identity: <sip:192.168.1.18>
       Privacy: id
       Content-Length: 200
   Message body
       Session Description Protocol
           Session Description Protocol Version (v): 0
           Owner/Creator, Session Id (o): - 81438282700007173 3 IN IP4 192.168.1.18       <--- THIS IS THE CREATOR'S IP
               Owner Username: -
               Session ID: 81438282700007173
               Session Version: 3
               Owner Network Type: IN
               Owner Address Type: IP4
               Owner Address: 192.168.1.18
           Session Name (s): session
           Connection Information (c): IN IP4 192.168.1.20  
               Connection Network Type: IN
               Connection Address Type: IP4
               Connection Address: 192.168.1.20    <--- THIS IS THE IP!
           Time Description, active time (t): 0 0
               Session Start Time: 0
               Session Stop Time: 0
           Media Description, name and address (m): audio 4380 RTP/AVP 18 101
               Media Type: audio
               Media Port: 4380
               Media Proto: RTP/AVP
               Media Format: ITU-T G.729
               Media Format: 101
           Media Attribute (a): rtpmap:18 G729/8000
               Media Attribute Fieldname: rtpmap
               Media Format: 18
               MIME Type: G729
           Media Attribute (a): ptime:40
               Media Attribute Fieldname: ptime
               Media Attribute Value: 40
           Media Attribute (a): sendrecv
           Media Attribute (a): rtpmap:101 telephone-event/8000
               Media Attribute Fieldname: rtpmap
               Media Format: 101
               MIME Type: telephone-event


By: Joshua C. Colp (jcolp) 2008-01-21 10:47:19.000-0600

Are you running a sip fixup module in the kernel that could be messing with the actual message? The message displayed in sip debug is printed out straight as it is received from the socket before any parsing is done.
By: David Villasmil (davidcsi) 2008-01-21 10:51:33.000-0600

No, I'm not. This is a clean Gentoo
Linux fwTS 2.6.18-gentoo-r3 ASTERISK-3 Wed Nov 29 17:17:40 CET 2006 i686 Intel(R) Pentium(R) D CPU 2.66GHz GenuineIntel GNU/Linux
I haven't messed with the kernel.
The packet printed on the previuos message was captured on the same box.
By: Joshua C. Colp (jcolp) 2008-01-21 10:56:26.000-0600

Attach an lsmod so it can be confirmed please.
By: David Villasmil (davidcsi) 2008-01-21 10:59:02.000-0600

fwTS ~ # lsmod
Module                  Size  Used by
r1000                  15116  0
fwTS ~ #
By: Joshua C. Colp (jcolp) 2008-01-21 11:02:38.000-0600

I'm at a loss then but I am quite certain this is outside the scope of Asterisk... sip debug shows the raw message as received from the socket so the message must have been modified somewhere. What is the setup like? is there a SIP proxy involved, on the same box?
By: David Villasmil (davidcsi) 2008-01-21 11:09:16.000-0600

There's no proxy involved, this is a ngrep executed on the same box:

#
U 2008/01/21 18:08:01.368095 192.168.1.18:1382 -> 192.168.1.28:5060
SIP/2.0 200 Ok
Via: SIP/2.0/UDP 192.168.1.28:5060;branch=z9hG4bK10683fff
From: "7059998" <sip:niai7059998@192.168.1.28>;tag=as2baccc6a
To: <sip:M3ll4m0d4v1d13058883456@192.168.1.18>;tag=00E0F51004DB308DA5D9000010BB
Call-ID: 51397766734aac29320023413ebf4e95@192.168.1.28
CSeq: 102 INVITE
Contact: <sip:192.168.1.18:5060>
Allow-Events: refer
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, INFO, REFER, NOTIFY, SUBSCRIBE, UPDATE
Content-Type: application/sdp
Supported: 100rel, timer, replaces
P-Asserted-Identity: <sip:192.168.1.18>
Privacy: id
Content-Length: 200

v=0
o=- 81458940600001582 2 IN IP4 192.168.1.18
s=session
c=IN IP4 192.168.1.20
t=0 0
m=audio 4340 RTP/AVP 18 101
a=rtpmap:18 G729/8000
a=ptime:40
a=sendrecv
a=rtpmap:101 telephone-event/8000

As yu can see, the packet is coming in right.
By: Joshua C. Colp (jcolp) 2008-01-21 11:10:05.000-0600

The message you gave contains external IP addresses, while all previously contained internal IP addresses, did you change 'em?
By: Olle Johansson (oej) 2008-01-21 11:10:18.000-0600

I tend to agree with file, there's nothing in Asterisk that would change the SDP. The printout is done at an early stage before parsing happens, so it's actually what we read.

This is mysterious. Would it be possible to get access to this server for debugging?
By: David Villasmil (davidcsi) 2008-01-21 11:13:13.000-0600

I did yes, obvious reasons.. ;)

Yes i could get you logged into the server...

I think its better to do this via msn: davidcsi@hotmail.com
By: David Villasmil (davidcsi) 2008-01-21 11:48:27.000-0600

as seen from ASTERISK:

SIP/2.0 200 Ok
Via: SIP/2.0/UDP 192.168.1.28:5060;branch=z9hG4bK130df927
From: "7059998" <sip:7059998@192.168.1.28>;tag=as31aa884a
To: <sip:34669448337@192.168.1.18>;tag=00E0F51004DB3090910500000F87
Call-ID: 077801314ac978605279977268fdf0b6@192.168.1.28
CSeq: 102 INVITE
Contact: <sip:192.168.1.18:5060>       <----- CONTACT
Allow-Events: refer
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, INFO, REFER, NOTIFY, SUBSCRIBE, UPDATE
Content-Type: application/sdp
Supported: 100rel, timer, replaces
P-Asserted-Identity: <sip:669448337@192.168.1.18:3111>
Content-Length:   200

v=0
o=- 81478068100004999 3 IN IP4 192.168.1.18
s=session
c=IN IP4 192.168.1.18
t=0 0
m=audio 5500 RTP/AVP 18 101
a=rtpmap:18 G729/8000
a=ptime:40
a=sendrecv
a=rtpmap:101 telephone-event/8000

as seen from TSHARK:

#
U 2008/01/21 18:39:59.675875 192.168.1.18:3111 -> 192.168.1.28:5060
SIP/2.0 200 Ok
Via: SIP/2.0/UDP 192.168.1.28:5060;branch=z9hG4bK130df927
From: "7059998" <sip:7059998@192.168.1.28>;tag=as31aa884a
To: <sip:34669448337@192.168.1.18>;tag=00E0F51004DB3090910500000F87
Call-ID: 077801314ac978605279977268fdf0b6@192.168.1.28
CSeq: 102 INVITE
Contact: <sip:192.168.1.18:5060>
Allow-Events: refer
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, INFO, REFER, NOTIFY, SUBSCRIBE, UPDATE
Content-Type: application/sdp
Supported: 100rel, timer, replaces
P-Asserted-Identity: <sip:669448337@192.168.1.18>
Content-Length:   200

v=0
o=- 81478068100004999 3 IN IP4 192.168.1.18
s=session
c=IN IP4 192.168.1.20
t=0 0
m=audio 5500 RTP/AVP 18 101
a=rtpmap:18 G729/8000
a=ptime:40
a=sendrecv
a=rtpmap:101 telephone-event/8000


This is too weird...
By: Olle Johansson (oej) 2008-01-21 11:57:08.000-0600

You need to run ngrep on the asterisk host to find out what's actually arriving there. THanks.
By: David Villasmil (davidcsi) 2008-01-21 11:58:03.000-0600

ALL traces are run on the asterisk box.
By: David Villasmil (davidcsi) 2008-01-21 11:59:08.000-0600

it seems to me, and I know this could sound stupid, that asterisk is not parsing the packet received but something it had on memory... could this be?
By: David Villasmil (davidcsi) 2008-01-21 15:53:01.000-0600

I believe this might be related to this:

http://forums.digium.com/viewtopic.php?p=57353&

I'll check it out and let you guys know.
By: Joshua C. Colp (jcolp) 2008-01-21 16:38:47.000-0600

After looking at the forum link I am quite confident that is the underlying issue here and not Asterisk.