Though I notice that RFC 6665 4.4.1 also says:
unless the NOTIFY request contains a "Subscription-State" of
"terminated."
And in our case the subscription state is "terminated". The dialog is then
over, so I guess that the other RFCs then apply.
On Thu, 25 Jul 2019 at 21:43, David Cunningham <dcunning...@voisonics.com>
wrote:
>
> Thank you Paul, and thank you Richard.
>
> I must say RFC 6665 4.4.1 does seem to make it clear that the route set
in the NOTIFY should be used, and therefore it's incorrect that the
re-SUBSCRIBE sends directly to the Contact address rather than using the
Record-Routes in the NOTIFY. It's very helpful to have this knowledge as a
reference!
>
>
> On Thu, 25 Jul 2019 at 00:01, Paul Kyzivat <pkyzi...@alum.mit.edu> wrote:
>>
>> On 7/23/19 7:38 PM, David Cunningham wrote:
>> > Hi Paul,
>> >
>> > I'd just like to check my understanding of your reply. The first
>> > SUBSCRIBE is from the UAC sip:1111113...@es8.example.com
>> > <mailto:sip%3a1111113...@es8.example.com>, and gets a 200 OK reply from
>> > the UAS. It is the 200 OK that should contain the Record-Route header?
>>
>> The normal process is that as the *request* is forwarded from the UAC
>> through proxies and on to the UAS, each proxy along the way has the
>> opportunity to add itself to the Record-Route header (or add the header
>> if one isn't already there). When it reaches the UAS, it should then
>> copy the Record-Route into response - both provisional and 2xx. This
>> then normally flows unchanged through all the proxies back to the UAC.
>>
>> The contents of the Record-Route then become the "route set" at both the
>> UAC and UAS, together with the Contact URL from the other end.
>>
>> (The above it typical. In exotic cases the UAC and/or the UAS may also
>> add one or more entries on the R-R, and entries might be added or
>> changed on the R-R in response as it returns. But these are unusual.)
>>
>> > And would that then oblige the UAC to use that route on all future
>> > transactions, even if the UAS sends a request (in this case a notify)
>> > which changes it's Contact address?
>>
>> The route-set remains unchanged for the duration of the dialog, but the
>> Contact address of the other end can change.
>>
>> > If you happen know which part of the RFC specifies this would be be
good
>> > to know. Thank you again for your help on this.
>>
>> This is all in 3261, but scattered around. Just search for Record-Route
>> and "route set".
>>
>> There are other mechanisms that might be of interest to you. Check out
>> the Path [RFC3327] and Service-Route [RFC3608] header fields. These
>> affect the Route used for *out of dialog* requests. If those requests
>> establish a dialog then Record-Route is still used to establish the
>> route set for subsequent in-dialog requests.
>>
>> Thanks,
>> Paul
>>
>> > On Tue, 23 Jul 2019 at 13:03, Paul Kyzivat <pkyzi...@alum.mit.edu
>> > <mailto:pkyzi...@alum.mit.edu>> 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
>> > <mailto:sip%3a1111113...@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>
>> > > <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>
>> > > <mailto:sip%3a1111113...@es8.example.com
>> > <mailto:sip%253a1111113...@es8.example.com
>>>;tag=Nf5GGb2cl6tUMcx2B18758F8644a2998
>> > > To: "798" <sip:7...@es8.example.com:5061
>> > <http://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>
>> > <http://es8.example.com>",
>> > > nonce="XPWf2Fz1nqyIJkgVG+Nm6jXXume5Pekp",
>> > uri="sip:798@192.168.3.1 <mailto:sip%3A798@192.168.3.1>
>> > > <mailto:sip%3A798@192.168.3.1 <mailto:sip%253A798@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>
>> > > <http://sip:7...@es8.example.com:5061>>;tag=155960081226925
>> > > From: ES8 Test 104 <sip:1111113...@es8.example.com
>> > <mailto:sip%3a1111113...@es8.example.com>
>> > > <mailto:sip%3a1111113...@es8.example.com
>> > <mailto:sip%253a1111113...@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>
>> > > <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>
>> > > <http://sip:7...@es8.example.com:5061>>;tag=155960081226925
>> > > To: <sip:1111113...@es8.example.com
>> > <mailto:sip%3a1111113...@es8.example.com>
>> > > <mailto:sip%3a1111113...@es8.example.com
>> > <mailto:sip%253a1111113...@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>
>> > > <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>
>> > > <http://sip:7...@es8.example.com:5061>>;tag=155960081226925
>> > > To: <sip:1111113...@es8.example.com
>> > <mailto:sip%3a1111113...@es8.example.com>
>> > > <mailto:sip%3a1111113...@es8.example.com
>> > <mailto:sip%253a1111113...@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>
>> > > <mailto:sip%3a1111113...@es8.example.com
>> > <mailto:sip%253a1111113...@es8.example.com
>>>;tag=Nf5GGb2cl6tUMcx2B18758F8644a2998
>> > > To: "798" <sip:7...@es8.example.com:5061
>> > <http://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>
>> > > <mailto: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>
>> > > <mailto: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>
>> > > <mailto: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
>> >
>> >
>> >
>> > --
>> > David Cunningham, Voisonics Limited
>> > http://voisonics.com/
>> > USA: +1 213 221 1092
>> > New Zealand: +64 (0)28 2558 3782
>>
>
>
> --
> David Cunningham, Voisonics Limited
> http://voisonics.com/
> USA: +1 213 221 1092
> New Zealand: +64 (0)28 2558 3782
--
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
