Jun,
Generally speaking your SIP end is configured to it's local registrar
for the domain, so a part from the multicast to unicast example in RFC3261
you may not see a registrar send a 302, I haven't, but that isn't to say it
can't happen or that it is wrong if it does.
Two examples I can think of which might be relevant 1) if you have
multiple registrars for your domain and one is under heavy load it could
send a 302 back to the UA to direct the regsistration to the other server
2) if for some reason your registration was directed at a registrar that is
NOT responsible for your domain and assuming it knows a registrar that is,
it could redirect the UA as well.
Hope the above is accurate and somewhat helpful. - Wayne
Jun asked:
****************************************************
Hi,
Can the REGISTER method be redirected ?
I actually read the RFC3261 and it wrote as follows;
" A registrar MAY redirect REGISTER requests as appropriate. One
common usage would be for a registrar listening on a multicast
interface to redirect multicast REGISTER requests to its own unicast
interface with a 302 (Moved Temporarily) response."
But the phrase is very ambigiuos, What happens if a SIP phone sends out
REGISTER method to a unicast registrar server - this is not an common usage
as mentioned above - and gets 302 temporary moved with a different uri ?
Is the SIP phone supposed to send out another REGISTER method to the
different registrar server ?
Is it the scenario that most of vendors implemented ?
Regards,
Jun
**********************************************************************
Any personal or sensitive information contained in this email and
attachments must be handled in accordance with the Victorian Information
Privacy Act 2000, the Health Records Act 2001 or the Privacy Act 1988
(Commonwealth), as applicable.
This email, including all attachments, is confidential. If you are not the
intended recipient, you must not disclose, distribute, copy or use the
information contained in this email or attachments. Any confidentiality or
privilege is not waived or lost because this email has been sent to you in
error. If you have received it in error, please let us know by reply
email, delete it from your system and destroy any copies.
**********************************************************************
_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
