OK, this is interesting. However, i think the received parameter and rport
are added by kamailio, so it can only be checked for outgoing messages,
these will still be unavailable in incoming messages. Is this correct or
they will be available in every incoming messages too (except of course the
the very first incoming messages)?
Looking at RFC7118, it says the WS VIA header domain part will contain
"random string" followed by ".invalid" to make it a correct domain
name.
This may provide some uniqueness, though this random string may not
necessarily be unique as well.
Thank you.
On Mon, Aug 25, 2014 at 5:23 PM, Vitaliy Aleksandrov <vitalik.voip(a)gmail.com
wrote:
> When kamailio processes a request script writer can check if there any
> Route header or valid R-URI or R-URI alias parameter to determine the
> destination. You can check it manually maybe reusing kamailio sip parser.
>
> As you've already said to find a destination where kamailio is going to
> send a reply you can parse via header or its "received" and
"rport"
> parameters. Even when via doesn't have valid destination (ws/wss transport)
> it has correct "received" and "rport" parameters which kamailio
adds during
> a request processing.
>
> "Via" header in INVITE received from WSS client and forwarded to a
> destination looks like this:
> "Via: SIP/2.0/WSS
>
df7jal23ls0d.invalid;received=1.2.3.4;branch=z9hG4bKTp9lzCApgHsdbRUrFcZ4XTCI49EZbbDf;rport=37213"
>
>
> Not really, the main context of this question is in reference to this
> thread,
>
>
https://www.mail-archive.com/sr-users@lists.sip-router.org/msg19962.html
>
> A patched to allow network IO intercept in kamailio corex module was add
> to trunk as discussed in this thread,
>
>
https://www.mail-archive.com/sr-users@lists.sip-router.org/msg20183.html
>
> Currently i am able to compress / decompress entire sip message coming
> from or going to remote endpoint in kamailio server. It works fine. Now i
> want to try ITV encryption algorithm for this on-wire data.
>
>
https://github.com/mshary/itv
>
> For this i need to keep track of remote endpoint. At this low level, i
> only have raw data received from or being transmitted to remote UA, without
> even the remote socket address, so i have no choice but to look at this raw
> data to determine the identity of remote endpoint. For non-WS transport, i
> can easily look at topmost VIA and extract network address to use as
> "unique identification" of endpoint who sent the data or would receive the
> data. However, for WS transport this topmost VIA is useless static constant
> string. So VIA checking is pointless (all remote endpoints will or may have
> same top most VIA).
>
> So i was thinking if there is another way to do it? I thought of using
> GRUU, but it is not always present, especially in SIP replies.
>
> Thank you.
>
>
>
>
> On Mon, Aug 25, 2014 at 3:24 PM, Vitaliy Aleksandrov <
> vitalik.voip(a)gmail.com
wrote:
>
>> On 22.08.14 03: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.
>>>
>>>
>> Can you provide an example of scenario you want to create ?
>> Do you want to understand how transaction and dialog matching works in
>> SIP ?
>>
>> _______________________________________________
>> 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
>>
>
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
listsr-users@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>
>
> _______________________________________________
> 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
>
>