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, and gets a 200 OK reply from the UAS. It is the 200 OK that should contain the Record-Route header?
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? 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. On Tue, 23 Jul 2019 at 13:03, Paul Kyzivat <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> 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 > > -- 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
