"Karthik.v" <karthik...@plintron.com> writes:
> 1) Please state a real time scenario where multiple contact headers will be
> present in a REGISTER request ?
The most likely use is when a UA knows only its IP address and not any
DNS name for that address. Then if it wants to register both an IPv4
address and an IPv6 address, it must register two contact URIs.
In addition, the UA might be changing its address, and simultaneously
registering its new address(es) while deregistering its old address(es).
Another possibility is if a UA is registering both itself and another,
"slave", UA which is not capable of registering itself.
> 2) Why Register does not establish a dialog & subscribe establish a dialog ?
The probable reason is that the registrar never needs to send a request
to the UA. (Incoming calls are sent to the UA, but each call uses its
own dialog.) In addition, registrations end due to time-out; it would
not work to require an explicit termination of a registration dialog.
Vivek Batra <vivek.ba...@matrixcomsec.com> writes:
> 3. Since it is optional and not sent in the REGISTER request, I would like
> to see registrar to simply return the present bindings. However not
> surprise for me if it's been rejected with 400 Bad Request and can be seen
> in many practical implementations.
More to the point, RFC 3261 *requires* the behavior you desire; the
behavior of the app that Karthik.v describes is incorrect. See
particularly RFC 3261 section 10.3:
...
When receiving a REGISTER request, a registrar follows these steps:
...
6. The registrar checks whether the request contains the Contact
header field. If not, it skips to the last step. ...
...
8. The registrar returns a 200 (OK) response. The response MUST
contain Contact header field values enumerating all current
bindings. Each Contact value MUST feature an "expires"
parameter indicating its expiration interval chosen by the
registrar. The response SHOULD include a Date header field.
Dale
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
