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] Authorization Header Values- vs REFER getting SIP 403 Authentication Failure

[Dale R. Worley]

Zuñiga, Guillermo  writes:
> Hi fellows,
> 
> I would like you can help me with the following doubt.
> 
> I am having a user is Registering ok to a Registrar Server.
> Seeing the authorization values I can see that we have the Authorization 
> Header wiht the following Authentication-URI value= sip:domain.com
> Realm = domain.com
> 
> But I am having a problem with REFER messages where the Registrar is sending 
> 403 Authentication Failure.
> Here I can see the Authorization header values are:
> Realm = domain.com
> Seeing the Authentication-URI value = sip:to-uri-user@dst-ipaddress
> 
> Could be the Registrar sending 403 cause the Authentication-URI should be 
> like the REGISTER value?
> Where I could find reference about the correct values of the Authorization 
> Header?

The standards do not prescribe what Authorization headers a server will
accept.

However, the usual practice is that the "uri" value has the form
"sip:UUU@DDD", where UUU is the user-part of the user's AOR and DDD is
the SIP domain, the "realm" value is the SIP domain, and the "username"
is UUU.  Of course, the "digest-uri-value" that is used in the
computation of the digest (RFC 3261 section 22.4) is the same as the
request-URI of the request containing the header (which is different for
different requests even if they originate from the same user).

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]

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"  > 
> >  > >;tag=1559

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", algorithm=M

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 understand