Hi Kchitiz,
The point over here is that the layer 3 IP does not matched with
resolved IP address which is similar to the case of NAT. This way this case
can be handled as NAT scenario even though its not NAT case.
Rest it will depend on how you want to implement this scenario. You can
either treat this as NAT case and send responses to actual layer 3 IP or
can use approach suggested by Varun.
What you will do suppose if DNS query failed? Will not reply at all and
let endpoint keeps retransmitting the INVITE or will send responses to
layer 3 IP?
Thanks and Regards,
Vivek Talwar
On Fri, Sep 19, 2014 at 11:10 PM, Varun Bhatia <varuninbha...@gmail.com>
wrote:
> Hi Kchitiz,
>
> As per my understanding this will be implementation dependent there is no
> specific standards, if client fqdn is resolving in two ip then it must be
> trying to load balance. In A query response both Ip should have been
> received therefore both of them should be compared with layer 3 ip to check
> the correct one for sending the responses.
>
> Sent from Iphone,
> Varun
>
> > On 19-Sep-2014, at 22:35, Kchitiz Saxena <kchitiz.sax...@gmail.com>
> wrote:
> >
> > No Vivek, its definitely not NAT. It is 2 IP addresses in DNS server for
> a
> > hostname.
> >
> > On Fri, Sep 19, 2014 at 7:50 PM, Vivek Talwar <
> vivek.tal...@globallogic.com>
> > wrote:
> >
> >> 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
>
--
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
