[reSIProcate] Sub scribe contact

[Robert Sparks]

Christian -

I haven't seen any other responses to this, but may have missed it -
apologies if I'm duplicating.

With what you've described, resip is doing exactly the right thing.
In any dialog usage, the Contact from a dialog refreshing message
(a 200 OK to a SUBSCRIBE is such a message) updates the remote
target for the dialog. Subsequent requests will be sent to that URI.
If SER had included Contact of <sip:someTotallyDifferentServer.com>,
that's exactly where the refresh SUBSCRIBE will go. It would be a 
violation
of 3261 to change that URI (by, say, modifying the user part) when 
issuing
new requests on that dialog.

  If the thing handling SUBSCRIBE requests wants to see a username in the
RURI of subsequet refreshes, it had better provide one in its Contact.

A few other comments inline:

RjS


On Apr 11, 2005, at 1:42 PM, Christian_Gavin at logitech.com wrote:

> (reposting since anything with "subscribe" in the subject triggers
> moderator approval)
>
> Hi,
>
> I am currently using commit 4015 (not the very latest but I don't have 
> time
> to upgrade every day). I am playing with event notification for 
> presence
> and seeing the following:
>
> - My user agent test application REGISTERs a user on a server running 
> SER.
>
> - It sends a SUBSCRIBE for a user's presence (for ex.
> sip:foobar at myserver.com). The request line looks like SUBSCRIBE
> sip:foobar at myserver.com SIP/2.0
>
> - SER replies with a 200 OK where the contact header field is Contact:
> <sip:myserver.com> (I believe this is correct according to the RFCs)

SER can put any sip: URI it wants to here. The only constraint is that
the URI route (per 3263) to something that knows how to serve this 
particular
subscription (in particular, knows about this particular dialog).

>
> - DUM refreshes the subscription. On the second SUBSCRIBE, it uses the
> contact that was specified in the 200 OK and modifies the request 
> line. The
> request line now becomes
>
> SUBSCRIBE sip:myserver.com SIP/2.0
>
> This causes the SER server to terminate the subscription with 404 not
> found, since the user name is missing.
Just out of curiosity, did the refresh subscription have a non-empty 
To: tag?

I've seen SER work for this use case with DUM in the past (are you using
DUM or are you building this messages directly with the stack?)

>
> Is this the expected behavior?
> Shouldn't resiprocate add the user name to the contact?
>
> Thanks,
> CG
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel at list.sipfoundry.org
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel