[Home]

Summary:ASTERISK-02326: [request] [post 1.2] support reponses to INVITEs on IP address aliases to come back on the same IP
Reporter:ltropiano (ltropiano)Labels:
Date Opened:2004-09-02 12:44:12Date Closed:2011-06-07 14:05:31
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/CodecHandling
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) asterisk-081204.srcudpaddr.txt
( 1) sc_diff_acl_c_1.txt
( 2) sc_diff_acl_h_1.txt
Description:Currently if we have Asterisk SIP channel driver binding to all interfaces, and eth0 has many subnets attached to it (a primary 10.1.200.1, and then alias interfaces eth0:1 with 10.1.201.1, eth0:2 with 10.1.202.1, eth0:3 with 10.1.203.1..

If an INVITE is sent to Asterisk on 10.1.202.1 (eth0:2) the response is always returned to 10.1.200.1.  We need it to come back to 10.1.202.1.  

Spoke to Mark Spencer about this, and he agreed do to the nature of UDP there would have to be code written to support this.  I inquired with Digium to do it, but haven't heard back from their consulting folks, so I'm asking the greater community as a whole.  

Our company is willing to pay a $500 bounty (Paypal) to code sent to us, that we'll approve and agree works for our load test scenarios we develop in house and then send/submit to the Asterisk folks as open source.  

It should be a patch/diff on the -HEAD version of chan_sip.c (or any other code that might need to be changed).

Thanks.
Comments:By: Brian West (bkw918) 2004-09-02 13:03:22

Please post this to the mailing list and add it to the voip-info.org wiki.

http://www.voip-info.org/tiki-index.php?page=Asterisk%20bounty
By: Rob Gagnon (rgagnon) 2004-09-02 23:42:04

This sounds like more of a routing issue at the networking level than anything else.

If 10.1.200.1 is in the same network as your default gateway setting, and there are no other routes on the computer, the packet is going to go out that way unless the station to respond to matches its network number to any of the aliases.

In your example, you did not supply the subnet masks you used in your example.  if they are all "/8" then there really is no way to control things since each alias is in the same network.  

I imagine you have subnetted things into class-C's or smaller.

In that case, you would need to setup routing to send data for particular networks to a gateway that matches the network number of one of your aliases.

Better yet, Save $485 and spend $15 on 3 more network cards in the machine :-)
By: ltropiano (ltropiano) 2004-09-03 07:04:08

It's partially a routing issue, but not completely.  The SIP OK response and SDP headers have the primary IP address in the packets...  if it had the address we received the packet on in the response, it would route just fine.

Also regarding your comment on 3 NIC cards and saving money, we have over 1000 addresses on this machine as it simulates load in our product... so it wouldn't solve the real problem :)
By: Tim Stewart (applsplatz) 2004-09-03 10:05:52

I'm working on this for you.  I should have it working by the end of today, if not earlier.  However, I would like to confirm whether or not each of those IP addresses is in a separate subnet.  Also, will the SIP clients be running asterisk, and if so, are their interfaces aliased as well?
By: ltropiano (ltropiano) 2004-09-03 10:24:47

I already have a submission (received this morning) that I'm reviewing.  Just to level set everyone.
By: Brian West (bkw918) 2004-09-03 13:44:27

goes on the Wiki till we get a patch.
By: Tilghman Lesher (tilghman) 2004-09-03 15:52:56

See uploaded patch.
By: ltropiano (ltropiano) 2004-09-03 16:03:09

Corydon76 is the 2nd submission to me.  Will review as well.
Both take similar takes on the subject.  recvmsg() vs. recvfrom().  

Q: Why the option (ReplyOnRecv?)  This should be the case always and not an option.
By: ltropiano (ltropiano) 2004-09-03 16:04:56

Corydon76 also your patch isn't based on the -HEAD version, as requested.
By: ltropiano (ltropiano) 2004-09-03 16:12:51

Corydon76, I've tested your patch.  It did not work.  

test1*CLI> sip show peer 3024
test1*CLI>

 * Name       : 3024
 Secret       : <Not set>
 MD5Secret    : <Not set>
 Context      : default
 Language     :
 FromUser     :
 FromDomain   :
 Callgroup    :  (0)
 Pickupgroup  :  (0)
 Mailbox      : 105
 LastMsgsSent : 0
 Dynamic      : Yes
 Expire       : 11
 Expiry       : 900
 Insecure     : No
 Nat          : RFC3581
 ACL          : No
 CanReinvite  : No
 ReplyOnRecv  : Yes
 PromiscRedir : No
 DTMFmode     : rfc2833
 LastMsg      : 0
 ToHost       :
 Addr->IP     : 10.50.34.16 Port 5060
 Defaddr->IP  : 0.0.0.0 Port 0
 Username     : 3024
 Codecs       : GSM ULAW ALAW
 Status       : UNKNOWN
 Useragent    : X-PRO build 1082
 Full Contact : sip:3024@10.50.34.16:5060

test1*CLI>

Sip read:


0 headers, 0 lines
test1*CLI>

Sip read:


0 headers, 0 lines
test1*CLI>

Sip read:


0 headers, 0 lines
test1*CLI>

Sip read:


0 headers, 0 lines
test1*CLI>

Sip read:


0 headers, 0 lines
test1*CLI>


Two problems.  The debug messages over and over (0 headers, 0 lines).  

Set in sip.conf as:

[3024]
type=friend
username=3024
host=dynamic
qualify=no
canreinvite=no
replyonreceiver=yes
mailbox=105

But the OK and c= lines still report back to 10.1.200.1.


(see debug below)
test1*CLI> sip debug
SIP Debugging Enabled
test1*CLI>

Sip read:
INVITE sip:999@10.1.205.22 SIP/2.0
Via: SIP/2.0/UDP 10.50.34.16:5060;rport;branch=z9hG4bK60F26E76D7434185A091BDF7ADB38254
From: Lenny Tropiano <sip:3024@10.1.205.22>;tag=905037022
To: <sip:999@10.1.205.22>
Contact: <sip:3024@10.50.34.16:5060>
Call-ID: 1CB20E79-1126-4515-B92A-EFB5914C3F09@10.50.34.16
CSeq: 21380 INVITE
Max-Forwards: 70
Content-Type: application/sdp
User-Agent: X-PRO build 1082
Content-Length: 241

v=0
o=3024 329188087 329188087 IN IP4 10.50.34.16
s=X-PRO
c=IN IP4 10.50.34.16
t=0 0
m=audio 8000 RTP/AVP 0 3 98 101
a=rtpmap:0 pcmu/8000
a=rtpmap:3 gsm/8000
a=rtpmap:98 iLBC/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

11 headers, 11 lines
Using latest request as basis request
Sending to 10.50.34.16 : 5060 (non-NAT)
Found RTP audio format 0
Found RTP audio format 3
Found RTP audio format 98
Found RTP audio format 101
Peer audio RTP is at port 10.50.34.16:8000
Found description format pcmu
Found description format gsm
Found description format iLBC
Found description format telephone-event
Capabilities: us - 0xe(GSM|ULAW|ALAW), peer - audio=0x406(GSM|ULAW|ILBC)/video=0x0(EMPTY), combined - 0x6(GSM|ULAW)
Non-codec capabilities: us - 0x1(G723), peer - 0x1(G723), combined - 0x0(EMPTY)
Found user '3024'
Looking for 999 in default
list_route: hop: <sip:3024@10.50.34.16:5060>
Transmitting (no NAT):
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.50.34.16:5060;branch=z9hG4bK60F26E76D7434185A091BDF7ADB38254
From: Lenny Tropiano <sip:3024@10.1.205.22>;tag=905037022
To: <sip:999@10.1.205.22>;tag=as0e267cc0
Call-ID: 1CB20E79-1126-4515-B92A-EFB5914C3F09@10.50.34.16
CSeq: 21380 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER
Contact: <sip:999@10.1.200.1>
Content-Length: 0


to 10.50.34.16:5060
   -- Executing Answer("SIP/3024-04eb", "") in new stack
We're at 10.1.200.1 port 19878
Video is at 10.1.200.1 port 16274
Answering with capability 0x2(GSM)
Answering with capability 0x4(ULAW)
Answering with capability 0x8(ALAW)
Answering with non-codec capability 0x1(G723)
Reliably Transmitting (no NAT):
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.50.34.16:5060;branch=z9hG4bK60F26E76D7434185A091BDF7ADB38254
From: Lenny Tropiano <sip:3024@10.1.205.22>;tag=905037022
To: <sip:999@10.1.205.22>;tag=as0e267cc0
Call-ID: 1CB20E79-1126-4515-B92A-EFB5914C3F09@10.50.34.16
CSeq: 21380 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER
Contact: <sip:999@10.1.200.1>
Content-Type: application/sdp
Content-Length: 259

v=0
o=root 28478 28478 IN IP4 10.1.200.1
s=session
c=IN IP4 10.1.200.1
t=0 0
m=audio 19878 RTP/AVP 3 0 8 101
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 - - - -

to 10.50.34.16:5060
   -- Executing Playback("SIP/3024-04eb", "demo-congrats") in new stack
   -- Playing 'demo-congrats' (language 'en')
test1*CLI>

Sip read:
ACK sip:999@10.1.200.1 SIP/2.0
Via: SIP/2.0/UDP 10.50.34.16:5060;rport;branch=z9hG4bKB18075150C6A4AE8B0C765F1B67AC121
From: Lenny Tropiano <sip:3024@10.1.205.22>;tag=905037022
To: <sip:999@10.1.205.22>;tag=as0e267cc0
Contact: <sip:3024@10.50.34.16:5060>
Call-ID: 1CB20E79-1126-4515-B92A-EFB5914C3F09@10.50.34.16
CSeq: 21380 ACK
Max-Forwards: 70
Content-Length: 0


9 headers, 0 lines
test1*CLI>

Sip read:
BYE sip:999@10.1.200.1 SIP/2.0
Via: SIP/2.0/UDP 10.50.34.16:5060;rport;branch=z9hG4bKE2F3591D1B9A4F88BDE056EC96D3BDA6
From: Lenny Tropiano <sip:3024@10.1.205.22>;tag=905037022
To: <sip:999@10.1.205.22>;tag=as0e267cc0
Contact: <sip:3024@10.50.34.16:5060>
Call-ID: 1CB20E79-1126-4515-B92A-EFB5914C3F09@10.50.34.16
CSeq: 21381 BYE
User-Agent: X-PRO build 1082
Content-Length: 0


9 headers, 0 lines
Sending to 10.50.34.16 : 5060 (non-NAT)
Transmitting (no NAT):
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.50.34.16:5060;branch=z9hG4bKE2F3591D1B9A4F88BDE056EC96D3BDA6
From: Lenny Tropiano <sip:3024@10.1.205.22>;tag=905037022
To: <sip:999@10.1.205.22>;tag=as0e267cc0
Call-ID: 1CB20E79-1126-4515-B92A-EFB5914C3F09@10.50.34.16
CSeq: 21381 BYE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER
Contact: <sip:999@10.1.200.1>
Content-Length: 0


to 10.50.34.16:5060
By: ltropiano (ltropiano) 2004-09-03 16:16:22

The first patch, here's the debug output (which is correct).  Still a few minor nits I have with it (Theo?)


Sip read:
INVITE sip:999@10.1.205.22 SIP/2.0
Via: SIP/2.0/UDP 10.50.34.16:5060;rport;branch=z9hG4bK5ED88D83708A424BAE349AC63E580671
From: Lenny Tropiano <sip:3024@10.1.205.22>;tag=1346954292
To: <sip:999@10.1.205.22>
Contact: <sip:3024@10.50.34.16:5060>
Call-ID: 16A94CA8-FCE0-459C-AD07-9E80510AA75C@10.50.34.16
CSeq: 1038 INVITE
Max-Forwards: 70
Content-Type: application/sdp
User-Agent: X-PRO build 1082
Content-Length: 241

v=0
o=3024 329406831 329406831 IN IP4 10.50.34.16
s=X-PRO
c=IN IP4 10.50.34.16
t=0 0
m=audio 8000 RTP/AVP 0 3 98 101
a=rtpmap:0 pcmu/8000
a=rtpmap:3 gsm/8000
a=rtpmap:98 iLBC/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

11 headers, 11 lines
Using latest request as basis request
Sending to 10.50.34.16 : 5060 (non-NAT)
Found RTP audio format 0
Found RTP audio format 3
Found RTP audio format 98
Found RTP audio format 101
Peer audio RTP is at port 10.50.34.16:8000
Found description format pcmu
Found description format gsm
Found description format iLBC
Found description format telephone-event
Capabilities: us - 0xe(GSM|ULAW|ALAW), peer - audio=0x406(GSM|ULAW|ILBC)/video=0x0(EMPTY), combined - 0x6(GSM|ULAW)
Non-codec capabilities: us - 0x1(G723), peer - 0x1(G723), combined - 0x0(EMPTY)
Found no matching peer or user for '10.50.34.16:5060'
Looking for 999 in default
list_route: hop: <sip:3024@10.50.34.16:5060>
Transmitting (no NAT):
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.50.34.16:5060;branch=z9hG4bK5ED88D83708A424BAE349AC63E580671
From: Lenny Tropiano <sip:3024@10.1.205.22>;tag=1346954292
To: <sip:999@10.1.205.22>;tag=as6faaddc1
Call-ID: 16A94CA8-FCE0-459C-AD07-9E80510AA75C@10.50.34.16
CSeq: 1038 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER
Contact: <sip:999@10.1.205.22>
Content-Length: 0


to 10.50.34.16:5060
   -- Executing Answer("SIP/10.1.205.22-08a778c8", "") in new stack
We're at 10.1.205.22 port 11672
Video is at 10.1.205.22 port 18582
Answering with capability 0x2(GSM)
Answering with capability 0x4(ULAW)
Answering with capability 0x8(ALAW)
Reliably Transmitting (no NAT):
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.50.34.16:5060;branch=z9hG4bK5ED88D83708A424BAE349AC63E580671
From: Lenny Tropiano <sip:3024@10.1.205.22>;tag=1346954292
To: <sip:999@10.1.205.22>;tag=as6faaddc1
Call-ID: 16A94CA8-FCE0-459C-AD07-9E80510AA75C@10.50.34.16
CSeq: 1038 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER
Contact: <sip:999@10.1.205.22>
Content-Type: application/sdp
Content-Length: 205

v=0
o=root 30932 30932 IN IP4 10.1.205.22
s=session
c=IN IP4 10.1.205.22
t=0 0
m=audio 11672 RTP/AVP 3 0 8
a=rtpmap:3 GSM/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=silenceSupp:off - - - -

to 10.50.34.16:5060
   -- Executing Playback("SIP/10.1.205.22-08a778c8", "demo-congrats") in new stack
   -- Playing 'demo-congrats' (language 'en')
test1*CLI>

Sip read:
ACK sip:999@10.1.205.22 SIP/2.0
Via: SIP/2.0/UDP 10.50.34.16:5060;rport;branch=z9hG4bK359CBCC3646E4592A26008B2F58F0373
From: Lenny Tropiano <sip:3024@10.1.205.22>;tag=1346954292
To: <sip:999@10.1.205.22>;tag=as6faaddc1
Contact: <sip:3024@10.50.34.16:5060>
Call-ID: 16A94CA8-FCE0-459C-AD07-9E80510AA75C@10.50.34.16
CSeq: 1038 ACK
Max-Forwards: 70
Content-Length: 0


9 headers, 0 lines
test1*CLI>

Sip read:
BYE sip:999@10.1.205.22 SIP/2.0
Via: SIP/2.0/UDP 10.50.34.16:5060;rport;branch=z9hG4bK9C3255F6535C42A2B24B06BD1047FEBE
From: Lenny Tropiano <sip:3024@10.1.205.22>;tag=1346954292
To: <sip:999@10.1.205.22>;tag=as6faaddc1
Contact: <sip:3024@10.50.34.16:5060>
Call-ID: 16A94CA8-FCE0-459C-AD07-9E80510AA75C@10.50.34.16
CSeq: 1039 BYE
User-Agent: X-PRO build 1082
Content-Length: 0


9 headers, 0 lines
Sending to 10.50.34.16 : 5060 (non-NAT)
Transmitting (no NAT):
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.50.34.16:5060;branch=z9hG4bK9C3255F6535C42A2B24B06BD1047FEBE
From: Lenny Tropiano <sip:3024@10.1.205.22>;tag=1346954292
To: <sip:999@10.1.205.22>;tag=as6faaddc1
Call-ID: 16A94CA8-FCE0-459C-AD07-9E80510AA75C@10.50.34.16
CSeq: 1039 BYE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER
Contact: <sip:999@10.1.205.22>
Content-Length: 0


to 10.50.34.16:5060
By: Tilghman Lesher (tilghman) 2004-09-03 16:18:57

To answer your question:  why the option?  Because while you're free to change the default option, the behavior should not change between CVS updates.  This is a Mark-mandate for all patches.
By: ltropiano (ltropiano) 2004-09-03 16:22:16

While I agree with Mark on behavior that is correct... I believe the behavior is incorrect.  It should always respond to the receiver on the address it was receiving traffic on.
By: Tilghman Lesher (tilghman) 2004-09-03 16:33:48

You're going to have to consult Mark on the current behavior as to whether or not that's correct.  In the meantime, see second patch.
By: ltropiano (ltropiano) 2004-09-03 16:42:53

The 2nd patch, although against CVS HEAD, still has the same problems. It doesn't work as advertised (even with the replyonreceiver=yes in the sip.conf) nor does it stop the "sip debug" messages that keep spewing.
By: serkan (serkan) 2004-09-07 18:05:08

Please try the new attachments.
By: twisted (twisted) 2004-10-01 11:51:25

I'm requesting a statuson this, as this was a bounty.  Has this been fulfilled? If so, I need to close it.  Otherwise, we need this to remain active to avoid close.

Thnks.
By: ltropiano (ltropiano) 2004-10-02 11:42:35

Olle was looking at wokring on this, but with Astricon it wasn't possible to do both.  The bounty hasn't been paid.  We received several submissions, all of them had implications and issues and 100% CVS worthy yet.
By: Olle Johansson (oej) 2004-10-12 13:01:24

Bountys are kept open on the Wiki, closed here until we have a patch. This is standard procedure, I hope no offence is taken.
By: ltropiano (ltropiano) 2004-12-08 15:46:26.000-0600

Paid $500 bounty to Theo Zourzouvillys today.  

He will attach patch from him... I'd like to see this as an inclusion in the future chan_sip, as it's been working for me well.  

Theo said he has a disclaimer on file :)
By: theo (theo) 2004-12-08 16:00:54.000-0600

asterisk-081204.srcudpaddr.txt uploaded, disclaimer already on file.

will need to be ported to bsd.
By: Olle Johansson (oej) 2004-12-19 04:10:55.000-0600

See bug ASTERISK-3027 - the ast_ouraddrfor was changed last night. Does this in any way change this patch?
By: nick (nick) 2005-01-02 18:46:15.000-0600

Theo: please advise on the status of this...  does it still work with latest CVS? If not, will you fix it?

--housekeeping
By: twisted (twisted) 2005-01-09 22:36:32.000-0600

ltroplano/theo - your response is requsted here - is this still an issue?
By: ltropiano (ltropiano) 2005-01-09 22:38:14.000-0600

Yes, I'd like to see it in CVS... Theo?
By: Mark Spencer (markster) 2005-01-12 23:57:46.000-0600

I've added support in iax2 for bindaddr to bind to multiple addresses which does *not* require the use of these msg things, can you take a look at my work there and see what it would take to make it work for SIP?
By: ltropiano (ltropiano) 2005-01-16 07:17:42.000-0600

Looking at the code and what it supposed to do it's likely it could have the same benefit in chan_sip as it has in the iax channel driver and could solve this without OS-dependent *msg() routines as you said.
By: Alberto Fernandez (derkommissar) 2005-01-18 09:39:39.000-0600

Has this pach been added to the cvs ?
By: Mark Spencer (markster) 2005-01-18 10:45:26.000-0600

No, I'm thinking the method used in IAX2 will be better and is part of acl so it should be easily accessible to the SIP side.
By: Alberto Fernandez (derkommissar) 2005-01-18 11:21:29.000-0600

So that means that with the current CVS, sip woulnt work with more than 2 IP'S at once ?

Or if it does it always awnsers trhu the primary ip?
I was trying to explain this problem a while back. But i wasnt successful at explaining it.

I would love to see it fixed at least for sip.
By: Mark Spencer (markster) 2005-03-08 23:51:40.000-0600

OEJ and I need to talk about this and how we can use the ACL stuff.  I've added some ACL changes which should help things out.
By: Kevin P. Fleming (kpfleming) 2005-03-10 11:56:53.000-0600

oej has already got a lot on his plate, so I'll take the responsibility for following through on this one.
By: Mark Spencer (markster) 2005-03-26 18:19:19.000-0600

Anyone still want to work with me on this one?
By: Kevin P. Fleming (kpfleming) 2005-03-26 19:18:54.000-0600

Yes, I've been working on it here, we can finish it up next week.
By: Mark Spencer (markster) 2005-03-26 20:15:40.000-0600

Rock on!
By: manero (manero) 2005-04-08 19:45:43

How work continues because CVS SIP doesn't behave friendly to multihomed PC. Worse on multihomed PC there is no way to run SIP successfully due this bug. It is really strange that adding alias to interface brings such troubles.

On multihomed PC all response must match destination address because we cannot assume any routing between aliased addresses and in consequence wrong response address makes Asterisk unaccessible.
By: Brian West (bkw918) 2005-04-12 09:49:17

Ok updated the title on this one since manero is about to have a cow over this.

/b
By: Kevin P. Fleming (kpfleming) 2005-04-12 10:20:56

This will get fixed, but there have been other priorities lately, sorry about that.

Note that using interface aliases is _not_ multihoming by any definition of that word; multihoming implies separate interfaces attached to distinct networks. In that configuration, Asterisk works just fine. Interface aliases are a different configuration altogether... in that mode, the kernel cannot pick a proper outbound address because all the addresses appear to be connected to the same subnet.

I will try to get this done this week; please be ready to test it as soon as possible whent he code is posted, and include your company information if you are offering a bounty for the work.
By: manero (manero) 2005-04-14 16:57:21

I think that this has nothing to do with kernel because kernel always chooses correct address (as far as I know). This is not problem of ipv4 or udp but values in SIP protocol.
From programmer point of view there should be no difference between multihomed or aliased PC. In each case when you need to know destination address it is not enough to call recvfrom function (as used in chan_sip) but one must use recvmsg (showed in patch). Furthermore this approach is more compatible with ipv6.

edited on: 04-15-05 06:56
By: Olle Johansson (oej) 2005-06-05 17:16:14

We need to wake this baby up... Could we split it up and take it step by step, first getting chan_sip up to chan_iax2 level and then see if we need to do more?

I need chan_sip to know, maybe have a list, of all possible interfaces to know what domains we listen to in auto mode (see my sipdomain patch). Some domains consist of just a text version of the IP address, and I can't make that happen automatically when bindaddr=0.0.0.0

/Olle
By: Kevin P. Fleming (kpfleming) 2005-06-05 17:53:00

I will be working on this during the coming week, before I head to Astricon. However, that work will not really do anything to help your 'auto-domain' issue, and I don't think we can reliably do auto-domain for IP addresses anyway, since address can come and go while Asterisk is running.

The work I am doing for this netsock stuff, though, will help out, because I plan to continue allowing channels to bind to the wildcard address, but be notified when they receive packets to an IP address they have not seen before. At least then chan_sip can stay up to date with the list of IP addresses it is listening on (indirectly, through the wildcard bind).
By: Michael Jerris (mikej) 2005-06-23 05:53:49

kevin-  If I read the comments correctly, you are discussing dns name issues, which to my understanding is not what this is about.  Is this multiple issues that you are working on intertwined or am I missing somthing?
By: Brian West (bkw918) 2005-07-07 11:55:34

Ok why is this just sitting here?  This is a fundamental flaw in how it should work... and should have been something that worked out of the box from day one!  IAX has a similar flaw but nobody will pay attention when I try to tell them about it...

*sigh*

/b
By: Olle Johansson (oej) 2005-07-20 12:54:50

This will be redesigned alongside with the recent changes in chan_iax2.c, so a different, more complete, solution is coming soon. Stay tuned to this bug report :-)
By: Michael Jerris (mikej) 2005-08-24 01:36:45

*ping* oej... where does this stand?
By: Olle Johansson (oej) 2005-08-24 01:43:12

*Pong* - it's waiting for Kevin's patch.
By: Michael Jerris (mikej) 2005-09-09 19:59:29

kevin-  can you please make a determination if this is going to be in 1.2 or not and mark post 1.2 if not.  Thanks.
By: Michael Jerris (mikej) 2005-09-25 19:17:20

Suspending this pending workable code to address this issue.  Perhaps a call for raising the bounty would help.  Please re-open this when there is code ready for review.  Thanks.
By: Digium Subversion (svnbot) 2008-01-15 15:27:10.000-0600

Repository: asterisk
Revision: 5155

U   trunk/acl.c
U   trunk/include/asterisk/acl.h

------------------------------------------------------------------------
r5155 | markster | 2008-01-15 15:27:09 -0600 (Tue, 15 Jan 2008) | 2 lines

Make ACL be what SIP is going to need (bug ASTERISK-2326, just first part)

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

http://svn.digium.com/view/asterisk?view=rev&revision=5155