I guess that one of the local policies could be that since the re-INVITE is part of the same dialog so let id continue with the secondary. All new dialogs would go to the primary once the same is in-service again.
regards
Rayees
To: "Brett Tate" <[EMAIL PROTECTED]>, <[email protected]>
From: "Agrawal, Vishal" <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
Date: 01/25/2006 09:21PM
Subject: Re: [Sip-implementors] RFC 3263 Question for Authenticated Request
Brett, I agree with what you say about applying a "local policy" in
these situations.
Just to strengthen the argument that the "local policy" may be required,
assume another case where the primary is down for a while... Now, if the
UAC applies RFC 3263 procedure then based on the expiry of NONCE at the
secondary (short expiry time); the UAC may never get authenticated.
However, shouldn't the "local policy" or as my colleague calls
"non-standard" be documented (identifying scenarios leading to the use
of local policy).
Vishal
-----Original Message-----
From: Brett Tate [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, January 25, 2006 2:17 PM
To: Agrawal, Vishal; [email protected]
Subject: RE: [Sip-implementors] RFC 3263 Question for Authenticated
Request
> Assume that a UAC is configured to use a DNS SRV FQDN to
> contact a set of UAS (a primary and a secondary). Further
> assume that the primary UAS is down (may be due to a restart
> of the server). If the UAC sends a SIP request, it follows
> the DNS SRV procedure and sends the request to the Primary
> UAS first. Since the Primary UAS is down, the UAC fails over
> to the Secondary UAS and gets challenged.
>
> Where should the UAC send the authenticated request first?
In my opinion, it is illogical to not try the successful location on the
immediate resubmit (with higher CSeq) of a request based on 4xx-6xx
responses.
For primary/secondary configurations, not first trying the reached
location
likely adds extra traffic and likely adds extra time to get the request
processed.
For loadbalance configurations, not first trying the reached location
could
cause resubmit loops or all locations to be tried before finally
providing
authorization for a given nonce to the machine which challenged with the
nonce.
However if I understand RFC 3261 and RFC 3263 correctly, the primary
would
be tried first again (or loadbalance occurs again) unless a "local
policy"
is alternatively used. Thus you can apply a "local policy" to allow
things
to work more efficiently. Or you can act less efficiently and follow
the
default process.
> Similarly, in the above scenario, if the request is INVITE
> (and lets say doesn't get challenged); where should the UAC
> send the ACK request first?
RFC 3261 section 17.1.1.2 indicates the destination address and port of
ACK
for a non-2xx response MUST be identical to the INVITE.
ACK for 2xx response follows the normal RFC 3263 process for the next
hop
within the dialog unless a "local policy" is used. If the ACK was for a
re-INVITE, I suggest following a "local policy" if the successful
location
is still within the RFC3263 result list and sending to a proxy. I
mention
this because the ACK likely would not be able to really fork to the
available location.
Note: during dialog establishment if the secondary wants to become the
primary within the dialog, it would be reflected by the next hop entry
(resulting from Contact or Record-Route entry) within the dialog.
Within a
confirmed dialog, an endpoint can switch from being secondary to primary
by
supplying a new Contact. However proxies are unable to indicate such a
switch after the dialog is confirmed. Thus applying a "local policy"
instead of the default process can be more efficient.
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
*****FSS-Private *****" DISCLAIMER: This message is proprietary to Flextronics Software Systems Limited (FSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."
_______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
