On 12/30/2011 04:07 AM, James Lamanna wrote:
Hi,
I've been trying to fix NOTIFY replies (specifically keep-alives) in 1.4.42
(I can't upgrade to 1.8.x at the moment for various reasons).
I've noticed for user agents that have a VIA header with a different
port than the port the NOTIFY was sent from,
the NOTIFY reply will always be sent back to that port, which is incorrect.
(Sonicwalls and other routers love to do this, even with "Symmetric NAT" on).
The reason for this is that the NOTIFY reply does not attempt to
lookup the SIP peer and check
its NAT flags.
I've seen some nasty From: header string parsing code + find_peer()
that does this, but I was wondering
if there's an easier way.
Since Asterisk does not initiate subscriptions, these NOTIFY requests
arriving to the Asterisk system must be 'unsolicited'. As such, they
don't have an associated SIP dialog structure, so there's no simple way
to know whether they are associated with a known peer or not.
You say that Asterisk's behavior is 'incorrect', but it's only
'incorrect' because you believe it should be looking up any associated
peer and using that peer's NAT setting; Asterisk's behavior as you've
quoted is *correct* according to the RFC3261 rules for how replies
should be sent, assuming that the top-most Via header does not have an
'rport' parameter present in it.
The *proper* way to solve this problem is to have the UA sending the
NOTIFY request include the 'rport' parameter in the top-most Via header
of the request; if that is done, then whatever UA receives the request
will be able to properly respond, even if the request crosses a NAT.
Another way to solve it, if the sending UA cannot be changed to emit
proper SIP requests, is to modify Asterisk to attempt a peer lookup when
it is going to reply to request that it cannot associate with any known
dialog, and then have the peer configured with 'nat=yes' (in the case of
1.4.42). A third option is to set 'nat=yes' in the [general] section of
sip.conf, so that Asterisk will reply using rport-style behavior
regardless of whether the request could be associated with a peer or not.
--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: [email protected] | SIP: [email protected] | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
http://www.asterisk.org/hello
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
