Hi all.
Can anyone shoot me an example on proper use of Juha's LCR module.
I thought I had mine right, but then I realized that some re-INVITE messages were not being handled properly and calls were being disconnected.
Regards, Paul
Java Rockx writes:
I thought I had mine right, but then I realized that some re-INVITE messages were not being handled properly and calls were being disconnected.
you should not use or need to use lcr modules functions for re-invites. re-invites are in-dialog requests that are forwarded based on route headers.
-- juha
Yep. I agree.
But does this mean for **any** SIP message that loose_route() returns TRUE, I simply call t_relay() and then stop processing via a break command?
I can't remember, but I thought I ran in to some cases where even when loose_route() returned TRUE, I still had to do some other processing.
Regards, Paul
On Tue, 15 Mar 2005 20:13:40 +0200, Juha Heinanen jh@tutpro.com wrote:
Java Rockx writes:
I thought I had mine right, but then I realized that some re-INVITE messages were not being handled properly and calls were being disconnected.
you should not use or need to use lcr modules functions for re-invites. re-invites are in-dialog requests that are forwarded based on route headers.
-- juha
Ahhh, I found my mistake, but can someone verify my thought process??
I'm using mediaproxy and I only proxy RTP streams if the caller or the callee are behind a NAT device.
So during a re-INVITE, I cannot just t_relay() the message because the RTP streams will end up at unreachable IP addresses if either SIP UA is NATed.
I can use client_nat_test("3") to test the caller's NAT settings, and for the callee I have to use lookup("location") and test my nat_flag setting.
But do I need to call revert_uri() after lookup("location") when processing re-INVITEs???
Regards, Paul
On Tue, 15 Mar 2005 16:17:38 -0500, Java Rockx javarockx@gmail.com wrote:
Yep. I agree.
But does this mean for **any** SIP message that loose_route() returns TRUE, I simply call t_relay() and then stop processing via a break command?
I can't remember, but I thought I ran in to some cases where even when loose_route() returned TRUE, I still had to do some other processing.
Regards, Paul
On Tue, 15 Mar 2005 20:13:40 +0200, Juha Heinanen jh@tutpro.com wrote:
Java Rockx writes:
I thought I had mine right, but then I realized that some re-INVITE messages were not being handled properly and calls were being disconnected.
you should not use or need to use lcr modules functions for re-invites. re-invites are in-dialog requests that are forwarded based on route headers.
-- juha
You won't be able to do lookup most of the time with re-INVITE if it falls into loose_route as the R-URI may have changed to sip:user@dest.ip.address. (The same applies to case without loose route as well)
With nathelper, you can do nat_uac_test("8") to test for private address in the SDP part and do rtpproxy according. Don't think mediaproxy has this test.
-----Original Message----- From: serusers-bounces@lists.iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Java Rockx Sent: Wednesday, 16 March 2005 9:03 AM To: serusers@lists.iptel.org; Juha Heinanen Subject: Re: [Serusers] LCR Backport Example For ser-0.9
Ahhh, I found my mistake, but can someone verify my thought process??
I'm using mediaproxy and I only proxy RTP streams if the caller or the callee are behind a NAT device.
So during a re-INVITE, I cannot just t_relay() the message because the RTP streams will end up at unreachable IP addresses if either SIP UA is NATed.
I can use client_nat_test("3") to test the caller's NAT settings, and for the callee I have to use lookup("location") and test my nat_flag setting.
But do I need to call revert_uri() after lookup("location") when processing re-INVITEs???
Regards, Paul
On Tue, 15 Mar 2005 16:17:38 -0500, Java Rockx javarockx@gmail.com wrote:
Yep. I agree.
But does this mean for **any** SIP message that
loose_route() returns
TRUE, I simply call t_relay() and then stop processing via a break command?
I can't remember, but I thought I ran in to some cases
where even when
loose_route() returned TRUE, I still had to do some other
processing.
Regards, Paul
On Tue, 15 Mar 2005 20:13:40 +0200, Juha Heinanen jh@tutpro.com wrote:
Java Rockx writes:
I thought I had mine right, but then I realized that some
re-INVITE > messages were not being handled properly and
calls were
being > disconnected.
you should not use or need to use lcr modules functions for re-invites. re-invites are in-dialog requests that are forwarded based on route headers.
-- juha
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
OK, but there are two sides of the conversation to test here for NAT.
Should nat_uac_test("8") be used in a reply_route or something? (Actually this won't work because the re-INIVITE would need to have the c= field in the SDP rewritten if the destination is NATed).
Anyhow, I mean if the original INVITE is from a NATed client, then I can use client_nat_test() but on the destination side, I still need to know if RTP proxying is needed.
How do I do this?
Regards, Paul
On Wed, 16 Mar 2005 11:19:50 +1100, Zeus Ng zeus.ng@isquare.com.au wrote:
You won't be able to do lookup most of the time with re-INVITE if it falls into loose_route as the R-URI may have changed to sip:user@dest.ip.address. (The same applies to case without loose route as well)
With nathelper, you can do nat_uac_test("8") to test for private address in the SDP part and do rtpproxy according. Don't think mediaproxy has this test.
-----Original Message----- From: serusers-bounces@lists.iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Java Rockx Sent: Wednesday, 16 March 2005 9:03 AM To: serusers@lists.iptel.org; Juha Heinanen Subject: Re: [Serusers] LCR Backport Example For ser-0.9
Ahhh, I found my mistake, but can someone verify my thought process??
I'm using mediaproxy and I only proxy RTP streams if the caller or the callee are behind a NAT device.
So during a re-INVITE, I cannot just t_relay() the message because the RTP streams will end up at unreachable IP addresses if either SIP UA is NATed.
I can use client_nat_test("3") to test the caller's NAT settings, and for the callee I have to use lookup("location") and test my nat_flag setting.
But do I need to call revert_uri() after lookup("location") when processing re-INVITEs???
Regards, Paul
On Tue, 15 Mar 2005 16:17:38 -0500, Java Rockx javarockx@gmail.com wrote:
Yep. I agree.
But does this mean for **any** SIP message that
loose_route() returns
TRUE, I simply call t_relay() and then stop processing via a break command?
I can't remember, but I thought I ran in to some cases
where even when
loose_route() returned TRUE, I still had to do some other
processing.
Regards, Paul
On Tue, 15 Mar 2005 20:13:40 +0200, Juha Heinanen jh@tutpro.com wrote:
Java Rockx writes:
I thought I had mine right, but then I realized that some
re-INVITE > messages were not being handled properly and
calls were
being > disconnected.
you should not use or need to use lcr modules functions for re-invites. re-invites are in-dialog requests that are forwarded based on route headers.
-- juha
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
How about something like this.
With the initial INVITE,
... Route processing ... if (caller is natted) { subst('/From:(.*)<(.*)>(.*)/From:\1<\2>;nat=yes\3/'); }
call nathelper or mediaproxy
t_on_reply(nat reply route); t_relay();
In your reply route,
if (callee is natted) { subst('/From:(.*)<(.*)>(.*)/From:\1<\2>;nat=yes\3/'); call nathelper or mediaproxy ... Other processing ...
In your loose route,
if (loose_route()) { if (method=="INVITE") { if (search("my_ser_detect_nat=yes") || (sdp in private address )) { call nathelper or mediaproxy } } on reply route t_relay() }
This does work for me most of the time. However, there are odd situation that this does not work.
Zeus
-----Original Message----- From: Java Rockx [mailto:javarockx@gmail.com] Sent: Wednesday, 16 March 2005 12:01 PM To: Zeus Ng Cc: serusers@lists.iptel.org Subject: Re: [Serusers] LCR Backport Example For ser-0.9
OK, but there are two sides of the conversation to test here for NAT.
Should nat_uac_test("8") be used in a reply_route or something? (Actually this won't work because the re-INIVITE would need to have the c= field in the SDP rewritten if the destination is NATed).
Anyhow, I mean if the original INVITE is from a NATed client, then I can use client_nat_test() but on the destination side, I still need to know if RTP proxying is needed.
How do I do this?
Regards, Paul
On Wed, 16 Mar 2005 11:19:50 +1100, Zeus Ng zeus.ng@isquare.com.au wrote:
You won't be able to do lookup most of the time with
re-INVITE if it
falls into loose_route as the R-URI may have changed to sip:user@dest.ip.address. (The same applies to case without loose route as well)
With nathelper, you can do nat_uac_test("8") to test for private address in the SDP part and do rtpproxy according. Don't think mediaproxy has this test.
-----Original Message----- From: serusers-bounces@lists.iptel.org
[mailto:serusers-bounces@lists.iptel.org]
On Behalf Of Java Rockx Sent: Wednesday, 16 March 2005 9:03 AM To: serusers@lists.iptel.org; Juha Heinanen Subject: Re: [Serusers] LCR Backport Example For ser-0.9
Ahhh, I found my mistake, but can someone verify my thought process??
I'm using mediaproxy and I only proxy RTP streams if the
caller or
the callee are behind a NAT device.
So during a re-INVITE, I cannot just t_relay() the
message because
the RTP streams will end up at unreachable IP addresses if either SIP UA is NATed.
I can use client_nat_test("3") to test the caller's NAT settings, and for the callee I have to use lookup("location") and test my nat_flag setting.
But do I need to call revert_uri() after lookup("location") when processing re-INVITEs???
Regards, Paul
On Tue, 15 Mar 2005 16:17:38 -0500, Java Rockx
wrote:
Yep. I agree.
But does this mean for **any** SIP message that
loose_route() returns
TRUE, I simply call t_relay() and then stop processing
via a break
command?
I can't remember, but I thought I ran in to some cases
where even when
loose_route() returned TRUE, I still had to do some other
processing.
Regards, Paul
On Tue, 15 Mar 2005 20:13:40 +0200, Juha Heinanen
wrote:
Java Rockx writes:
I thought I had mine right, but then I realized that some
re-INVITE > messages were not being handled properly and
calls were
being > disconnected.
you should not use or need to use lcr modules functions for re-invites. re-invites are in-dialog requests that
are forwarded
based on route headers.
-- juha
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
I did not think altering the From: header in anyway was legal.
If it is not legal, could the ;nat=yes tag be added to a Record-Route header?
Regards, Paul
On Wed, 16 Mar 2005 14:18:46 +1100, Zeus Ng zeus.ng@isquare.com.au wrote:
How about something like this.
With the initial INVITE,
... Route processing ... if (caller is natted) { subst('/From:(.*)<(.*)>(.*)/From:\1<\2>;nat=yes\3/'); }
call nathelper or mediaproxy
t_on_reply(nat reply route); t_relay();
In your reply route,
if (callee is natted) { subst('/From:(.*)<(.*)>(.*)/From:\1<\2>;nat=yes\3/'); call nathelper or mediaproxy ... Other processing ...
In your loose route,
if (loose_route()) { if (method=="INVITE") { if (search("my_ser_detect_nat=yes") || (sdp in private address )) { call nathelper or mediaproxy } } on reply route t_relay() }
This does work for me most of the time. However, there are odd situation that this does not work.
Zeus
-----Original Message----- From: Java Rockx [mailto:javarockx@gmail.com] Sent: Wednesday, 16 March 2005 12:01 PM To: Zeus Ng Cc: serusers@lists.iptel.org Subject: Re: [Serusers] LCR Backport Example For ser-0.9
OK, but there are two sides of the conversation to test here for NAT.
Should nat_uac_test("8") be used in a reply_route or something? (Actually this won't work because the re-INIVITE would need to have the c= field in the SDP rewritten if the destination is NATed).
Anyhow, I mean if the original INVITE is from a NATed client, then I can use client_nat_test() but on the destination side, I still need to know if RTP proxying is needed.
How do I do this?
Regards, Paul
On Wed, 16 Mar 2005 11:19:50 +1100, Zeus Ng zeus.ng@isquare.com.au wrote:
You won't be able to do lookup most of the time with
re-INVITE if it
falls into loose_route as the R-URI may have changed to sip:user@dest.ip.address. (The same applies to case without loose route as well)
With nathelper, you can do nat_uac_test("8") to test for private address in the SDP part and do rtpproxy according. Don't think mediaproxy has this test.
-----Original Message----- From: serusers-bounces@lists.iptel.org
[mailto:serusers-bounces@lists.iptel.org]
On Behalf Of Java Rockx Sent: Wednesday, 16 March 2005 9:03 AM To: serusers@lists.iptel.org; Juha Heinanen Subject: Re: [Serusers] LCR Backport Example For ser-0.9
Ahhh, I found my mistake, but can someone verify my thought process??
I'm using mediaproxy and I only proxy RTP streams if the
caller or
the callee are behind a NAT device.
So during a re-INVITE, I cannot just t_relay() the
message because
the RTP streams will end up at unreachable IP addresses if either SIP UA is NATed.
I can use client_nat_test("3") to test the caller's NAT settings, and for the callee I have to use lookup("location") and test my nat_flag setting.
But do I need to call revert_uri() after lookup("location") when processing re-INVITEs???
Regards, Paul
On Tue, 15 Mar 2005 16:17:38 -0500, Java Rockx
wrote:
Yep. I agree.
But does this mean for **any** SIP message that
loose_route() returns
TRUE, I simply call t_relay() and then stop processing
via a break
command?
I can't remember, but I thought I ran in to some cases
where even when
loose_route() returned TRUE, I still had to do some other
processing.
Regards, Paul
On Tue, 15 Mar 2005 20:13:40 +0200, Juha Heinanen
wrote:
Java Rockx writes:
> I thought I had mine right, but then I realized that some re-INVITE > messages were not being handled properly and
calls were
being > disconnected.
you should not use or need to use lcr modules functions for re-invites. re-invites are in-dialog requests that
are forwarded
based on route headers.
-- juha
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Zeus,
Thanks for that code snippet. That works like a charm!!!!
I just hope altering the from header doesn't break something.
Thanks again. Paul
On Tue, 15 Mar 2005 22:22:01 -0500, Java Rockx javarockx@gmail.com wrote:
I did not think altering the From: header in anyway was legal.
If it is not legal, could the ;nat=yes tag be added to a Record-Route header?
Regards, Paul
On Wed, 16 Mar 2005 14:18:46 +1100, Zeus Ng zeus.ng@isquare.com.au wrote:
How about something like this.
With the initial INVITE,
... Route processing ... if (caller is natted) { subst('/From:(.*)<(.*)>(.*)/From:\1<\2>;nat=yes\3/'); }
call nathelper or mediaproxy
t_on_reply(nat reply route); t_relay();
In your reply route,
if (callee is natted) { subst('/From:(.*)<(.*)>(.*)/From:\1<\2>;nat=yes\3/'); call nathelper or mediaproxy ... Other processing ...
In your loose route,
if (loose_route()) { if (method=="INVITE") { if (search("my_ser_detect_nat=yes") || (sdp in private address )) { call nathelper or mediaproxy } } on reply route t_relay() }
This does work for me most of the time. However, there are odd situation that this does not work.
Zeus
-----Original Message----- From: Java Rockx [mailto:javarockx@gmail.com] Sent: Wednesday, 16 March 2005 12:01 PM To: Zeus Ng Cc: serusers@lists.iptel.org Subject: Re: [Serusers] LCR Backport Example For ser-0.9
OK, but there are two sides of the conversation to test here for NAT.
Should nat_uac_test("8") be used in a reply_route or something? (Actually this won't work because the re-INIVITE would need to have the c= field in the SDP rewritten if the destination is NATed).
Anyhow, I mean if the original INVITE is from a NATed client, then I can use client_nat_test() but on the destination side, I still need to know if RTP proxying is needed.
How do I do this?
Regards, Paul
On Wed, 16 Mar 2005 11:19:50 +1100, Zeus Ng zeus.ng@isquare.com.au wrote:
You won't be able to do lookup most of the time with
re-INVITE if it
falls into loose_route as the R-URI may have changed to sip:user@dest.ip.address. (The same applies to case without loose route as well)
With nathelper, you can do nat_uac_test("8") to test for private address in the SDP part and do rtpproxy according. Don't think mediaproxy has this test.
-----Original Message----- From: serusers-bounces@lists.iptel.org
[mailto:serusers-bounces@lists.iptel.org]
On Behalf Of Java Rockx Sent: Wednesday, 16 March 2005 9:03 AM To: serusers@lists.iptel.org; Juha Heinanen Subject: Re: [Serusers] LCR Backport Example For ser-0.9
Ahhh, I found my mistake, but can someone verify my thought process??
I'm using mediaproxy and I only proxy RTP streams if the
caller or
the callee are behind a NAT device.
So during a re-INVITE, I cannot just t_relay() the
message because
the RTP streams will end up at unreachable IP addresses if either SIP UA is NATed.
I can use client_nat_test("3") to test the caller's NAT settings, and for the callee I have to use lookup("location") and test my nat_flag setting.
But do I need to call revert_uri() after lookup("location") when processing re-INVITEs???
Regards, Paul
On Tue, 15 Mar 2005 16:17:38 -0500, Java Rockx
wrote:
Yep. I agree.
But does this mean for **any** SIP message that
loose_route() returns
TRUE, I simply call t_relay() and then stop processing
via a break
command?
I can't remember, but I thought I ran in to some cases
where even when
loose_route() returned TRUE, I still had to do some other
processing.
Regards, Paul
On Tue, 15 Mar 2005 20:13:40 +0200, Juha Heinanen
wrote: > Java Rockx writes: > > > I thought I had mine right, but then I realized that some > re-INVITE > messages were not being handled properly and
calls were
> being > disconnected. > > you should not use or need to use lcr modules functions for > re-invites. re-invites are in-dialog requests that
are forwarded
> based on route headers. > > -- juha >
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
I fully agree.
I am starting to think the best approach is to leave all SIP headers untouched and alter the nathelper and/or mediaproxy modules by giving them the ability to "lookup" a call-id and return TRUE or FALSE to indicate that a call is already in progress. By doing so ser would totally eliminate any need to alter SIP headers.
So something like this I think would do the trick:
route { # usual sanity checks
if (loose_route()) { if (media_proxy_has_session()) { use_media_proxy(); }; t_relay(); break; };
# other usual stuff - like lookup('location') }
Regards, Paul
On Wed, 16 Mar 2005 15:42:26 +1100, Zeus Ng zeus.ng@isquare.com.au wrote:
Paul,
I just hope altering the from header doesn't break something.
It does in some cases. So, be warn. I encourage the community not to do this unless your know what you are doing! Test with all UA you have before pushing to production!
Zeus
Well, legal or not, I can't say. I agree that we shall not touch the From, To header. But, I try to fool myself to interpret it like this. The URI part CANNOT be changed. Adding a tag should do little harm.
From my understanding, you can't change record route header because SER use
it to do comparison. That's why I try to hack the From, To header. BUT, a big BUT, don't use this method unless necessary. I've seem UA doing strict on the rule and refuse to treat xx@yy.com;tag=1234 the same as xx@yy.com;tag=1234;nat=yes and break the call. This is no fault to the UA. It's just following the rule. However, it breaks my NAT handling for re-INVITE in loose route which change media IP or port. For on hold call (IP 0.0.0.0) and re-INVITE that just change codec and not touching IP or port, I just ignore them.
-----Original Message----- From: Java Rockx [mailto:javarockx@gmail.com] Sent: Wednesday, 16 March 2005 2:22 PM To: Zeus Ng Cc: serusers@lists.iptel.org Subject: Re: [Serusers] LCR Backport Example For ser-0.9
I did not think altering the From: header in anyway was legal.
If it is not legal, could the ;nat=yes tag be added to a Record-Route header?
Regards, Paul
On Wed, 16 Mar 2005 14:18:46 +1100, Zeus Ng zeus.ng@isquare.com.au wrote:
How about something like this.
With the initial INVITE,
... Route processing ... if (caller is natted) { subst('/From:(.*)<(.*)>(.*)/From:\1<\2>;nat=yes\3/'); }
call nathelper or mediaproxy
t_on_reply(nat reply route); t_relay();
In your reply route,
if (callee is natted) { subst('/From:(.*)<(.*)>(.*)/From:\1<\2>;nat=yes\3/'); call nathelper or mediaproxy ... Other processing ...
In your loose route,
if (loose_route()) { if (method=="INVITE") { if (search("my_ser_detect_nat=yes") || (sdp in
private address )) {
call nathelper or mediaproxy } } on reply route t_relay()}
This does work for me most of the time. However, there are odd situation that this does not work.
Zeus
-----Original Message----- From: Java Rockx [mailto:javarockx@gmail.com] Sent: Wednesday, 16 March 2005 12:01 PM To: Zeus Ng Cc: serusers@lists.iptel.org Subject: Re: [Serusers] LCR Backport Example For ser-0.9
OK, but there are two sides of the conversation to test here for NAT.
Should nat_uac_test("8") be used in a reply_route or something? (Actually this won't work because the re-INIVITE would
need to have
the c= field in the SDP rewritten if the destination is NATed).
Anyhow, I mean if the original INVITE is from a NATed
client, then I
can use client_nat_test() but on the destination side, I
still need
to know if RTP proxying is needed.
How do I do this?
Regards, Paul
-
Java Rockx -
Juha Heinanen -
Zeus Ng