Hi all,
I would suggest as a HA configuration having more than one SRV entry
for your domain, each one pointing to a b2b.
Besides that, it is important to use hostnames in the Contact header
value instead of IP numeric values.
With this approach, and sharing the dialog identifiers between the
different b2b, when the primary b2b fails, the UA will try (trough RF C
3263) the next SRV record, which will point to the backup b2b. When the
backup b2b receives the request from the UA, it has to modify the media
parameters if it is in the middle of the media path.
I think the key point here is to use hostnames in
Contact/Record-Route/etc headers instead of IP numeric values.
I hope it helps and, please, correct me if I am wrong,
Samuel.
Unclassified.
>>> <[EMAIL PROTECTED]> 11/19/04 01:11AM >>>
Suheel,
I don't know about 'typical configuration' I just kind of
diagreed
with the statement that HA / redundancy is not possible. Didn't this
thread start with the concept of two b2b servers which shared dialog
state
information between them ? - UAC redundancy to these servers should be
available with redundancy config for proxy address, returned contact
address, re-use of tags, etc inline with some of the previous postings.
Sorry - if I have jumped on the wrong conversation where the context of
my
response does not apply.
Regards,
Wayne.
>Wayne,
>
>Configuration on SIP UA box? I am curious about what
>are typical configuration which can provide HA?
>
>--- [EMAIL PROTECTED] wrote:
>
> Baniel,
> SIP HA is available - it may just take some
> configuration. I know
> / have worked on systems that provide in dialog
> failover. The posting from
> Jason(?) below stating that the address is not used,
> from and to tags are
> used to correlate messages with existing dialogs, is
> appropriate.
> Regards,
> Wayne.
> *********************************************
>
>
>
> Well we can get into a long conceptual discussion
> here... In my opinion
> SIP does provide some nice recoverability/HA
> built-in support, by having
> state/path info incorporated in the messages (e.g
> Route list, Contact
> etc).
>
> -uri
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On
> Behalf Of Suheel
> Hussain
> Sent: Thursday, November 18, 2004 10:43 AM
> To: [EMAIL PROTECTED]
> Subject: RE: [Sip-implementors] UA IP address change
> after initial
>
>
> The gist is that Sip signalling does not support
> high-availability. Which
> is quite odd as a number of telephony and ATM
> signalling protocols support
> HA.
>
> -suheel
> Suheel Hussain
> Email: [EMAIL PROTECTED]
>
> >For call control, if contact has IP, subsequent
> msgs
> within dialog will
> >use that IP. I would think msgs will be dropped if
> failover occurs to
> >diff IP.
>
> >Same with audio stream sent to specific IP/port.
> >-- Jason
>
> >>UA1 is not supposed to maintain IP address as part
> of the dialogue. In may cases it wouldn't even know
> what is the IP address of the b2bua as the SIP
> messages may go through intermediate hops (e.g.
> proxy). All
> >>should be fine as long as the call-leg (dialog)
> identifiers are kept the
> >>same (call-id, local and remote tags (in the From
> and To headers
> >>respectively)).
>
> >Hope everyone is in agreement w/ me...
>
> >-uri
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam
> protection around
> http://mail.yahoo.com
> _______________________________________________
> Sip-implementors mailing list
> [EMAIL PROTECTED]
>
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
> _______________________________________________
> Sip-implementors mailing list
> [EMAIL PROTECTED]
>
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
******************************************************************************
- NOTICE FROM DIMENSION DATA AUSTRALIA
This message is confidential, and may contain proprietary or legally
privileged information. If you have received this email in error,
please notify the sender and delete it immediately.
Internet communications are not secure. You should scan this message
and any attachments for viruses. Under no circumstances do we accept
liability for any loss or damage which may result from your receipt of
this message or any attachments.
******************************************************************************
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
