3 Sep
2014
3 Sep
'14
9:48 a.m.
On 03.09.2014 03:09, Muhammad Shahzad wrote:
Thank you so much for your informative response.
Yes the "peer" may be correct term in this sense as i am trying to
identify "devices" (SIP UAs or Proxy) that are directly connected to
Kamailio via SIP signalling (i.e. there is no other intermediate SIP
device [SIP UA or Proxy] in the middle). That is why top most VIA header
looks interesting as it has peer network address that can be used to
identify that peer uniquely for both incoming and outgoing SIP requests
and responses.
However, this works perfectly fine ONLY for TCP, TLS and UDP transports.
For WS and WSS, there is no network address, just some random string,
which is not guaranteed to be unique in peer context.
Anyways for the moment the only workaround i see fit for the situation
is to modify WS client code such that i generates this random string
uniquely (e.g. something like GUID used by Windows OS or UUID generated
by libuuid in Linux).
Any other suggestions are warmly welcome.
I disagree. IMO it is a bad choice to rely on the Via header. Your
software should use only data which is generated locally (and thus
trustworthy). The Via header is generated by the peer and may be false
or manipulated, and it does not serve your needs. Thus, instead of
changing clients to add data tot he Via header you should look for
another option.
For example, when a client uses outbound and GRUU, Kamailio also has to
map some identifiers to transport connections. Thus, I guess there is
already some code in Kamailio.
Another method, as stated in my previous email, is the IP:port:proto.
But not extracted from the Via header, but extracted from the transport
layer (e.g. $si, $sp, $proto, ....)
regards
Klaus