10 Jun
2008
10 Jun
'08
1:35 a.m.
I'm having a problem using loose_route, and I'm not sure if it's a
bug/feature/misunderstanding.
I have a B2BUA (Asterisk) running on the same system as OpenSER, and in
my failure_route for voicemail I direct calls there which actually sends
them on to the voicemail server. If someone 'zeroes out' of voicemail,
to be forwarded to the operator, the voicemail server issues a re-INVITE
to redirect media. This is where the problem comes in.
If I try to loose_route this re-INVITE, it fails. However, putting the
B2BUA on a different system works fine.
This is running OpenSER 1.2.3 currently, though I'm not particularly
averse to upgrading to the latest 1.3.x if for some reason this is
something that's been resolved there.
Any suggestions?
Thanks in advance,
- Brad
10 Jun
10 Jun
1:45 a.m.
On Mon, Jun 9, 2008 at 6:35 PM, Watkins, Bradley
<Bradley.Watkins(a)compuware.com> wrote:
I'm having a problem using loose_route, and
I'm not sure if it's a
bug/feature/misunderstanding.
I have a B2BUA (Asterisk) running on the same system as OpenSER, and in
my failure_route for voicemail I direct calls there which actually sends
them on to the voicemail server. If someone 'zeroes out' of voicemail,
to be forwarded to the operator, the voicemail server issues a re-INVITE
to redirect media. This is where the problem comes in.
If I try to loose_route this re-INVITE, it fails. However, putting the
B2BUA on a different system works fine.
I'm not sure that this is a loose routing problem. A SIP message trace
and an Asterisk 'sip set debug' trace can help identify the issue.
--
Raj Jain
11:56 p.m.
-----Original Message-----
From: Raj Jain [mailto:rj2807@gmail.com]
Sent: Monday, June 09, 2008 6:46 PM
To: Watkins, Bradley
Cc: users(a)lists.openser.org
Subject: Re: [OpenSER-Users] Loose route problem or misunderstanding
On Mon, Jun 9, 2008 at 6:35 PM, Watkins, Bradley
<Bradley.Watkins(a)compuware.com> wrote:
I'm quite sure that it is, actually. Mind you, it could be that I'm
expecting loose_route to do something that by RFC compliance it
shouldn't, hence the admission that I may be misunderstanding.
Here's the relevant SIP messages for a failing scenario:
U 10.3.104.104:5060 -> 10.0.12.51:5060
INVITE sip:71841@10.0.12.51:5062 SIP/2.0.
From: <sip:77740@10.0.12.51>;tag=6868030a-13c4-4848318e-d46a11b5-7671.
To: "Brad Watkins"<sip:71841@10.0.12.51:5062>;tag=as75bb16a1.
Call-ID: 75bd11cb40e6f85239b3bf6c525bb206(a)10.0.12.51.
CSeq: 2 INVITE.
Via: SIP/2.0/UDP
10.3.104.104:5060;branch=z9hG4bK-484831a0-d46a55df-21eb.
Supported: 100rel,sipvc,replaces,timer.
User-Agent: Nortel CS1000 SIP GW release_4.5 version_sse-4.50.88.
P-Asserted-Identity:
<sip:5077740;phone-context=udp@compuware.com;user=phone>.
Privacy: none.
Contact:
<sip:5077740;phone-context=udp@compuware.com:5060;maddr=10.3.104.104;tra
nsport=udp;user=phone>.
Route: <sip:10.0.12.51;lr;ftag=as75bb16a1>.
Allow:
INVITE,ACK,BYE,REGISTER,REFER,NOTIFY,CANCEL,PRACK,OPTIONS,INFO,SUBSCRIBE
,UPDATE.
Content-Type: application/SDP.
Content-Length: 148.
.
v=0.
o=- 121469 3 IN IP4 10.3.104.104.
s=-.
t=0 0.
m=audio 5202 RTP/AVP 0 8 18.
c=IN IP4 10.3.102.105.
a=fmtp:18 annexb=no.
a=ptime:20.
a=sendrecv.
#
U 10.0.12.51:5060 -> 10.3.104.104:5060
SIP/2.0 100 Giving a try.
From: <sip:77740@10.0.12.51>;tag=6868030a-13c4-4848318e-d46a11b5-7671.
To: "Brad Watkins"<sip:71841@10.0.12.51:5062>;tag=as75bb16a1.
Call-ID: 75bd11cb40e6f85239b3bf6c525bb206(a)10.0.12.51.
CSeq: 2 INVITE.
Via: SIP/2.0/UDP
10.3.104.104:5060;branch=z9hG4bK-484831a0-d46a55df-21eb.
Server: OpenSER (1.2.3-notls (i386/linux)).
Content-Length: 0.
.
#
U 10.0.12.51:5060 -> 10.3.104.104:5060
SIP/2.0 404 Not here.
From: <sip:77740@10.0.12.51>;tag=6868030a-13c4-4848318e-d46a11b5-7671.
To: "Brad Watkins"<sip:71841@10.0.12.51:5062>;tag=as75bb16a1.
Call-ID: 75bd11cb40e6f85239b3bf6c525bb206(a)10.0.12.51.
CSeq: 2 INVITE.
Via: SIP/2.0/UDP
10.3.104.104:5060;branch=z9hG4bK-484831a0-d46a55df-21eb.
Server: OpenSER (1.2.3-notls (i386/linux)).
Content-Length: 0.
This is with a basic loose-routing construct from the sample config:
if (has_totag()) {
# sequential request within a dialog should
# take the path determined by record-routing
if (loose_route()) {
loose_route();
route(1);
} else {
sl_send_reply("404","Not here");
}
exit;
And here's a working snippet, with the exact same OpenSER config and
Asterisk config (except bindport on Asterisk), except with Asterisk on a
separate machine:
U 10.3.104.104:5060 -> 10.0.12.51:5060
INVITE sip:71841@10.0.12.52 SIP/2.0.
From: <sip:77740@10.0.12.51>;tag=6868030a-13c4-484eb0f3-edcbf878-e5e.
To: "Brad Watkins"<sip:71841@10.0.12.52>;tag=as7c7f08f2.
Call-ID: 2058be9c5b530f237378e77f2c12f5dd(a)10.0.12.52.
CSeq: 2 INVITE.
Via: SIP/2.0/UDP 10.3.104.104:5060;branch=z9hG4bK-484eb100-edcc2deb-b36.
Supported: 100rel,sipvc,replaces,timer.
User-Agent: Nortel CS1000 SIP GW release_4.5 version_sse-4.50.88.
P-Asserted-Identity:
<sip:5077740;phone-context=udp@compuware.com;user=phone>.
Privacy: none.
Contact:
<sip:5077740;phone-context=udp@compuware.com:5060;maddr=10.3.104.104;tra
nsport=udp;user=phone>.
Route: <sip:10.0.12.51;lr;ftag=as7c7f08f2>.
Allow:
INVITE,ACK,BYE,REGISTER,REFER,NOTIFY,CANCEL,PRACK,OPTIONS,INFO,SUBSCRIBE
,UPDATE.
Content-Type: application/SDP.
Content-Length: 148.
.
v=0.
o=- 126019 3 IN IP4 10.3.104.104.
s=-.
t=0 0.
m=audio 5214 RTP/AVP 0 8 18.
c=IN IP4 10.3.102.107.
a=fmtp:18 annexb=no.
a=ptime:20.
a=sendrecv.
#
U 10.0.12.51:5060 -> 10.3.104.104:5060
SIP/2.0 100 Giving a try.
From: <sip:77740@10.0.12.51>;tag=6868030a-13c4-484eb0f3-edcbf878-e5e.
To: "Brad Watkins"<sip:71841@10.0.12.52>;tag=as7c7f08f2.
Call-ID: 2058be9c5b530f237378e77f2c12f5dd(a)10.0.12.52.
CSeq: 2 INVITE.
Via: SIP/2.0/UDP 10.3.104.104:5060;branch=z9hG4bK-484eb100-edcc2deb-b36.
Server: OpenSER (1.2.3-notls (i386/linux)).
Content-Length: 0.
.
#
U 10.0.12.51:5060 -> 10.3.104.104:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP 10.3.104.104:5060;branch=z9hG4bK-484eb100-edcc2deb-b36.
From: <sip:77740@10.0.12.51>;tag=6868030a-13c4-484eb0f3-edcbf878-e5e.
To: "Brad Watkins"<sip:71841@10.0.12.52>;tag=as7c7f08f2.
Call-ID: 2058be9c5b530f237378e77f2c12f5dd(a)10.0.12.52.
CSeq: 2 INVITE.
User-Agent: Asterisk PBX.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY.
Supported: replaces.
Contact: <sip:71841@10.0.12.52>.
Content-Type: application/sdp.
Content-Length: 176.
.
v=0.
o=root 407 409 IN IP4 10.0.12.52.
s=session.
c=IN IP4 10.0.12.52.
t=0 0.
m=audio 18948 RTP/AVP 0.
a=rtpmap:0 PCMU/8000.
a=silenceSupp:off - - - -.
a=ptime:20.
a=sendrecv.
I'm having a problem using loose_route, and
I'm not sure if it's a
bug/feature/misunderstanding.
I have a B2BUA (Asterisk) running on the same system as
OpenSER, and in
my failure_route for voicemail I direct calls
there which
actually sends
them on to the voicemail server. If someone
'zeroes out'
of voicemail,
to be forwarded to the operator, the voicemail
server
issues a re-INVITE
to redirect media. This is where the problem
comes in.
If I try to loose_route this re-INVITE, it fails. However,
putting the
B2BUA on a different system works fine.
I'm not sure that this is a loose routing problem. A SIP message trace
and an Asterisk 'sip set debug' trace can help identify the issue.
--
Raj Jain
11 Jun
11 Jun
12:14 a.m.
El Martes, 10 de Junio de 2008, Watkins, Bradley escribió:
I'm quite sure that it is, actually. Mind you, it
could be that I'm
expecting loose_route to do something that by RFC compliance it
shouldn't, hence the admission that I may be misunderstanding.
Here's the relevant SIP messages for a failing scenario:
This is an in-dialog request, so WHY the host of the RURI is the OpenSer IP
(10.0.12.51) instead of the UA "Contact" IP?
Of course this is incorrect. The RURI host in any in-dialog request must be
the remote-target (this is: the host in the received "Contact" from the other
end point).
Nortel CS1000? I've bad experiences with a Nortel CS2000 but it *does* well
loose-routing not as in your case.
U 10.3.104.104:5060 -> 10.0.12.51:5060
INVITE sip:71841@10.0.12.51:5062 SIP/2.0.
From: <sip:77740@10.0.12.51>;tag=6868030a-13c4-4848318e-d46a11b5-7671.
To: "Brad Watkins"<sip:71841@10.0.12.51:5062>;tag=as75bb16a1.
Call-ID: 75bd11cb40e6f85239b3bf6c525bb206(a)10.0.12.51.
CSeq: 2 INVITE.
Via: SIP/2.0/UDP
10.3.104.104:5060;branch=z9hG4bK-484831a0-d46a55df-21eb.
Supported: 100rel,sipvc,replaces,timer.
User-Agent: Nortel CS1000 SIP GW release_4.5 version_sse-4.50.88.
P-Asserted-Identity:
<sip:5077740;phone-context=udp@compuware.com;user=phone>.
Privacy: none.
Contact:
<sip:5077740;phone-context=udp@compuware.com:5060;maddr=10.3.104.104;tra
nsport=udp;user=phone>.
Route: <sip:10.0.12.51;lr;ftag=as75bb16a1>.
Allow:
INVITE,ACK,BYE,REGISTER,REFER,NOTIFY,CANCEL,PRACK,OPTIONS,INFO,SUBSCRIBE
,UPDATE.
Content-Type: application/SDP.
Content-Length: 148.
.
v=0.
o=- 121469 3 IN IP4 10.3.104.104.
s=-.
t=0 0.
m=audio 5202 RTP/AVP 0 8 18.
c=IN IP4 10.3.102.105.
a=fmtp:18 annexb=no.
a=ptime:20.
a=sendrecv.
#
U 10.0.12.51:5060 -> 10.3.104.104:5060
SIP/2.0 100 Giving a try.
From: <sip:77740@10.0.12.51>;tag=6868030a-13c4-4848318e-d46a11b5-7671.
To: "Brad Watkins"<sip:71841@10.0.12.51:5062>;tag=as75bb16a1.
Call-ID: 75bd11cb40e6f85239b3bf6c525bb206(a)10.0.12.51.
CSeq: 2 INVITE.
Via: SIP/2.0/UDP
10.3.104.104:5060;branch=z9hG4bK-484831a0-d46a55df-21eb.
Server: OpenSER (1.2.3-notls (i386/linux)).
Content-Length: 0.
.
#
U 10.0.12.51:5060 -> 10.3.104.104:5060
SIP/2.0 404 Not here.
From: <sip:77740@10.0.12.51>;tag=6868030a-13c4-4848318e-d46a11b5-7671.
To: "Brad Watkins"<sip:71841@10.0.12.51:5062>;tag=as75bb16a1.
Call-ID: 75bd11cb40e6f85239b3bf6c525bb206(a)10.0.12.51.
CSeq: 2 INVITE.
Via: SIP/2.0/UDP
10.3.104.104:5060;branch=z9hG4bK-484831a0-d46a55df-21eb.
Server: OpenSER (1.2.3-notls (i386/linux)).
Content-Length: 0.
This is with a basic loose-routing construct from the sample config:
if (has_totag()) {
# sequential request within a dialog should
# take the path determined by record-routing
if (loose_route()) {
loose_route();
Take off the second "loose_route()", it has been done into the "if"
stament.
route(1);
} else {
sl_send_reply("404","Not here");
}
exit;
loose_route() examines the top "Route" header (10.0.12.51) and matches it
agains OpenSer knows IP's and hostnames (and domains).
If it matches (and it does it) it takes off the "Route" header and send the
request to the URI indicated in the RURI (if there is not more "Route"
headers), but note that the request RURI is:
INVITE sip:71841@10.0.12.51:5062 SIP/2.0
So it's 10.0.12.51: OpenSer IP !!!!!
so OpenSer routes the request to itself !!!
When the request arrives again to OpenSer (looped) it has "To" tag but
not "Route" header so OpenSer replies with a correct "404: Not here".
It's
100% correct.
The problem is the host of the RURI in the in-dialog request. Could you show
how the INITIAL INVITE arrives to the Nortel (in case a UAC calls the
Nortel), or the 200 OK arriving to Nortel (if Nortel initiates the call).
--
Iñaki Baz Castillo
1:21 a.m.
-----Original Message-----
From: users-bounces(a)lists.openser.org
[mailto:users-bounces@lists.openser.org] On Behalf Of Iñaki
Baz Castillo
Sent: Tuesday, June 10, 2008 5:14 PM
To: users(a)lists.openser.org
Subject: Re: [OpenSER-Users] Loose route problem or misunderstanding
El Martes, 10 de Junio de 2008, Watkins, Bradley escribió:
The remote target is on the same machine, but on a different port. OpenSER is
listening on 5060, Asterisk is listening on 5062.
I'm quite sure that it is, actually. Mind
you, it could be that I'm
expecting loose_route to do something that by RFC compliance it
shouldn't, hence the admission that I may be misunderstanding.
Here's the relevant SIP messages for a failing scenario:
This is an in-dialog request, so WHY the host of the RURI is
the OpenSer IP
(10.0.12.51) instead of the UA "Contact" IP?
Of course this is incorrect. The RURI host in any in-dialog
request must be
the remote-target (this is: the host in the received
"Contact" from the other
end point).
Nortel CS1000? I've bad experiences with a Nortel
CS2000 but
it *does* well
loose-routing not as in your case.
This is a CS1k, but the question is a vagary of my setup. Unfortunately, this is one
problem I can't blame on the Nortel. ;)
Not to worry, there are plenty of others that I know for sure I can. :)
loose_route() examines the top "Route"
header (10.0.12.51)
and matches it
agains OpenSer knows IP's and hostnames (and domains).
If it matches (and it does it) it takes off the "Route"
header and send the
request to the URI indicated in the RURI (if there is not
more "Route"
headers), but note that the request RURI is:
INVITE sip:71841@10.0.12.51:5062 SIP/2.0
Yes, but if it were doing that it would work fine. Again, the endpoint here is on the
same system, but a different port.
So it's 10.0.12.51: OpenSer IP !!!!!
so OpenSer routes the request to itself !!!
When the request arrives again to OpenSer (looped) it has
"To" tag but
not "Route" header so OpenSer replies with a correct "404:
Not here". It's
100% correct.
But it shouldn't be sending it to itself at all. If it is, then it's ignoring the
port in the RURI and that's certainly incorrect.
The problem is the host of the RURI in the in-dialog
request.
Could you show
how the INITIAL INVITE arrives to the Nortel (in case a UAC calls the
Nortel), or the 200 OK arriving to Nortel (if Nortel
initiates the call).
I can, but it will have to wait until tomorrow I'm afraid. I'm away from those
systems for the evening.
1:35 a.m.
El Miércoles, 11 de Junio de 2008, Watkins, Bradley escribió:
You are completely right, sorry, I didn't realize on the different port.
So a SIP trace of what happens in that machine would be needed. Could you
provide a complete SIP flow? it's neccesary to see also the flow between
OpenSer and Asterisk.
--
Iñaki Baz Castillo
This is an
in-dialog request, so WHY the host of the RURI is
the OpenSer IP
(10.0.12.51) instead of the UA "Contact" IP?
Of course this is incorrect. The RURI host in any in-dialog
request must be
the remote-target (this is: the host in the received
"Contact" from the other
end point).
The remote target is on the same machine, but on a different port. OpenSER
is listening on 5060, Asterisk is listening on 5062.
14 Jun
14 Jun
2:13 a.m.
-----Original Message-----
From: users-bounces(a)lists.openser.org
[mailto:users-bounces@lists.openser.org] On Behalf Of Iñaki
Baz Castillo
Sent: Tuesday, June 10, 2008 6:35 PM
To: users(a)lists.openser.org
Subject: Re: [OpenSER-Users] Loose route problem or misunderstanding
El Miércoles, 11 de Junio de 2008, Watkins, Bradley escribió:
Apparently, it pays to read the documentation...
In particular, the entry in the core cookbook for alias:
"It is necessary to include the port (the port value used in the "port=" or
"listen=" defintions) in the alias definition otherwise the loose_route()
function will not work as expected for local forwards"
This was exactly my problem.
I'm not entirely sure I agree with assuming that OpenSER is responsible for EVERY
port, even when it's configure to only listen on one. But at any rate, changing a few
lines to include the port number makes this work for me so I won't complain too
loudly.
Thanks for taking the time to try and help me with this issue.
Regards,
- Brad
The remote target is on the same machine, but on
a
different port. OpenSER
is listening on 5060, Asterisk is listening on
5062.
You are completely right, sorry, I didn't realize on the
different port.
So a SIP trace of what happens in that machine would be
needed. Could you
provide a complete SIP flow? it's neccesary to see also the
flow between
OpenSer and Asterisk.
6008
days inactive
6012
days old
6 comments
3 participants
participants (3)
-
Iñaki Baz Castillo -
Raj Jain -
Watkins, Bradley