Any substitute or replace function for the request-/response line of SIP messages available?
15 Feb
2013
15 Feb
'13
8:22 p.m.
Hi,
I have a very specific situation that the implementation of a customer
SIP user agent is absolutely not standards conform. Therefore, I use
Kamailio as a SIP protocol adapter between the non-standard conform user
agent(s) and the typical RFC3261 compliant user agents. Most conversions
are working fine. But in a very specific scenario I have to
change/convert a SIP response message to a SIP request message and
change the SIP method´s name. This conversion is no problem for the SIP
header fields. However, I haven't found a way for adapting the
response-/request line of a SIP message. This line seems to be protected.
The described situation of the perverse conversion I try to realize is
following (please do not ask "why?" or think I'm mad...):
(mad) UA1 == INVITE ==> SIP-Prot-Adapter(Kamailio) == INVITE ==> (typ.)UA2
UA1 <== BYE == SIP-Prot-Adapter(Kamailio) <== 488 == (typ.)UA2
UA1 == BYE ==> SIP-Prot-Adapter(Kamailio) == ACK ==> (typ.)UA2
I use the "textops" module for substitution and/or replacement in SIP
header fields. But the "subst" and "replace" functions cannot be used
for the request-/response line on top of the SIP messages. I was a
little bit irritated, as the "search" function is still working on these
lines, but not the subst/replace function. Creating a new SIP message
with the UAC module (as alternative) is not okay, as this new message
does not use the same values for Call-ID, From-tag a.s.o. and these
values can't be changed before sending the message.
Does anybody know a way / function / method for manipulating the
request-/response line of a message? It would be perfect using a
function á la "sed"/subst.
Thanks
Klaus
P.S. I tested with kamailio-3.3.3
15 Feb
15 Feb
8:52 p.m.
At the risk of sounding unhelpful, if you are having to modify the
request/status line, there's probably something more deeply wrong here,
and you should probably endeavour to fix the problem in a somewhat more
realistic manner.
Furthermore, it must be said that proxies do not make a particularly
good "protocol adaptor"; in contrast to "thicker" back-to-back user
agents (B2BUAs), which build out two logically independent call legs and
bridge signaling events between them selectively, as they see fit,
proxies are more or less obligated, in principle, to pass on what they
receive, in unadulterated form. Kamailio does offer some hacks around
that, in the form of textops and so on, but it doesn't really mean that
it is the right tool for the job.
That said, if you are dead-set on doing this, your best for regenerating
a reply into a request is the 'uac' module and uac_req_send() functionality:
http://kamailio.org/docs/modules/3.3.x/modules_k/uac.html#id2494432
-- Alex
On 02/15/2013 03:22 PM, Klaus Feichtinger wrote:
Hi,
I have a very specific situation that the implementation of a
customer SIP user agent is absolutely not standards conform.
Therefore, I use Kamailio as a SIP protocol adapter between the
non-standard conform user agent(s) and the typical RFC3261 compliant
user agents. Most conversions are working fine. But in a very
specific scenario I have to change/convert a SIP response message to
a SIP request message and change the SIP method´s name. This
conversion is no problem for the SIP header fields. However, I
haven't found a way for adapting the response-/request line of a SIP
message. This line seems to be protected.
The described situation of the perverse conversion I try to realize
is following (please do not ask "why?" or think I'm mad...): (mad)
UA1 == INVITE ==> SIP-Prot-Adapter(Kamailio) == INVITE ==> (typ.)UA2
UA1 <== BYE == SIP-Prot-Adapter(Kamailio) <== 488 == (typ.)UA2 UA1
== BYE ==> SIP-Prot-Adapter(Kamailio) == ACK ==> (typ.)UA2
I use the "textops" module for substitution and/or replacement in
SIP header fields. But the "subst" and "replace" functions cannot be
used for the request-/response line on top of the SIP messages. I
was a little bit irritated, as the "search" function is still working
on these lines, but not the subst/replace function. Creating a new
SIP message with the UAC module (as alternative) is not okay, as this
new message does not use the same values for Call-ID, From-tag a.s.o.
and these values can't be changed before sending the message.
Does anybody know a way / function / method for manipulating the
request-/response line of a message? It would be perfect using a
function á la "sed"/subst.
Thanks Klaus
P.S. I tested with kamailio-3.3.3
_______________________________________________ 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
--
Alex Balashov - Principal
Evariste Systems LLC
235 E Ponce de Leon Ave
Suite 106
Decatur, GA 30030
United States
Tel: +1-678-954-0670
Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
17 Feb
17 Feb
12:52 p.m.
I know that it is an untypical way and that a B2BUA would be the best
solution - that is absolutely clear. But because of a missing framework
and time I decided to try it with Kamailio that I've used in many other
projects, too.
Textops is still used and working fine for any headers (except request
line). But UAC (as you´ve recommended) didn't satisfy me. I missed a
possibility for setting dialog-specific settings á la Call-ID, from-tag,
to-tag and CSeq. When I´ve tried setting the CSeq header with the function
$uac_req(hdrs)="CSeq: 123 INVITEr\n";
it has only added a second CSeq header to the outgoing message, but
didn't replace the original CSeq header that was created by the UAC
module. Is there a way to influence the listed id´s, too?
Klaus
At the risk of sounding unhelpful, if you are having
to modify the
request/status line, there's probably something more deeply wrong here,
and you should probably endeavour to fix the problem in a somewhat more
realistic manner.
Furthermore, it must be said that proxies do not make a particularly
good "protocol adaptor"; in contrast to "thicker" back-to-back user
agents (B2BUAs), which build out two logically independent call legs and
bridge signaling events between them selectively, as they see fit,
proxies are more or less obligated, in principle, to pass on what they
receive, in unadulterated form. Kamailio does offer some hacks around
that, in the form of textops and so on, but it doesn't really mean that
it is the right tool for the job.
That said, if you are dead-set on doing this, your best for
regenerating a reply into a request is the 'uac' module and
uac_req_send() functionality:
http://kamailio.org/docs/modules/3.3.x/modules_k/uac.html#id2494432
-- Alex
18 Feb
18 Feb
5:23 a.m.
...I think in worst case a controlled local loop (which was helpful in
other situations, too), could be a solution for fixing the UAC problem.
1. UAC (module) sending the created request to the SIP server again (loop)
2. the server is doing textops and
3. is finally forwarding the request to the real target
I will try that.
Klaus
I know that it is an untypical way and that a B2BUA
would be the best
solution - that is absolutely clear. But because of a missing
framework and time I decided to try it with Kamailio that I've used in
many other projects, too.
Textops is still used and working fine for any headers (except request
line). But UAC (as you´ve recommended) didn't satisfy me. I missed a
possibility for setting dialog-specific settings á la Call-ID,
from-tag, to-tag and CSeq. When I´ve tried setting the CSeq header
with the function
$uac_req(hdrs)="CSeq: 123 INVITEr\n";
it has only added a second CSeq header to the outgoing message, but
didn't replace the original CSeq header that was created by the UAC
module. Is there a way to influence the listed id´s, too?
Klaus
At the risk of sounding unhelpful, if you are
having to modify the
request/status line, there's probably something more deeply wrong here,
and you should probably endeavour to fix the problem in a somewhat more
realistic manner.
Furthermore, it must be said that proxies do not make a particularly
good "protocol adaptor"; in contrast to "thicker" back-to-back user
agents (B2BUAs), which build out two logically independent call legs and
bridge signaling events between them selectively, as they see fit,
proxies are more or less obligated, in principle, to pass on what they
receive, in unadulterated form. Kamailio does offer some hacks around
that, in the form of textops and so on, but it doesn't really mean that
it is the right tool for the job.
That said, if you are dead-set on doing this, your best for
regenerating a reply into a request is the 'uac' module and
uac_req_send() functionality:
http://kamailio.org/docs/modules/3.3.x/modules_k/uac.html#id2494432
-- Alex
_______________________________________________
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
4103
days inactive
4106
days old
3 comments
2 participants
participants (2)
-
Alex Balashov -
Klaus Feichtinger