[Home]

Summary:ASTERISK-09984: directrtpsetup doesn't work with 'nat=yes' devices
Reporter:Adam Gundy (adamgundy)Labels:
Date Opened:2007-07-30 13:33:32Date Closed:2007-08-10 09:55:11
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:I've been trying to get two copies of OpenWengo to talk to one another without asterisk in the middle (video kills my bandwidth!). OpenWengo unfortunately seems to be very unhappy with SIP reinvites, so I was hoping the new directrtpsetup behavior would be ideal.

it's worth noting that everything works well without reinvites turned on.

unfortunately, OpenWengo also doesn't appear to do STUN for 'custom' SIP accounts, so it presents LAN IP addresses to asterisk. with 'nat=yes', asterisk works around this by replying to the source IP address, rather than the one specified in the SIP message. HOWEVER, asterisk seems to figure out the RTP IP address/port by waiting for an incoming packet in 'nat=yes' mode, which of course never happens with 'directrtpsetup=yes'. instead, asterisk sends both SIP clients the LAN IP addresses and port numbers.

my thought is, depending on the definition of 'nat=yes', we still might be able to make this work - eg if 'nat=yes' means 'port forwarding, 1:1 mapping, symmetric NAT', then in theory we should be able to force the RTP IP address(es) to be the same as the SIP IP address, *IF* the SIP message contains the same (LAN) IP address for both SIP and RTP? other than that, we need to fail the direct invite...

that would at least allow people with NAT-blind devices to setup port forwarding and still have asterisk connect them directly.
Comments:By: Joshua C. Colp (jcolp) 2007-07-30 14:28:18

I'm suspending this since it's a feature request and an item that should be discussed on the asterisk-dev mailing list.
By: Adam Gundy (adamgundy) 2007-07-30 15:07:09

I don't mind discussing this stuff on the -dev list, but saying this is a feature request is not true.

for SIP: using 'directrtpsetup=yes' with 'nat=yes' and 'canreinvite=yes' results in no audio or video.

surely that's a BUG? the fact that I suggested a possible solution doesn't make it a feature request...
By: Joshua C. Colp (jcolp) 2007-07-30 15:10:48

directrtpsetup is known to be extremely buggy, thus why it is disabled by default but I can add additional checks to keep it disabled for known scenarios where it would go kaboom.
By: Adam Gundy (adamgundy) 2007-07-30 15:32:17

that's fine for a 1.4 bug fix... preferably with a verbose message saying why asterisk didn't do what it was asked to ;-)

I'm thinking the behavior of the 'directrtpsetup' option with 'canreinvite' is not really correct here - I think *all* 'nat=no' SIP devices would be perfectly happy with a direct connection.

I currently have to also specify 'canreinvite=yes' to trigger the direct connect, but it's actually not related to this at all - it's telling asterisk the device supports reinvites. in this case, I'd *like* to say: directrtpsetup=yes canreinvite=no, and still have asterisk either (a) do the direct invite, or (b) fall back to proxying...
By: Digium Subversion (svnbot) 2007-08-08 08:33:29

Repository: asterisk
Revision: 78569

------------------------------------------------------------------------
r78569 | file | 2007-08-08 08:33:27 -0500 (Wed, 08 Aug 2007) | 4 lines

(closes issue ASTERISK-9984)
Reported by: adamgundy
Update sip.conf to include another scenario where directrtpsetup will fail.

------------------------------------------------------------------------
By: Digium Subversion (svnbot) 2007-08-08 08:34:37

Repository: asterisk
Revision: 78570

------------------------------------------------------------------------
r78570 | file | 2007-08-08 08:34:37 -0500 (Wed, 08 Aug 2007) | 12 lines

Merged revisions 78569 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r78569 | file | 2007-08-08 10:51:01 -0300 (Wed, 08 Aug 2007) | 4 lines

(closes issue ASTERISK-9984)
Reported by: adamgundy
Update sip.conf to include another scenario where directrtpsetup will fail.

........

------------------------------------------------------------------------
By: Joshua C. Colp (jcolp) 2007-08-08 08:35:49

I ended up just adding a note to sip.conf, I came to the conclusion that if you are specifically doing canreinvite then you are saying the two devices can talk directly to eachother. As for another option for trunk feel free to open another bug if you have a patch for that.
By: Digium Subversion (svnbot) 2007-08-10 09:55:11

Repository: asterisk
Revision: 78994

------------------------------------------------------------------------
r78994 | murf | 2007-08-10 09:55:07 -0500 (Fri, 10 Aug 2007) | 117 lines

Merged revisions 78570,78590,78635,78637,78648-78649,78679,78683,78685-78686,78718,78747 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
r78570 | file | 2007-08-08 07:52:13 -0600 (Wed, 08 Aug 2007) | 12 lines

Merged revisions 78569 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r78569 | file | 2007-08-08 10:51:01 -0300 (Wed, 08 Aug 2007) | 4 lines

(closes issue ASTERISK-9984)
Reported by: adamgundy
Update sip.conf to include another scenario where directrtpsetup will fail.

........

................
r78590 | mmichelson | 2007-08-08 08:34:10 -0600 (Wed, 08 Aug 2007) | 12 lines

Merged revisions 78575 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r78575 | mmichelson | 2007-08-08 09:26:36 -0500 (Wed, 08 Aug 2007) | 4 lines

Changing a bit of logic so that someone will NEVER exit the queue on timeout unless they have enabled the 'n' option.
This commit relates to issue ASTERISK-9971. Thanks to jfitzgibbon for detailing the idea behind this code change.


........

................
r78635 | mmichelson | 2007-08-08 12:34:16 -0600 (Wed, 08 Aug 2007) | 11 lines

Blocked revisions 78620 via svnmerge

........
r78620 | mmichelson | 2007-08-08 13:16:49 -0500 (Wed, 08 Aug 2007) | 4 lines

Fixed some compiler warnings so that compiling with dev-mode and IMAP storage would not have any errors.
This section of code may get changed again shortly since my change uncovers a rather silly bit of logic.


........

................
r78637 | file | 2007-08-08 13:03:46 -0600 (Wed, 08 Aug 2007) | 2 lines

Correct spelling. s/threaads/threads/

................
r78648 | qwell | 2007-08-08 13:30:33 -0600 (Wed, 08 Aug 2007) | 10 lines

Merged revisions 78646 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r78646 | qwell | 2007-08-08 14:29:42 -0500 (Wed, 08 Aug 2007) | 2 lines

Fix mogs email address.

........

................
r78649 | file | 2007-08-08 13:30:52 -0600 (Wed, 08 Aug 2007) | 2 lines

Merge audiohooks branch into trunk. This is a new API for developers to listen and manipulate the audio going through a channel.

................
r78679 | file | 2007-08-08 14:49:07 -0600 (Wed, 08 Aug 2007) | 2 lines

HAVEL_SS7 should be HAVE_SS7. Reported by kwallace.

................
r78683 | file | 2007-08-08 15:44:58 -0600 (Wed, 08 Aug 2007) | 2 lines

Add support for using epoll instead of poll. This should increase scalability and is done in such a way that we should be able to add support for other poll() replacements.

................
r78685 | file | 2007-08-08 15:58:12 -0600 (Wed, 08 Aug 2007) | 2 lines

Minor fix for building under dev mode when byteswapping macro header files are not available.

................
r78686 | file | 2007-08-08 16:05:45 -0600 (Wed, 08 Aug 2007) | 2 lines

Regenerate configure script. This actually just updated the revision number... since my last merge changed it to an older number, while it was in fact generated from a much newer revision.

................
r78718 | russell | 2007-08-09 10:13:26 -0600 (Thu, 09 Aug 2007) | 15 lines

Merged revisions 78717 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r78717 | russell | 2007-08-09 11:12:57 -0500 (Thu, 09 Aug 2007) | 7 lines

Fix a problem with the combination of the 'F' option to pass DTMF through a
conference and options that use DTMF to activate various features.  The problem
was that the BEGIN frame would be passed through, but the END frame would get
intercepted to activate a feature.  Then, the other conference members would hear
DTMF for forever, which they didn't seem to like very much.
(closes issue ASTERISK-10038, reported by stevefeinstein, fixed by me)

........

................
r78747 | russell | 2007-08-09 11:07:36 -0600 (Thu, 09 Aug 2007) | 4 lines

Fix a problem that I had introduced into MWI handling.  I had ignored
the mailbox context.  Now, all related MWI event dealings pay attention
to the context as well.

................

------------------------------------------------------------------------