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 _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
