Re: [Sofia-sip-devel] Sofia-SIP sorting of SRV records defeats DNS server round-robin SIP traffic distribution
Hi,
Thanks for your analysis. If anybody is looking into fixing this, you can also
consider address affinity for dialogs and transactions: a dialog/transaction
(in practice, a NUA handle representing either of these) should stick to a
particular IP protocol/address/port tuple (in Sofia, a “secondary transport”)
for all outbound requests, unless there is some problem with the transport.
Services implementing load balancing with DNS are unfortunately less likely to
maintain shared dialog state between the load balanced proxies.
See
http://sourceforge.net/tracker/?func=detail&aid=2204637&group_id=143636&atid=756079
Best regards,
Mikhail
From: ext Jim Thomas [mailto:jimthomasembed...@yahoo.com]
Sent: Friday, March 19, 2010 1:15 AM
To: sofia-sip-devel@lists.sourceforge.net
Subject: [Sofia-sip-devel] Sofia-SIP sorting of SRV records defeats DNS server
round-robin SIP traffic distribution
Hello,
I am using Sofia-SIP 1.12.10 and it works great. Thank you
for your open source contribution.
I use an ITSP where, until recently, a DNS lookup by Sofia-SIP
would obtain a single SRV record. Outbound SIP calls work as
expected every time.
The ITSP now wants to distribute the SIP traffic across three
destinations (three cities), so the same DNS lookup by Sofia-SIP
obtains three SRV records.
The DNS server is provisioned to rotate the SRV records
round-robin, so the first choice will alternate among the three
destinations. I can see in a packet trace that the SRV record
sequence is in fact alternating across DNS lookups. (These are
the external DNS lookups after the Sofia-SIP DNS cache expires).
The problem is that even though the DNS response presents the
SRV records in varying order, Sofia-SIP always selects the same
particular SRV record, so outbound calls always go to a single
destination and are not distributed.
I reviewed the Sofia-SIP source, and think I see what is
happening.
Sofia-SIP sorts the SRV records on priority, weight, srv_target,
and srv_port:
sofia-resolv/sres_record.h
/** Service location record (@RFC2782). */
typedef struct sres_srv_record
{
sres_common_t srv_record[1]; /**< Common part of DNS records. */
uint16_t srv_priority; /**< Priority */
uint16_t srv_weight; /**< Weight */
uint16_t srv_port; /**< Service port on the target host. */
uint16_t srv_pad;
char *srv_target; /**< Domain name of the target host. */
} sres_srv_record_t;
sres.c
sres_record_compare(sres_record_t const *aa, sres_record_t const *bb)
{
case sres_type_srv:
{
sres_srv_record_t const *A = aa->sr_srv, *B = bb->sr_srv;
D = A->srv_priority - B->srv_priority; if (D) return D;
/* Record with larger weight first */
D = B->srv_weight - A->srv_weight; if (D) return D;
D = strcmp(A->srv_target, B->srv_target); if (D) return D;
return A->srv_port - B->srv_port;
}
}
If the priority and weight are identical for all three SRV records,
as they are with my ITSP, then the alpha sort of the srv_target name
determines the SRV record sort sequence.
The result is that Sofia-SIP loses the SRV record sequence intended
by the round-robin ordering by the DNS server, and the SRV record
selected by Sofia-SIP is always the record that just happens to have
the target name with the lowest alpha sort key.
It seems to me that the correct sort would be by priority and weight
only, and where those are identical for adjacent records, the original
SRV record sequence would be preserved so the first choice intended
by the DNS server round-robin ordering would be used by Sofia-SIP
to determine where to send the SIP for the outbound call.
Thanks.
Jim
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] Default SOA Session
Hi all How to pass the default soa session as argument to soa_set_remote_sdp() and soa_process_answer() functions Best Regards -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
Re: [Sofia-sip-devel] Sofia-SIP sorting of SRV records defeats DNS server round-robin SIP traffic distribution
2010/3/19 Jim Thomas : > The DNS server is provisioned to rotate the SRV records > round-robin, so the first choice will alternate among the three > destinations. I can see in a packet trace that the SRV record > sequence is in fact alternating across DNS lookups. (These are > the external DNS lookups after the Sofia-SIP DNS cache expires). > The problem is that even though the DNS response presents the > SRV records in varying order, Sofia-SIP always selects the same > particular SRV record, so outbound calls always go to a single > destination and are not distributed. ... > The result is that Sofia-SIP loses the SRV record sequence intended > by the round-robin ordering by the DNS server, and the SRV record > selected by Sofia-SIP is always the record that just happens to have > the target name with the lowest alpha sort key. Sofia SIP is supposed to select SRV record randomly. However there is a problem with SRV records with zero weight. If all the SRV records have zero weight, the first one after the sort is always selected. A far as I can remember, this is because the weight 0 is used to indicate that no server selection is done. If the weights are greater than 0, the server selection should be pretty random. > It seems to me that the correct sort would be by priority and weight > only, and where those are identical for adjacent records, the original > SRV record sequence would be preserved so the first choice intended > by the DNS server round-robin ordering would be used by Sofia-SIP > to determine where to send the SIP for the outbound call. You are right, the sorting tries now support stateless proxies, the nta should probably not use the default sorting algorithm but do its own or do some special randomization in case of 0 weights. -- Pekka.Pessi mail at nokia.com -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
Re: [Sofia-sip-devel] Remove an unknown sip header
2010/3/26 Alexandre Brito : > I flowing through sofia sip documentation/code trying to find the best way to > remove an unknown sip header. > I found that its easy to add any header my using SIPTAG_HEADER_STR or even > SIPTAG_HEADER(x) by define a new header struct. > > However, what's the best option to remove those kind of headers from a sip > message? I don't think it is possible when using the tags. > Should I create a new SIPTAG around the new header, for instance > SIPTAG_P_CHARGING_VECTOR()? What are my options? You have to either go through the list of unknown headers explicitly, or define your own header parser class object. See the sofia-sip-2543 package for examples. If you feel like it, a sofia-sip-3455 package would probably be appropriated by many folks here. -- Pekka.Pessi mail at nokia.com -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
