Re: [Sip-implementors] NOTIFY and Record-Route

Wed, 24 Jul 2019 02:45:11 -0700 

Hi all,
Sorry, but I am a bit confused here. I hope someone can clarify things for me. 


According to RFC 6665 4.4.1 the subscribe dialog (usage) is created when 
the first NOTIFY request is received by the subscriber and the 
record-route set (if present) is taken as route set for the dialog:


   Dialogs usages are created upon completion of a NOTIFY transaction
   for a new subscription, unless the NOTIFY request contains a
   "Subscription-State" of "terminated."

   Because the dialog usage is established by the NOTIFY request, the
   route set at the subscriber is taken from the NOTIFY request itself,
   as opposed to the route set present in the 200-class response to the
   SUBSCRIBE request.

As I understand it that would mean the re-SUBSCRIBE request:

-has Request-URI 'sip:7...@yy.yy.yy.146:56095', taken from the Contact 
header of the NOTIFY request
-has a Route set identical to the Record-Route set of the NOTIFY request 
(and is therefore different to the Route set in the original SUBSCRIBE 
request)
-will be sent to the first Route value in the re-SUBSCRIBE request, in 
this case IP address 'yy.yy.yy.146' and port '5061' (RFC 3261 8.1.2)



I don't understand why the re-SUBSCRIBE request would be sent to port 
53426, which seems to be the port the subscriber can be reached at by 
the notifier.


Thank you for your time and any clarifications.

Best regards,
Richard Phernambucq


On 23-7-2019 03:03, Paul Kyzivat wrote:

On 7/22/19 7:09 PM, David Cunningham wrote:

Hi Paul,


Thank you for the reply. Below is the full exchange, which hopefully 
makes things clearer.


Yes it does.


Ultimately the problem is the SUBSCRIBE at the end which is being 
sent to port 53426 - is it correct because it's going to the Contact 
address in the NOTIFY, or is it incorrect because it's not following 
the Record-Route?


To the best of my understanding it is correct.


To get the effect you seem to be going for, the proxy at 
sip:yy.yy.yy.146:5061 should add a Record-Route with its own URL to 
the first SUBSCRIBE. Then the UA <sip:1111113...@es8.example.com> will 
add it to the reSUBSCRIBE as a Route header.


    Thanks,
    Paul


SUBSCRIBE sip:7...@es8.example.com:5061 
<http://sip:7...@es8.example.com:5061> SIP/2.0

Via: SIP/2.0/TLS xx.xx.xx.10:5061;branch=z9hG4bK1954587875
Route: <sip:yy.yy.yy.146:5061;transport=tls;lr>

From: ES8 Test 104 <sip:1111113...@es8.example.com 
<mailto:sip%3a1111113...@es8.example.com>>;tag=Nf5GGb2cl6tUMcx2B18758F8644a2998
To: "798" <sip:7...@es8.example.com:5061 
<http://sip:7...@es8.example.com:5061>>

Call-ID: 1552952...@xx.xx.xx.10
CSeq: 876 SUBSCRIBE
Contact: <sip:1111113...@xx.xx.xx.10:5061;transport=tls>
Supported: eventlist, 100rel

Proxy-Authorization: Digest username="1111113368", 
realm="es8.example.com <http://es8.example.com>", 
nonce="XPWf2Fz1nqyIJkgVG+Nm6jXXume5Pekp", uri="sip:798@192.168.3.1 
<mailto:sip%3A798@192.168.3.1>", 
response="a480f0356c0654435c742114dfe8c4da", algorithm=MD5

Max-Forwards: 70
User-Agent: ewb2bua/15.4.3Alpha.2019053
Event: dialog
Expires: 300
Allow: UPDATE, REFER
Accept: application/dialog-info+xml
Content-Length: 0


SIP/2.0 200 OK

To: "798" <sip:7...@es8.example.com:5061 
<http://sip:7...@es8.example.com:5061>>;tag=155960081226925
From: ES8 Test 104 <sip:1111113...@es8.example.com 
<mailto:sip%3a1111113...@es8.example.com>>;tag=Nf5GGb2cl6tUMcx2B18758F8644a2998

Via: SIP/2.0/TLS xx.xx.xx.10:5061;rport=53426;branch=z9hG4bK1954587875
Call-ID: 1552952...@xx.xx.xx.10
CSeq: 876 SUBSCRIBE
Expires: 300

Contact: <sip:7...@es8.example.com:5061 
<http://sip:7...@es8.example.com:5061>>

User-Agent: Example SIP server
Content-Length: 0


NOTIFY sip:1111113...@xx.xx.xx.10:53426;transport=tls SIP/2.0
Max-Forwards: 10
Record-Route: <sip:yy.yy.yy.146:5061;transport=tls;r2=on;lr=on>
Record-Route: <sip:yy.yy.yy.146;r2=on;lr=on>

Via: SIP/2.0/TLS 
yy.yy.yy.146:5061;branch=z9hG4bK4b91.0cf32b66d634969dec31117b9c120464.0
Via: SIP/2.0/UDP 
127.0.0.1;rport=56095;received=yy.yy.yy.146;branch=z9hG4bKCkq6GHVlo4
From: <sip:7...@es8.example.com:5061 
<http://sip:7...@es8.example.com:5061>>;tag=155960081226925
To: <sip:1111113...@es8.example.com 
<mailto:sip%3a1111113...@es8.example.com>>;tag=Nf5GGb2cl6tUMcx2B18758F8644a2998

Contact: <sip:7...@yy.yy.yy.146:56095>
Call-ID: 1552952...@xx.xx.xx.10
CSeq: 9017777 NOTIFY
User-Agent: Example presence server
Event: dialog
Subscription-State: active;expires=299
Content-Type: application/dialog-info+xml
Content-Length: 271

<?xml version="1.0" encoding="UTF-8"?>

<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="0" 
state="full" entity="sip:7...@es8.example.com:5061 
<http://sip:7...@es8.example.com:5061>">

<dialog id="1552952...@xx.xx.xx.10" direction="recipient">
<state>terminated</state>
</dialog>
</dialog-info>


SIP/2.0 200 OK

Via: SIP/2.0/TLS 
yy.yy.yy.146:5061;branch=z9hG4bK4b91.0cf32b66d634969dec31117b9c120464.0
Via: SIP/2.0/UDP 
127.0.0.1;rport=56095;received=yy.yy.yy.146;branch=z9hG4bKCkq6GHVlo4

Record-Route: <sip:yy.yy.yy.146:5061;transport=tls;r2=on;lr=on>
Record-Route: <sip:yy.yy.yy.146;r2=on;lr=on>

From: <sip:7...@es8.example.com:5061 
<http://sip:7...@es8.example.com:5061>>;tag=155960081226925
To: <sip:1111113...@es8.example.com 
<mailto:sip%3a1111113...@es8.example.com>>;tag=Nf5GGb2cl6tUMcx2B18758F8644a2998

Call-ID: 1552952...@xx.xx.xx.10
CSeq: 9017777 NOTIFY
Content-Length: 0


SUBSCRIBE sip:7...@yy.yy.yy.146:56095 SIP/2.0
Via: SIP/2.0/TLS xx.xx.xx.10:5061;branch=z9hG4bK1045495431

From: ES8 Test 104 <sip:1111113...@es8.example.com 
<mailto:sip%3a1111113...@es8.example.com>>;tag=Nf5GGb2cl6tUMcx2B18758F8644a2998
To: "798" <sip:7...@es8.example.com:5061 
<http://sip:7...@es8.example.com:5061>>;tag=155960081226925

Call-ID: 1552952...@xx.xx.xx.10
CSeq: 877 SUBSCRIBE
Contact: <sip:1111113...@xx.xx.xx.10:5061;transport=tls>
Max-Forwards: 70
User-Agent: ewb2bua/15.4.3Alpha.2019053
Event: dialog
Expires: 300
Content-Length: 0



On Tue, 23 Jul 2019 at 04:54, Paul Kyzivat <pkyzi...@alum.mit.edu 
<mailto:pkyzi...@alum.mit.edu>> wrote:


    Inline

    On 7/21/19 6:42 PM, David Cunningham wrote:
     > Hello,
     >
     > We have the following issue and are looking for some advice on
    the expected
     > behaviour:
     >
     > 1. UAC sends SUBSCRIBE to UAS at x.x.x.x:5061, receives 200 OK in
    response.
     > 2. UAS sends NOTIFY to UAC with Record-Route x.x.x.x:5061, Via

     > x.x.x.x:5061, and Contact x.x.x.x:56095, receives 200 OK in 
response.
     > 3. UAC sends SUBSCRIBE to UAS at x.x.x.x:56095, receives no 
response

     > because port is not accessible directly from the UAC.
     >
     > These are all within one dialog. RFC 3261 12.2 says:
     >
     >     Requests within a dialog MAY contain Record-Route and Contact
    header
     >     fields.  However, these requests do not cause the dialog's
    route set

     >     to be modified, although they may modify the remote target 
URI.

     >     Specifically, requests that are not target refresh requests
    do not
     >     modify the dialog's remote target URI, and requests that are
    target
     >     refresh requests do.
     >
     > The NOTIFY is a target refresh request, so presumably the remote
    target URI
     > is then considered to be x.x.x.x:56095 as specified in the
    Contact header.
     >

     > But dos the Record-Route in the NOTIFY really have no effect 
on the
     > subsequent SUBSCRIBE? Can the NOTIFY not tell the UAS to route 
via

     > x.x.x.x:5061 instead of sending to x.x.x.x:56095 directly?

    Your example is hard to understand because of the repeated use of
    x.x.x.x - it isn't clear if all instances of that are intended to be
    the

    same or if each is intended to carry different values. Please 
restate
    your problem, showing exactly what changes in the NOTIFY and what 
stays

    the same.

    But for your basic question, the route set for a dialog is finalized
    during dialog establishment. Subsequently only the addresses of the

    endpoints can be changed. If you need to change the route set you 
can
    send an INVITE/Replaces or a REFER/Replaces to establish a 
totally new

    dialog to replace the old one.

             Thanks,
             Paul

     > Thank you in advance!
     >
     > --
     > David Cunningham, Voisonics Limited
     > http://voisonics.com/
     > USA: +1 213 221 1092
     > New Zealand: +64 (0)28 2558 3782
     > _______________________________________________
     > Sip-implementors mailing list
     > Sip-implementors@lists.cs.columbia.edu
    <mailto:Sip-implementors@lists.cs.columbia.edu>
     > https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
     >

    _______________________________________________
    Sip-implementors mailing list
    Sip-implementors@lists.cs.columbia.edu
    <mailto:Sip-implementors@lists.cs.columbia.edu>
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors



--
David Cunningham, Voisonics Limited
http://voisonics.com/
USA: +1 213 221 1092
New Zealand: +64 (0)28 2558 3782


_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors


_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
























					Reply via email to