[asterisk-users] Authenticated SUBSCRIBE and NOTIFY's R-URI

[Vladimir Broz]

Hello,

I've got a deployment with the SBC in between the clients and Asterisk
(11.17.1 version). When the UAC tries to subscribe for "dialog" event
package, the NOTIFY request sent by Asterisk fails.
The SBC uses a different Contact (user part) for the 1st and the 2nd
SUBSCRIBE (with Auth.).
The issue is that Asterisk sends the NOTIFY with R-URI of the first
SUBSCRIBE's Contact, not the 2nd one and SBC does not recognise this
request, as it would expect the NOTIFY with R-URI containing the 2nd
SUSBSCRIBE's Contact.
I would say Asterisk should use the 2nd Contact?

the log and trace:

SBC <-->  PBX (Asterisk)

--> 1st SUBSCRIBE:

SUBSCRIBE sip:1001 at testing.net SIP/2.0
...
CSeq: 1 SUBSCRIBE
Call-ID: 3d28dadd-87e5e749-1b7c8e1d at 192.168.1.133
Event: dialog
Expires: 3600
Contact: <sip:33F18ADD-554124D20004E0F0-6CB68700 at 10.0.0.32;transport=udp>

...

[2015-05-04 16:56:50] DEBUG[1948]: chan_sip.c:16341 build_route:
build_route: Contact hop: <sip:33F18ADD-554124D20004E0F0-6CB68700 at 10.0.0.32
;transport=udp>

<-- 401 unauthorized
--> 2nd SUBSCRIBE (authenticated):
SUBSCRIBE sip:1001 at testing.net SIP/2.0
...
CSeq: 2 SUBSCRIBE
Call-ID: 3d28dadd-87e5e749-1b7c8e1d at 192.168.1.133
Event: dialog
Authorization: Digest username="100", realm="asterisk", nonce="69f0a340",
uri="sip:1001 at testing.net", response="580f1a83fb04d58e2bc5cb9c4c531771",
algorithm=MD5
Expires: 3600
Contact: <sip:1D3BB238-554124D200064934-6C865700 at 10.0.0.32;transport=udp>

[2015-05-04 16:56:50] DEBUG[1948]: chan_sip.c:16259 build_route:
build_route: Retaining previous route: <
sip:1D3BB238-554124D200064934-6C865700 at 10.0.0.32;transport=udp>
...
[2015-05-04 16:56:50] DEBUG[1948]: chan_sip.c:11811 reqprep: Strict routing
enforced for session ...
...
set_destination: Parsing
<sip:33F18ADD-554124D20004E0F0-6CB68700 at 10.0.0.32;transport=udp>
for address/port to send to
...

<-- 200 OK
<-- NOTIFY:
NOTIFY sip:33F18ADD-554124D20004E0F0-6CB68700 at 10.0.0.32;transport=udp
SIP/2.0
...
Contact: <sip:1001 at 10.0.0.46:5060>
Call-ID: 3d28dadd-87e5e749-1b7c8e1d at 192.168.1.133
CSeq: 102 NOTIFY
....

--> 491 Call leg/Transaction does not exists


Why Asterisk does the "build_route: Retaining previous route:..." and
doesn't update it according to the 2nd SUBSCRIBE?

Thanks in advance for any hint,
-Vlada
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20150505/b0921882/attachment.html>