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