Keerthi,     Your answer lies in section 8.2,2,2 itself. The re-register or 
de-register will have a different Via branch and incremental CSeq number. That 
will make that request unique and will not cause the end server to return a 482 
loop detected.
Santosh

--- On Tue, 10/30/12, Keerthi Srinivasan <[email protected]> 
wrote:

From: Keerthi Srinivasan <[email protected]>
Subject: [SIPForum-discussion] To-Tag in REGISTER message
To: [email protected], [email protected]
Date: Tuesday, October 30, 2012, 4:47 PM

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


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?

-- 
Regards,
Keerthi


-----Inline Attachment Follows-----

_______________________________________________
This is the SIP Forum discussion mailing list
TO UNSUBSCRIBE, or edit your delivery options, please visit 
http://sipforum.org/mailman/listinfo/discussion
Post to the list at [email protected]
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Reply via email to