IMO the UA has no obligation to accept such a request, based on current
RFCs.
The UA in general has control of how it is addressed. It generates its
own contact address and publishes it with a registrar. And the specs for
routing to registered contacts result in the UA receiving the request
with its chosen contact in the R-URI.
UAs that don't register must find some way to make their address known
to those that send requests to them. In that case, they should be
prepared to accept whatever they have made known.
There is a proposal outstanding to provide a new way for a home proxy to
route requests to registered contacts. With this proposal the AOR will
remain in the R-URI and the registered contact will be placed into a
Route header. This is still a work in progress, so you shouldn't see
this behavior yet. And as proposed, you would need to specify an option
when registering to get this behavior. So it won't be a surprise.
Paul
Manivannan S, TLS-Chennai wrote:
> Hi everybody,
>
> Shall UAS receive INVITE with its own AOR in request URI instead of its
> contact?
>
> Example:
> UA registered its AOR sip:[EMAIL PROTECTED] with contact
> sip:[EMAIL PROTECTED]
>
> And UA Receiving INVITE with following Start line from the registrar.
> INVITE sip:[EMAIL PROTECTED] SIP/2.0
>
> Should UA accept or reject this INVITE?
>
> Thanks,
> S. Manivannan
>
> DISCLAIMER:
> -----------------------------------------------------------------------------------------------------------------------
>
> The contents of this e-mail and any attachment(s) are confidential and
> intended for the named recipient(s) only.
> It shall not attach any liability on the originator or HCL or its affiliates.
> Any views or opinions presented in
> this email are solely those of the author and may not necessarily reflect the
> opinions of HCL or its affiliates.
> Any form of reproduction, dissemination, copying, disclosure, modification,
> distribution and / or publication of
> this message without the prior written consent of the author of this e-mail
> is strictly prohibited. If you have
> received this email in error please delete it and notify the sender
> immediately. Before opening any mail and
> attachments please check them for viruses and defect.
>
> -----------------------------------------------------------------------------------------------------------------------
>
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors@cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
Sip-implementors@cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
