Hi,
I think since address B is different from address A, client should
treat this as some NAT is in place should send responses back to address A
which is actual source IP received in Packet. Here, client can also treat
that Layer 3 ip and layer 2 ip are different and thus same logic of NAT
should be applied and response should be sent to source IP.
Refer NAT detection procedures for more details.
Thanks and Regards,
Vivek
On Fri, Sep 19, 2014 at 6:23 PM, Kchitiz Saxena <kchitiz.sax...@gmail.com>
wrote:
> Hi
> This is related to UAS behaviour to know "Where to send response for the
> received request". Following two statement looks a bit contradicting to me
> -
>
> 1. RFC 3261, Section 18.2.2 - The server transport uses the value of the
> top Via header field in
> order to determine where to send a response.
> Same section, last bullet -
> Otherwise, if it is not receiver-tagged, the response MUST be
> sent to the address indicated by the "sent-by" value, using the
> procedures in Section 5 of [4].
>
> 2. RFC 3263 - A server, according to RFC 3261 [1], will send a response on
> the
> connection it arrived on (in the case of reliable transport
> protocols), and for unreliable transport protocols, to the source
> address of the request, and the port in the Via header field.
>
> As per RFC 3263, it seems like only port is used from Via header and source
> address is used. Although, I believe that Address and port both should be
> used from Via header and RFC 3261 also indicates the same. Does this
> statement from RFC 3263 applies to some special situations?
>
>
> My problem is following-
> Application receives an INVITE message from source IP address A with FQDN
> in Via header. FQDN is resolved through DNS A query and receives DNS reply
> where IP address B is mentioned at top and IP address A is mentioned after
> that. So, all the responses are sent to IP address B. Calling side keeps
> retransmitting the request from source address A and call does not go
> through. Is there anything which can be changed in application's behaviour?
>
> Thanks
> Kchitiz
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>
--
Name | Title
GlobalLogic
P +x.xxx.xxx.xxxx M +x.xxx.xxx.xxxx S skype
www.globallogic.com
<http://www.globallogic.com/>
http://www.globallogic.com/email_disclaimer.txt
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
