[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Sip] Open Issue #179: Multicast to unicast REGISTER
Issue:
The spec allows for clients to multicast their registrations. Presumably,
refreshes are also sent multicast. Sometimes this is the right thing, but if
the purpose of multicast REGISTER is just discovery, the client should
probably unicast after it discovers, and then revert to multicast again only
if that server becomes unavailable. However, the spec is silent on this
case. Should we discuss?
Discussion points:
A 301 can be sent by the registar, providing a unicast address (this is only
now possible in bis-05 due to the new multicast treatment). However, the 301
would be cached indefinitely at the client, and its not clear what the
behavior is for cached redirects on failure. If we specify that it retries
the original request that generated the 3xx, then the registrar has a
mechanism it can use.
Proposal:
* add text to 301 section saying that if a cached contact fails, try the
original URI again
* add text in the registration section, mentioning that this is a useful
thing to do. Otherwise, people may not be prepared to have their
registrations redirected, even though the spec does allow it.
-Jonathan R.
---
Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave.
Chief Scientist First Floor
dynamicsoft East Hanover, NJ 07936
jdrosen@dynamicsoft.com FAX: (973) 952-5050
http://www.jdrosen.net PHONE: (973) 952-5000
http://www.dynamicsoft.com
_______________________________________________
Sip mailing list http://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip