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