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

[David Cunningham]

Hi Paul and Dale,

I just wanted to say thank you for the updates. We haven't got a fully
working solution yet so are not completely sure what the fix will be, but
your input has helped guide our investigation a lot.


On Fri, 26 Jul 2019 at 15:11, Dale R. Worley  wrote:

> David Cunningham  writes:
> > 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!
>
> But don't overlook the 2nd paragraph of section 4.3:
>
>Proxies that did not add a "Record-Route" header field to the initial
>SUBSCRIBE request MUST NOT add a "Record-Route" header field to any
>of the associated NOTIFY requests.
>
> My vague memory is that while the passage of the first NOTIFY request of
> a subscription creates the subscription usage, the intermediate proxies
> are required to insert Record-Routes into it in exactly the same way
> they inserted Record-Routes into the SUBSCRIBE.  In particular, when the
> subscriber receives a 2xx response, it can act as if that subscription
> usage has been created and be assured that it will handle the dialog
> correctly.  Further NOTIFYs that it receives create other subscription
> usages based on their contents.
>
> If I understand your example correctly, it was taken at the subscriber.
> I see that the 200 response to the SUBSCRIBE contains no Record-Route
> headers, so none of the proxies in the path have chosen to insert
> themselves into dialog.  However, the first NOTIFY contains two
> Record-Route headers, which violate section 4.3.
>
> It appears the subscriber has refreshed its remote target based on the
> Contact header of the NOTIFY, which it is required to do.  But it has
> not recorded the Record-Route headers from the NOTIFY, which should not
> be there.
>
> Dale
>


-- 
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

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

[Dale R. Worley]

David Cunningham  writes:
> 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!

But don't overlook the 2nd paragraph of section 4.3:

   Proxies that did not add a "Record-Route" header field to the initial
   SUBSCRIBE request MUST NOT add a "Record-Route" header field to any
   of the associated NOTIFY requests.

My vague memory is that while the passage of the first NOTIFY request of
a subscription creates the subscription usage, the intermediate proxies
are required to insert Record-Routes into it in exactly the same way
they inserted Record-Routes into the SUBSCRIBE.  In particular, when the
subscriber receives a 2xx response, it can act as if that subscription
usage has been created and be assured that it will handle the dialog
correctly.  Further NOTIFYs that it receives create other subscription
usages based on their contents.

If I understand your example correctly, it was taken at the subscriber.
I see that the 200 response to the SUBSCRIBE contains no Record-Route
headers, so none of the proxies in the path have chosen to insert
themselves into dialog.  However, the first NOTIFY contains two
Record-Route headers, which violate section 4.3.

It appears the subscriber has refreshed its remote target based on the
Contact header of the NOTIFY, which it is required to do.  But it has
not recorded the Record-Route headers from the NOTIFY, which should not
be there.

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

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

[David Cunningham]

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 
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  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:113...@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 > > > 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 > > > will add
>> > it to the reSUBSCRIBE as a Route header.
>> >
>> >  Thanks,
>> >  Paul
>> >
>> >  > SUBSCRIBE sip:7...@es8.example.com:5061
>> > 
>> >  >  SIP/2.0
>> >  > Via: SIP/2.0/TLS xx.xx.xx.10:5061;branch=z9hG4bK1954587875
>> >  > Route: 
>> >  > From: ES8 Test 104 > > 
>> >  > > > >>;tag=Nf5GGb2cl6tUMcx2B18758F8644a2998
>> >  > To: "798" > > 
>> >  > >
>> >  > Call-ID: 1552952...@xx.xx.xx.10
>> >  > CSeq: 876 SUBSCRIBE
>> >  > Contact: 
>> >  > Supported: eventlist, 100rel
>> >  > Proxy-Authorization: Digest username="113368",
>> >  > realm="es8.example.com 
>> > ",
>> >  > nonce="XPWf2Fz1nqyIJkgVG+Nm6jXXume5Pekp",
>> > uri="sip:798@192.168.3.1 
>> >  > >",
>> >  > response="a480f0356c0654435c742114dfe8c4da", 

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

[David Cunningham]

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  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:113...@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  > > 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  > > will add
> > it to the reSUBSCRIBE as a Route header.
> >
> >  Thanks,
> >  Paul
> >
> >  > SUBSCRIBE sip:7...@es8.example.com:5061
> > 
> >  >  SIP/2.0
> >  > Via: SIP/2.0/TLS xx.xx.xx.10:5061;branch=z9hG4bK1954587875
> >  > Route: 
> >  > From: ES8 Test 104  > 
> >  >  >  >>>;tag=Nf5GGb2cl6tUMcx2B18758F8644a2998
> >  > To: "798"  > 
> >  > >
> >  > Call-ID: 1552952...@xx.xx.xx.10
> >  > CSeq: 876 SUBSCRIBE
> >  > Contact: 
> >  > Supported: eventlist, 100rel
> >  > Proxy-Authorization: Digest username="113368",
> >  > realm="es8.example.com 
> > ",
> >  > nonce="XPWf2Fz1nqyIJkgVG+Nm6jXXume5Pekp",
> > uri="sip:798@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"  > 
> >  > 

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

[Paul Kyzivat]

On 7/25/19 5:53 AM, David Cunningham wrote:

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.


Hmm. I forgot that 6665 did some funky things to this process. It is an 
update to rfc3265 and was intended to resolve some problems that cropped 
up with 3265. Moving the establishment of the route set to the notify 
means that you don't have one between the receipt of the 2xx and the 
NOTIFY. One of the reasons for this is that the NOTIFY might have been 
forked, but only one 2xx response can be returned, but every fork could 
send a NOTIFY, each establishing a separate dialog. This means that the 
Record-Route in the first NOTIFY (if non-"terminated") needs to be the 
same as sent in the 2xx of the SUBSCRIBE. Meanwhile that is also used as 
the Route put into the NOTIFY by the notifier.


What I told you is correct for non-SUBSCRIBE dialogs (IOW, INVITE 
dialogs). Any servers on the path that would normally update the 
Record-Route in the 2xx response to the SUBSCRIBE will also need to make 
those same changes to the Record-Route in the NOTIFY.


The "terminated" does mean the dialog is ended (or was never 
established), so your subsequent SUBSCRIBE should start over with a new 
from-tag and no to-tag.


Sorry for forgetting about 6665.

Thanks,
Paul

On Thu, 25 Jul 2019 at 21:43, David Cunningham 
mailto: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 > 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:113...@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 

 >> > >> 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 

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

[Paul Kyzivat]

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:113...@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 > 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 mailto:sip%3a113...@es8.example.com>> will add
it to the reSUBSCRIBE as a Route header.

         Thanks,
         Paul

 > SUBSCRIBE sip:7...@es8.example.com:5061

 >  SIP/2.0
 > Via: SIP/2.0/TLS xx.xx.xx.10:5061;branch=z9hG4bK1954587875
 > Route: 
 > From: ES8 Test 104 mailto:sip%3a113...@es8.example.com>
 > >>;tag=Nf5GGb2cl6tUMcx2B18758F8644a2998
 > To: "798" http://sip:7...@es8.example.com:5061>
 > >
 > Call-ID: 1552952...@xx.xx.xx.10
 > CSeq: 876 SUBSCRIBE
 > Contact: 
 > Supported: eventlist, 100rel
 > Proxy-Authorization: Digest username="113368",
 > realm="es8.example.com 
",
 > nonce="XPWf2Fz1nqyIJkgVG+Nm6jXXume5Pekp",
uri="sip:798@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" http://sip:7...@es8.example.com:5061>
 > >;tag=155960081226925
 > From: ES8 Test 104 mailto:sip%3a113...@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: http://sip:7...@es8.example.com:5061>
 > >
 > User-Agent: Example SIP server
 > Content-Length: 0
 >
 >
 > NOTIFY sip:113...@xx.xx.xx.10:53426;transport=tls SIP/2.0
 > Max-Forwards: 10
 > Record-Route: 
 > Record-Route: 
 > Via: SIP/2.0/TLS
 >

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

[Richard Phernambucq]

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  will 
add it to the reSUBSCRIBE as a Route header.


Thanks,
Paul

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

Via: SIP/2.0/TLS xx.xx.xx.10:5061;branch=z9hG4bK1954587875
Route: 
From: ES8 Test 104 >;tag=Nf5GGb2cl6tUMcx2B18758F8644a2998
To: "798" >

Call-ID: 1552952...@xx.xx.xx.10
CSeq: 876 SUBSCRIBE
Contact: 
Supported: eventlist, 100rel
Proxy-Authorization: Digest username="113368", 
realm="es8.example.com ", 
nonce="XPWf2Fz1nqyIJkgVG+Nm6jXXume5Pekp", uri="sip:798@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" >;tag=155960081226925
From: ES8 Test 104 >;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: >

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


NOTIFY sip:113...@xx.xx.xx.10:53426;transport=tls SIP/2.0
Max-Forwards: 10
Record-Route: 
Record-Route: 
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: >;tag=155960081226925
To: >;tag=Nf5GGb2cl6tUMcx2B18758F8644a2998

Contact: 
Call-ID: 1552952...@xx.xx.xx.10
CSeq: 901 NOTIFY
User-Agent: Example presence server
Event: dialog
Subscription-State: active;expires=299
Content-Type: application/dialog-info+xml
Content-Length: 271


state="full" entity="sip:7...@es8.example.com:5061 
">


terminated




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: 
Record-Route: 
From: >;tag=155960081226925
To: >;tag=Nf5GGb2cl6tUMcx2B18758F8644a2998

Call-ID: 1552952...@xx.xx.xx.10
CSeq: 901 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 >;tag=Nf5GGb2cl6tUMcx2B18758F8644a2998
To: "798" >;tag=155960081226925

Call-ID: 1552952...@xx.xx.xx.10
CSeq: 877 SUBSCRIBE
Contact: 
Max-Forwards: 70
User-Agent: ewb2bua/15.4.3Alpha.2019053
Event: dialog

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

[David Cunningham]

Hi Paul,

I'd just like to check my understanding of your reply. The first SUBSCRIBE
is from the UAC sip:113...@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  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  will add
> it to the reSUBSCRIBE as a Route header.
>
> Thanks,
> Paul
>
> > SUBSCRIBE sip:7...@es8.example.com:5061
> >  SIP/2.0
> > Via: SIP/2.0/TLS xx.xx.xx.10:5061;branch=z9hG4bK1954587875
> > Route: 
> > From: ES8 Test 104  >  >>;tag=Nf5GGb2cl6tUMcx2B18758F8644a2998
> > To: "798"  > >
> > Call-ID: 1552952...@xx.xx.xx.10
> > CSeq: 876 SUBSCRIBE
> > Contact: 
> > Supported: eventlist, 100rel
> > Proxy-Authorization: Digest username="113368",
> > realm="es8.example.com ",
> > nonce="XPWf2Fz1nqyIJkgVG+Nm6jXXume5Pekp", uri="sip:798@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"  > >;tag=155960081226925
> > From: ES8 Test 104  >  >>;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:  > >
> > User-Agent: Example SIP server
> > Content-Length: 0
> >
> >
> > NOTIFY sip:113...@xx.xx.xx.10:53426;transport=tls SIP/2.0
> > Max-Forwards: 10
> > Record-Route: 
> > Record-Route: 
> > 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:  > >;tag=155960081226925
> > To:  >  >>;tag=Nf5GGb2cl6tUMcx2B18758F8644a2998
> > Contact: 
> > Call-ID: 1552952...@xx.xx.xx.10
> > CSeq: 901 NOTIFY
> > User-Agent: Example presence server
> > Event: dialog
> > Subscription-State: active;expires=299
> > Content-Type: application/dialog-info+xml
> > Content-Length: 271
> >
> > 
> >  > state="full" entity="sip:7...@es8.example.com:5061
> > ">
> > 
> > terminated
> > 
> > 
> >
> >
> > 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: 
> > Record-Route: 
> > From:  > >;tag=155960081226925
> > To:  >  >>;tag=Nf5GGb2cl6tUMcx2B18758F8644a2998
> > Call-ID: 1552952...@xx.xx.xx.10
> > CSeq: 901 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  >  >>;tag=Nf5GGb2cl6tUMcx2B18758F8644a2998
> > To: "798"  > >;tag=155960081226925
> > Call-ID: 1552952...@xx.xx.xx.10
> > CSeq: 877 SUBSCRIBE
> > Contact: 
> > 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  > > 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
> >

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

[David Cunningham]

Thank you very much Paul, we'll try that.


On Tue, 23 Jul 2019 at 13: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  will add
> it to the reSUBSCRIBE as a Route header.
>
> Thanks,
> Paul
>
> > SUBSCRIBE sip:7...@es8.example.com:5061
> >  SIP/2.0
> > Via: SIP/2.0/TLS xx.xx.xx.10:5061;branch=z9hG4bK1954587875
> > Route: 
> > From: ES8 Test 104  >  >>;tag=Nf5GGb2cl6tUMcx2B18758F8644a2998
> > To: "798"  > >
> > Call-ID: 1552952...@xx.xx.xx.10
> > CSeq: 876 SUBSCRIBE
> > Contact: 
> > Supported: eventlist, 100rel
> > Proxy-Authorization: Digest username="113368",
> > realm="es8.example.com ",
> > nonce="XPWf2Fz1nqyIJkgVG+Nm6jXXume5Pekp", uri="sip:798@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"  > >;tag=155960081226925
> > From: ES8 Test 104  >  >>;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:  > >
> > User-Agent: Example SIP server
> > Content-Length: 0
> >
> >
> > NOTIFY sip:113...@xx.xx.xx.10:53426;transport=tls SIP/2.0
> > Max-Forwards: 10
> > Record-Route: 
> > Record-Route: 
> > 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:  > >;tag=155960081226925
> > To:  >  >>;tag=Nf5GGb2cl6tUMcx2B18758F8644a2998
> > Contact: 
> > Call-ID: 1552952...@xx.xx.xx.10
> > CSeq: 901 NOTIFY
> > User-Agent: Example presence server
> > Event: dialog
> > Subscription-State: active;expires=299
> > Content-Type: application/dialog-info+xml
> > Content-Length: 271
> >
> > 
> >  > state="full" entity="sip:7...@es8.example.com:5061
> > ">
> > 
> > terminated
> > 
> > 
> >
> >
> > 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: 
> > Record-Route: 
> > From:  > >;tag=155960081226925
> > To:  >  >>;tag=Nf5GGb2cl6tUMcx2B18758F8644a2998
> > Call-ID: 1552952...@xx.xx.xx.10
> > CSeq: 901 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  >  >>;tag=Nf5GGb2cl6tUMcx2B18758F8644a2998
> > To: "798"  > >;tag=155960081226925
> > Call-ID: 1552952...@xx.xx.xx.10
> > CSeq: 877 SUBSCRIBE
> > Contact: 
> > 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  > > 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
> > 

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

[Paul Kyzivat]

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  will add 
it to the reSUBSCRIBE as a Route header.


Thanks,
Paul

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

Via: SIP/2.0/TLS xx.xx.xx.10:5061;branch=z9hG4bK1954587875
Route: 
From: ES8 Test 104 >;tag=Nf5GGb2cl6tUMcx2B18758F8644a2998
To: "798" >

Call-ID: 1552952...@xx.xx.xx.10
CSeq: 876 SUBSCRIBE
Contact: 
Supported: eventlist, 100rel
Proxy-Authorization: Digest username="113368", 
realm="es8.example.com ", 
nonce="XPWf2Fz1nqyIJkgVG+Nm6jXXume5Pekp", uri="sip:798@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" >;tag=155960081226925
From: ES8 Test 104 >;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: >

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


NOTIFY sip:113...@xx.xx.xx.10:53426;transport=tls SIP/2.0
Max-Forwards: 10
Record-Route: 
Record-Route: 
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: >;tag=155960081226925
To: >;tag=Nf5GGb2cl6tUMcx2B18758F8644a2998

Contact: 
Call-ID: 1552952...@xx.xx.xx.10
CSeq: 901 NOTIFY
User-Agent: Example presence server
Event: dialog
Subscription-State: active;expires=299
Content-Type: application/dialog-info+xml
Content-Length: 271


state="full" entity="sip:7...@es8.example.com:5061 
">


terminated




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: 
Record-Route: 
From: >;tag=155960081226925
To: >;tag=Nf5GGb2cl6tUMcx2B18758F8644a2998

Call-ID: 1552952...@xx.xx.xx.10
CSeq: 901 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 >;tag=Nf5GGb2cl6tUMcx2B18758F8644a2998
To: "798" >;tag=155960081226925

Call-ID: 1552952...@xx.xx.xx.10
CSeq: 877 SUBSCRIBE
Contact: 
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 > 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 

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

[David Cunningham]

Hi Paul,

Thank you for the reply. Below is the full exchange, which hopefully makes
things clearer. 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?

SUBSCRIBE sip:7...@es8.example.com:5061 SIP/2.0
Via: SIP/2.0/TLS xx.xx.xx.10:5061;branch=z9hG4bK1954587875
Route: 
From: ES8 Test 104 ;tag=Nf5GGb2cl6tUMcx2B18758F8644a2998
To: "798" 
Call-ID: 1552952...@xx.xx.xx.10
CSeq: 876 SUBSCRIBE
Contact: 
Supported: eventlist, 100rel
Proxy-Authorization: Digest username="113368", realm="es8.example.com",
nonce="XPWf2Fz1nqyIJkgVG+Nm6jXXume5Pekp", uri="sip:798@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" ;tag=155960081226925
From: ES8 Test 104 ;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: 
User-Agent: Example SIP server
Content-Length: 0


NOTIFY sip:113...@xx.xx.xx.10:53426;transport=tls SIP/2.0
Max-Forwards: 10
Record-Route: 
Record-Route: 
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: ;tag=155960081226925
To: ;tag=Nf5GGb2cl6tUMcx2B18758F8644a2998
Contact: 
Call-ID: 1552952...@xx.xx.xx.10
CSeq: 901 NOTIFY
User-Agent: Example presence server
Event: dialog
Subscription-State: active;expires=299
Content-Type: application/dialog-info+xml
Content-Length: 271




terminated




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: 
Record-Route: 
From: ;tag=155960081226925
To: ;tag=Nf5GGb2cl6tUMcx2B18758F8644a2998
Call-ID: 1552952...@xx.xx.xx.10
CSeq: 901 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 ;tag=Nf5GGb2cl6tUMcx2B18758F8644a2998
To: "798" ;tag=155960081226925
Call-ID: 1552952...@xx.xx.xx.10
CSeq: 877 SUBSCRIBE
Contact: 
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  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
> > 

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

[Paul Kyzivat]

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
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