< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index  

Re: [reSIProcate] Sub scribe contact


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@xxxxxxxxxxxx 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@xxxxxxxxxxxx). The request line looks like SUBSCRIBE
sip:foobar@xxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel