On 10/30/12 7:17 AM, Keerthi Srinivasan wrote:
> All,
>
> When UA sends REGISTER request to the server it does not contain the To-Tag
> and Server is accepts the Registration (200 OK) will have the To-Tag.
>
> If the Refresh or Deregister does not have the To-Tag in the REGISTER
> message.

REGISTER is peculiar. It uses to- and from- tags, callid, and CSeq like 
a dialog. But it otherwise isn't a true dialog.

This pseudo-dialog isn't of any great utility according to what is 
specified in 3261. There is nothing to prevent you from forgetting it 
and starting over with a new from-tag and callid in a subsequent 
REGISTER to refresh a particular contact. Doing so might bother some 
implementations even though it is conforming.

BUT, that "dialog" is significant to the way a registrar manages GRUUs. 
(RFC 5627). In particular it determines when temporary gruus expire.

> Is the server will accept the Refresh or Deregister REGISTER
> message or will send 482 Loop Detected as per the RFC3261 (8.2.2.2 Merged
> Requests)

Well, if you sent your refresh with the same from-tag and callid and 
cseq, and you sent it soon enough, then you *might* get caught up in 
this. But if you do that then you have a really broken implementation.

If you aren't setting up the registration pseudo-dialog state, including 
remembering from-tag, to-tag, callid, next valid cseq, etc., then when 
you send the next REGISTER you should be treating it as *new* and 
assigning a *new* from-tag, callid, and cseq.

        Thanks,
        Paul

> Here is the RFC3261 content:
> 8.2.2.2 Merged Requests
>
>     If the request has no tag in the To header field, the UAS core MUST
>     check the request against ongoing transactions.  If the From tag,
>     Call-ID, and CSeq exactly match those associated with an ongoing
>     transaction, but the request does not match that transaction (based
>     on the matching rules in Section 17.2.3), the UAS core SHOULD
>     generate a 482 (Loop Detected) response and pass it to the server
>     transaction.
>
>        The same request has arrived at the UAS more than once, following
>        different paths, most likely due to forking.  The UAS processes
>        the first such request received and responds with a 482 (Loop
>        Detected) to the rest of them.
>
> Is the Server MUST reject or Accept the Refresh / Deregister REGISTER
> request?
>

_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Reply via email to