On 12/30/2011 03:09 PM, James Lamanna wrote:
On Fri, Dec 30, 2011 at 11:55 AM, Kevin P. Fleming<kpflem...@digium.com> wrote:
On 12/30/2011 12:29 PM, James Lamanna wrote:
On Fri, Dec 30, 2011 at 8:35 AM, James Lamanna<jlama...@gmail.com> wrote:
On Fri, Dec 30, 2011 at 6:02 AM, Kevin P. Fleming<kpflem...@digium.com>
wrote:
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.
Thanks Kevin.
I'll have to turn rport on on all my Linksys/Cisco phones and give it a
shot.
Hi Kevin,
That doesn't appear to work correctly:
The response does not come back to 34972 even though rport is in the Via.
U xxx.234:34972 -> yyy..7:5060
NOTIFY sip:yyy.7 SIP/2.0..Via: SIP/2.0/UDP
10.132.38.19:6957;branch=z9hG4bK-25ea41f0;rport..From: "1316"
<sip:1316@yyy.7>;tag=80f427ae9e884ado0..To:<sip:yyy
.7>..Call-ID: 4fa38a62-b7d76...@10.132.38.19..cseq: 1
NOTIFY..Max-Forwards: 70..Contact: "1316"
<sip:1316@10.132.38.19:6957>..Event: keep-alive..User-Agent:
Linksys/SPA942-6.1.3(
a)..Content-Length: 0....
#
U yyy.7:5060 -> xxx.234:6957
SIP/2.0 481 No subscription..Via: SIP/2.0/UDP
10.132.38.19:6957;branch=z9hG4bK-25ea41f0;received=xxx.234;rport=34972..From:
"1316"<sip:1316@yyy.7>;tag=80f427ae9e884
ado0..To:<sip:yyy.7>;tag=as07ad17b5..Call-ID:
4fa38a62-b7d76...@10.132.38.19..cseq: 1 NOTIFY..User-Agent: Asterisk
PBX..Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTI
FY, INFO..Supported: replaces..Content-Length: 0....
That would be a bug then; the 481 response was not sent to the proper port.
It's strange though, because the rport parameter was properly updated with
the 'perceived port', and the received parameter was added as well.
Could this be because this is sent through a "temporary' response,
rather than the
traditional allocation? (it uses transmit_response_using_temp)
I'm sure that is related, but it's still a bug :-) Unfortunately you've
reported this against an Asterisk 1.4.x release, which is in security
fix only mode, so even though it's a bug, there won't be a new 1.4.x
release available with a fix for it.
--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kflem...@digium.com | SIP: kpflem...@digium.com | 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
