22 Aug
2014
22 Aug
'14
12:26 a.m.
Sorry for putting this question on both dev and user mailing lists, as it
is a rather theoretical question and i hope some SIP guru on either mail
list will answer.
For non-WS endpoints which use TCP or UDP for SIP transport, each upstream
request has top most VIA header pointing to the previous hop which
forwarded the request to current hop while each downstream request has top
most VIA header pointing to next hop to which it will be forwarded from
current hop.
But for WS endpoints, the top most VIA has dummy static value, so there is
no way to identify who sent this request or to whom the reply is going to.
Please note that i am not specifically interested in network address of
remote endpoint (though VIA header is suppose to provide it), i only need
to match requests and responses from / to a specific device using SIP v2.0
standard.
Any help is highly appreciated.
Thank you.
2 Sep
2 Sep
2:22 p.m.
Not sure what you trying to do, but the Via header is for transactions.
It may be different for every transaction. Thus, if you need transaction
matching (requests to responses) then you are fine and should use purely
the branch id.
If you want to match messages from one transaction to messages from
another transaction (e.g. dialog matching or matching multiple dialogs
from the same user) then the Via is probably the wrong choice. Please
also note, that the user can put any data into the Via header and this
may confuse your application if you blindly trusts all the data in the
Via header.
For matching dialogs you should use call-id and tags (or use the dialog
module).
For matching requests from a certain user agent: I think there is no
reliable way - GRUU may work if available.
But as you are talking about encryption it is more "peer" related then
user-agent related. I say "peer" as the peer may be another proxy with
several user agents behind. To identify peers you should use the data
from the transport: IP, port, protocol. That should be unique for a
peer. For received messages it should be simple to extract them, for
sending, the data should be available too (e.g. in DURI or some
references to a TCP connection).
regards
Klaus
On 22.08.2014 02:26, Muhammad Shahzad wrote:
Sorry for putting this question on both dev and user
mailing lists, as
it is a rather theoretical question and i hope some SIP guru on either
mail list will answer.
For non-WS endpoints which use TCP or UDP for SIP transport, each
upstream request has top most VIA header pointing to the previous hop
which forwarded the request to current hop while each downstream request
has top most VIA header pointing to next hop to which it will be
forwarded from current hop.
But for WS endpoints, the top most VIA has dummy static value, so there
is no way to identify who sent this request or to whom the reply is
going to.
Please note that i am not specifically interested in network address of
remote endpoint (though VIA header is suppose to provide it), i only
need to match requests and responses from / to a specific device using
SIP v2.0 standard.
Any help is highly appreciated.
Thank you.
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
3 Sep
3 Sep
1:09 a.m.
New subject: [SR-Users] How to uniquely identify SIP WS / WSS endpoint
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.
Thank you.
On Tue, Sep 2, 2014 at 4:22 PM, Klaus Darilion <klaus.mailinglists(a)pernau.at
wrote:
Not sure what you trying to do, but the Via header is
for transactions.
It may be different for every transaction. Thus, if you need transaction
matching (requests to responses) then you are fine and should use purely
the branch id.
If you want to match messages from one transaction to messages from
another transaction (e.g. dialog matching or matching multiple dialogs
from the same user) then the Via is probably the wrong choice. Please
also note, that the user can put any data into the Via header and this
may confuse your application if you blindly trusts all the data in the
Via header.
For matching dialogs you should use call-id and tags (or use the dialog
module).
For matching requests from a certain user agent: I think there is no
reliable way - GRUU may work if available.
But as you are talking about encryption it is more "peer" related then
user-agent related. I say "peer" as the peer may be another proxy with
several user agents behind. To identify peers you should use the data
from the transport: IP, port, protocol. That should be unique for a
peer. For received messages it should be simple to extract them, for
sending, the data should be available too (e.g. in DURI or some
references to a TCP connection).
regards
Klaus
On 22.08.2014 02:26, Muhammad Shahzad wrote:
Sorry for putting this question on both dev and
user mailing lists, as
it is a rather theoretical question and i hope some SIP guru on either
mail list will answer.
For non-WS endpoints which use TCP or UDP for SIP transport, each
upstream request has top most VIA header pointing to the previous hop
which forwarded the request to current hop while each downstream request
has top most VIA header pointing to next hop to which it will be
forwarded from current hop.
But for WS endpoints, the top most VIA has dummy static value, so there
is no way to identify who sent this request or to whom the reply is
going to.
Please note that i am not specifically interested in network address of
remote endpoint (though VIA header is suppose to provide it), i only
need to match requests and responses from / to a specific device using
SIP v2.0 standard.
Any help is highly appreciated.
Thank you.
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
9:48 a.m.
New subject: [SR-Users] How to uniquely identify SIP WS / WSS endpoint
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
3539
days inactive
3551
days old
3 comments
2 participants
participants (2)
-
Klaus Darilion -
Muhammad Shahzad