[Asterisk-Dev] OT: R&D Loadbalancer SIP Questions

[Kevin P. Fleming]

Matthew Boehm wrote:

>     1. Which SIP header would be best to become the "session id"? He gave
> examples of Via header, callid header and From header. The header needs to
> be persistant across all packets per call and be unique between calls. (not
> purely unique, meaning that the LB doesn't store id's past the termination
> of the call.)

Per the RFC (which you need to read (two or three times) and understand 
very, very well before embarking on this adventure), the Call-ID header 
is globally unique and identifies a specific call.

>     2. Is the "session id" chosen in #1 also present in the audio payload
> packets?

No. There is nothing in the media streams to indicate that they belong 
to any SIP session whatsoever; this can only be determined by inspecting 
the SIP signaling and making note of the IPs and ports to be used to 
send/receive media (which can change throughout the call).

>     3. I was under the impression that SIP over TCP was not yet an RFC
> standard but the tech seemed to think so. So his question was "at any time
> during a call, are there both tcp and udp packets refering to that same
> call? and with the same id as #1?"

SIP over TCP is part of RFC3261, always has been. This is an area where 
Asterisk is slightly out of RFC compliance, because we don't support SIP 
over TCP and the RFC says we SHOULD.

However, a single SIP session (Call-ID) will use only a single signaling 
path.

>     4. Finally, he wanted to know what could he do to "query" each server to
> determine if it should be in the pool of servers. For example, when doing
> HTTP requests, the LB examines the packet and if it finds any thing in the
> error 500 range, that server is marked as "down".  He said that he could
> send an INVITE to each server and as long as he recieved code XXX that that
> server would remain in the pool. If no response recieved after XXms, or the
> incorrect response code recieved, then the server is marked down and email
> fired off.

Use OPTIONS, the same technique that Asterisk uses to keep track of its 
own SIP peers.

> 
> Thoughts, questions, concerns are welcome.

Read my answer to #1 above, again. You really, really need to understand 
SIP very well if you want to be able to implement and support an 
application like this, or you will be at the mercy of the vendor's 
support staff (finger pointing included at no extra charge). All of 
these questions are easily answered by understanding RFC3261, and it's 
really not that hard of a read.