[SIPForum-discussion] Multiple equivalent P-CSCF discovery issues

[Michael Zhang]

The DNS procedures for a stateful proxy is specified in RFC3263. But the
RFC only states proxy should not change target within a SIP transaction. In
your case, the new REGISTER starts a new transaction so SBC can forward the
request to a different P-CSCF if the TTL of previous DNS rr expires. But
the window for this to happen is pretty small.

Thanks,
-Michael

On Friday, May 30, 2014, Bourdoukis Dimitrios <dbourdoukis at hol.net> wrote:

>  Hello team
>
>
>
> I have deployed in the network an SBC acting as A-ALG and I am trying to
> load-balance the REGISTER requests coming from the UEs towards multiple
> cores (P-CSCFs) by means of DNS which resolves the P-CSCFs hosts with equal
> priority and weight.
>
>
>
> I am using Digest authentication without for TLS for the users and the
> problem I am phasing is the following:
>
>
>
> After a UE is challenged by the network with 401 Unauthorized, it
> resubmits the REGISTER request with the appropriate credentials and same
> Call-Id as appropriate. However this new REGISTER request is routed
> individually by the SBC A-ALG by executing again DNS procedures. The effect
> is that this 2nd REGISTER request may be routed to a different P-CSCF which
> in turn results again to a new challenge for obvious reasons, and so on.
>
>
>
> Note that this is not the case for the Re-REGISTER requests, where in that
> case my A-ALG remembers where the initial Registration has been concluded
> as it uses that address:port when a binding is refreshed.
>
>
>
> I was not able to find any explicit reference in the specs on how a UE
> Proxy Registrar (in my case an A-ALG) should route a REGISTER request
> following the challenge, in case of multiple equivalent core targets.
>
>
>
> Can anybody help on that?  Is there any RFC reference or other spec  that
> clarify this? Note that the SIP multicast Registrar discovery is not an
> option in my implementation.
>
>
>
> Thanks in advance
>
>
>
> Dimitris
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sipforum.org/pipermail/discussion/attachments/20140603/690eca9a/attachment-0002.html>