[Home]

Summary:ASTERISK-02879: contact header patch
Reporter:cherso (cherso)Labels:
Date Opened:2004-11-24 04:03:49.000-0600Date Closed:2011-06-07 14:05:27
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/Interoperability
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) chan_sip_contact_patch.diff
( 1) chan_sip_contact_patch.diff.txt
Description:this patch fixed a REGISTER nat issue of a buggy adsl router.
Hope it's RFC ok.
it's using fromdomain to build contact header (ref. build_callid)
Comments:By: cherso (cherso) 2004-11-24 08:05:16.000-0600

working on registration but it has a bad effect on music on hold, so forget it
By: twisted (twisted) 2004-11-24 17:13:45.000-0600

I don't see this as being correct, as it causes us to replace our IP with the value in the fromdomain for that particular entry.  This can cause problems, for example, if we need our IP to be correct in the contact header, but we need to appear to be part of another domain.

ie, we are at ip 192.168.0.2, and our sip domain is ourdomain.com (which resolves to 10.10.10.15).

If we substitute the record from the fromdomain=ourdomain.com, the resulting contact header will send the packets to 10.10.10.15 as opposed to our location, 192.168.0.2.

I may be completely wrong, but that's the way it seems like it would work to me.
By: Brian West (bkw918) 2004-11-24 18:13:27.000-0600

bad bad bad patch.. we need to know what your localnet = and externip were and who you're trying reg with.

bkw
By: Mark Spencer (markster) 2004-11-24 22:05:04.000-0600

Can you send a trace of what the problem is?
By: brads (brads) 2004-11-25 01:35:26.000-0600

As of today, the patch has fixed the opaque problem, and the uri problem without failure. Thank you!
By: cherso (cherso) 2004-11-25 02:35:36.000-0600

for bkw...
It's an asterisk2asterisk registration.
both asterisks are behind a nat
the first router is a draytek 2600 with a buggy ALG NAT system (all the draytek adsl router work this way and it can't be disabled).
Every sip packet that comes in will be changed. The wan ip address will be replaced by the local ip address of the machine that is running asterisk.
So you need to use fromdomain keyword (sip.conf) to get a working rtp connection (call-id header problem fixed in may)

For the authentication: the problem is the URI field
for example:
Asterisk 1 (no buggy router) is sending
Authorization: Digest username="sergio", realm="asterisk", algorithm=MD5, uri="sip:sergio@82.xx.xx.xx", nonce="69e10fb6", response="83b997x77xfdx8139f6b7xa3x552c10d", opaque=""

Asterisk 2 (with buggy router) receives
Authorization: Digest username="sergio", realm="asterisk", algorithm=MD5, uri="sip:sergio@192.168.0.100", nonce="69e10fb6", response="83b997x77xfdx8139f6b7xa3x552c10d", opaque=""

the reply is:
Got SIP response 403 "Forbidden" back from 82.xx.xx.xx

Ok.. with my (bad :-)) patch
Asterisk 1 (no buggy router) is sending
Authorization: Digest username="sergio", realm="asterisk", algorithm=MD5, uri="sip:sergio@fromdomain", nonce="69e10fb6", response="83b997x77xfdx8139f6b7xa3x552c10d", opaque=""

Asterisk2 (with buggy router) receives
Authorization: Digest username="sergio", realm="asterisk", algorithm=MD5, uri="sip:sergio@fromdomain", nonce="69e10fb6", response="83b997x77xfdx8139f6b7xa3x552c10d", opaque=""

Registration works.
Well I think it's not a good way to force a registration. It has for sure a bad effect on a different type of authentication.
It's just a try to get asterisk working behind all those routers with ALG NAT system
I don't know how to force asterisk to use a domain name in the URI field
thx
sergio

edited on: 11-25-04 02:47
By: cherso (cherso) 2004-11-25 04:02:50.000-0600

same scenario. Cisco 7905 is registering with no errors on the asterisk2 (with buggy router)
Cisco 7905 uses URI="sip:domainname" in the authentication header

asterisk is sending REGISTER sip:domainname with
uri="sip:sergio@dest_ip_address"

do we really need a uri with the username and the ip address in the authentication header?
can we just set uri="sip:domainname" like the REGISTER field?

edited on: 11-25-04 05:15
By: Brian West (bkw918) 2004-11-26 16:34:13.000-0600

so double nat... maybe nat=double option?
By: khb (khb) 2004-11-26 17:23:10.000-0600

>> do we really need a uri with the username and the ip address in the authentication header?
>>can we just set uri="sip:domainname" like the REGISTER field?

Yes, you can.  In fact, I think, it should be the same as the request uri from the REGISTER first header and its only purpose here is to keep the original request uri in the packet, since a proxy is allowed to change the first line.
But what does this have to do with the COntact header patch?

You also point out a real problems with some ALGs since they rewrite addresses they don't like anywhere in the data (binary or ascii) where they see them. This can break the STUN protocol as well, and they create an additional source of problems beside the very NAT problems they are supposed to help.
It's is always preferable to use domainnames instead of ip addresses for these reasons, despite the extra DNS lookup that is sometimes required. Hmm, my SIP does use domain names in the uri, but I don't remember at what point I changed that.
Asterisk SIP has a habit of using IP addresses in some places despite knowing the domain names as well. Such header information is not well handled and therefore we must be carefull here to just apply any patch that works for a specific situation.  In general the address in contact header should be the address or fqdn of that address at which the UA can actually physically be reached. It seems that in your case that address happens to coincide with the address of the fromdomain,  but in general it won't.  This appears to be a fix for a specific scenario only, but nothing we should do in general.


>> so double nat... maybe nat=double option?

I don't think this should be a configurable option in any case.  Leave it a customer specific local patch for that user to maintain.

These types of NAT, and now plus ALG, problems are almost impossible to handle with general methods (at least not based on a single instance), particularly when our base SIP protocol isn't even compliant.  So, I think one should take note of this example and keep in mind for furture changes.

$0.02

edited on: 11-26-04 17:28
By: Brian West (bkw918) 2004-11-26 17:26:48.000-0600

But we should be paying attention to the via header right? if we get it?

bkw
By: cherso (cherso) 2004-11-26 17:33:23.000-0600

via it's not a problem with this ALG router, setting up the fromdomain everything is working good. The problem was the call-id header with wan ip address on outgoing calls replaced with the local ip address on incoming ACK packet (solved in may)

now the problem is the registration. I know it's just a problem of those ALG router (it's not an asterisk problem).
I really don't know how to set up the sip.conf to force an authentication uri="sip:domainname" or sip:fromdomainname
By: cherso (cherso) 2004-11-26 17:41:25.000-0600

the problem has been reported to draytek tech support but they are not in the mood to provide a firmware to let the user decides to activate/deactivate ALG system.
Good way to get a working softphone without STUN, but it will kill your brain trying to run a SIP server inside :-(

edited on: 11-26-04 17:42
By: khb (khb) 2004-11-26 17:57:33.000-0600

Sure, naturally we should be paying proper attention to all the headers, since they all have their meaningful purpose. And we are using the VIA header to send responses to requests back.  The VIA header identifies the tranport layer characteristics used for a message.  Asterisk SIP doesn't really have any layered architecture, it's just one big pile of spaghetti.
By: khb (khb) 2004-11-26 18:03:33.000-0600

Yes, substitutions in the Call-ID will kill any communcations since we can't match incoming packets with prior dialogs reliably.  We can help with this in a general way by not coding the IP address with the dots but for example using dashes instead.  THat way an ALG won't substitute.  There is no requirement for the format for the Call-Id, only that it be globally unique string.
By: Mark Spencer (markster) 2004-12-12 00:02:36.000-0600

So what's the concensus here?  Are we ready to close this out?
By: Olle Johansson (oej) 2004-12-12 02:54:35.000-0600

According to the reporter, this patch is not needed any more. If there are other problems with the Draytek, open another report.