[OpenSER-Users] Openser 1.3 How to rewrite transport protocol from udp to tcp after redirect
16 Jan
2008
16 Jan
'08
11:25 p.m.
Hello,
I have the following scenario:
SIP UA <=UDP=> OpenSER <=TCP> Microsoft Unified Messaging 2007
When I invite an account on the UM 2007 server the following happens
1 SIP UA ==Invite UDP=> OpenSER
2 SIP UA <== 407 Proxy Authentication Required UDP= OpenSER
3 SIP UA ==ACK UDP=> OpenSER
4 SIP UA ==Invite UDP=> OpenSER
5 OpenSER ==Invite TCP=> UM2007
6 OpenSER <=Trying TCP== UM2007
7 OpenSER <= 302 Moved Temporarily TCP== UM2007
8 OpenSER == ACK TCP=> UM2007
9 OpenSER == INVITE UDP=> UM2007
.....no answer from UM2007
(I left out some steps between Openser and UA)
In Step 5 OpenSER invites "sip:11111@10.10.2.13;transport=UDP>" with TCP
protocol (checked with ngrep) and UM2007 answers.
In Step 7 UM2007 answers with CONTACT:
<sip:11111@10.10.2.13:5065;transport=UDP> but I need to answer on TCP to
UM2007.
(I can change the message with add_uri_param("transport=tcp") in step 5
and I get a <sip:11111@10.10.2.13:5065;transport=TCP> back from UA2007,
but in fact the message is corrupted and OpenSER replies to the UA with
Error 500 then, see below)
The point is:
- I can invite UM2007 with TCP (although I was not able to produce
correct headers as there is still "transport=udp;>" mentioned in the
INVITE part)
- but in the failure route when I force OpenSER to reinvite with
get_redirects("*") and t_relay() I am not able to swith to TCP
I tried several ways as described in discussions which I found in
http://osdir.com/ml/voip.openser.user/2005-12/msg00256.html
- add_uri_param("transport=tcp"); ==> added transport=tcp additionally
to transport=udp ==> transport=udp;transport=tcp ==> 500 Internal
Server error
- $avp(s:foo)="sip:10.10.2.13;transport=tcp";
avp_pushto("$du","$avp(s:foo)"); ==>had
actually
no effect
- replace_all("transport=udp", "transport=tcp"); ==> produced
invalid
headers as it simply replaced the headers wrongly as described in
http://openser.org/pipermail/devel/2007-May/007702.html
Questions:
1. How can I change the initial INVITe message (Step5) in order to have
the right headers. (transport=TCP instead of transport=UDP)?
2. How can I answer to a redirect and change to a different transport
protocol (Step 9)?
Your help is very much appreciated.
Best regards
Peter
16 Jan
16 Jan
11:42 p.m.
New subject: [OpenSER-Users] Openser 1.3 How to rewrite transport protocol from udp to tcp after redirect
El Miércoles, 16 de Enero de 2008, Peter P GMX escribió:
SIP UA <=UDP=> OpenSER <=TCP> Microsoft
Unified Messaging 2007
When I invite an account on the UM 2007 server the following happens
1 SIP UA ==Invite UDP=> OpenSER
2 SIP UA <== 407 Proxy Authentication Required UDP= OpenSER
3 SIP UA ==ACK UDP=> OpenSER
4 SIP UA ==Invite UDP=> OpenSER
5 OpenSER ==Invite TCP=> UM2007
6 OpenSER <=Trying TCP== UM2007
7 OpenSER <= 302 Moved Temporarily TCP== UM2007
8 OpenSER == ACK TCP=> UM2007
9 OpenSER == INVITE UDP=> UM2007
.....no answer from UM2007
1. How can I change the initial INVITe message (Step5)
in order to have
the right headers. (transport=TCP instead of transport=UDP)?
I suppose that the account in UM 2007 is not registered in OpenSer so you need
to specify protocol TCP in the t_relay(). How do you use "t_relay()" to
contact UM 2007?
--
Iñaki Baz Castillo
17 Jan
17 Jan
10:11 a.m.
Thanks for your quick reply,
I have the following routes:
For the invites
route[6] {
# -----------------------------------------------------------------
# Exchange 2007 Handler
# -----------------------------------------------------------------
xlog("L_INFO","Step 600 Entering ==== Route 6 (Exchange 2007)
======");
force_send_socket(10.10.2.24:5060); # for sending requets on eth1
if (t_relay("tcp:10.10.2.13:5060")){
xlog("L_INFO", "Step 601: Forward to UM2007 succecssful - From=$fu
To=$tu\n");
}else{
xlog("L_INFO", "Step 602: Forward to UM2007 not successful -
From=$fu To=$tu\n");
};
}
For the failure route
failure_route[1] {
xlog("L_INFO","Step 700 Entering ==== Failure Route 1 ======");
xlog("L_INFO","Step 701:Method [$rm]");
if (method=="INVITE"){
get_redirects("*");
force_send_socket(10.10.2.24:5060); # for sending requets on eth1
if (t_relay()){
xlog("L_INFO","Step 702: t_relay ok");
}
}
}
As UM requests a different port (5065) in the 302 message, I cannot use
t_relay with TCP in the failure_route. With t_relay I have to submit the
whole address like
t_relay(tcp: dest_ip:port) and I cannot always predict the port in this
case.
Best regards
Peter
Iñaki Baz Castillo schrieb:
El Miércoles, 16 de Enero de 2008, Peter P GMX
escribió:
SIP UA <=UDP=> OpenSER <=TCP>
Microsoft Unified Messaging 2007
When I invite an account on the UM 2007 server the following happens
1 SIP UA ==Invite UDP=> OpenSER
2 SIP UA <== 407 Proxy Authentication Required UDP= OpenSER
3 SIP UA ==ACK UDP=> OpenSER
4 SIP UA ==Invite UDP=> OpenSER
5 OpenSER ==Invite TCP=> UM2007
6 OpenSER <=Trying TCP== UM2007
7 OpenSER <= 302 Moved Temporarily TCP== UM2007
8 OpenSER == ACK TCP=> UM2007
9 OpenSER == INVITE UDP=> UM2007
.....no answer from UM2007
1. How can I change the initial INVITe message
(Step5) in order to have
the right headers. (transport=TCP instead of transport=UDP)?
I suppose that the account in UM 2007 is not registered in OpenSer so you need
to specify protocol TCP in the t_relay(). How do you use "t_relay()" to
contact UM 2007?
10:47 a.m.
New subject: [OpenSER-Users] Openser 1.3 How to rewrite transport protocol from udp to tcp after redirect
On Thursday 17 January 2008 10:11:48 Peter P GMX wrote:
As UM requests a different port (5065) in the 302
message, I cannot use
t_relay with TCP in the failure_route. With t_relay I have to submit the
whole address like
t_relay(tcp: dest_ip:port) and I cannot always predict the port in this
case.
Could you show the received 302 from UM?
I understand that it's something as:
SIP/2.0 302 Redirection
...
Contact: <sip:other_user@10.10.2.13:5065>;transport=TCP
Is it?
And you say that sometime the "Contact" port is 5065 and sometimes 5060? or
there are more possible values?
In case they are a fixed number of values you can do a very dirty trick:
if ( $(ct{uri.port}) == "5065" )
t_relay("tcp:10.10.2.13:5065"
else if ( $(ct{uri.port}) == "5060" )
t_relay("tcp:10.10.2.13:5060"
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
6:46 p.m.
When I send an INVITE as follows (with transport=UDP) but sent via TCP:
(UA=10.5.3.22 internal, 82.135.xx.xxx external)
=====================
T 10.10.2.24:27838 -> 10.10.2.13:5060 [AP]
INVITE sip:11111@10.10.2.13;transport=UDP SIP/2.0..Record-Route:
<sip:88.217.xxx.x:5060:nat=yes;ftag=4b086b07;lr=on>..Via: SIP/2.0/TCP
10.10.2.24;branch=z9hG4bK3
e88.e9631885.0..Via: SIP/2.0/UDP
10.5.3.22:5060;received=82.135.xx.xxx;branch=z9hG4bK-d8754z-be756d81d31da419-1---d8754z-;rport=5060..Max-Forwards:
69..Contact:
<sip:6005@82.135.xx.xxx:5060>..To:
<sip:11111@my.openser.de>;transport=UDP..From:
"6005"<sip:6005@my.openser.de>;transport=UDP;tag=4b086b07..Call-ID:
NjQxNjk3Z
DczZDkzN2ZmMzI5MzdiNzhkMzdmZTg0YzM...CSeq: 2 INVITE..Allow: INVITE,
ACK, CANCEL, OPTIONS, BYE, NOTIFY, REFER, MESSAGE, OPTIONS,
INFO..Content-Type: application/s
dp..User-Agent: Zoiper rev.570..Content-Length: 319..Remote-Party-ID:
8154711;party=calling;id-type=subscriber;screen=yes....v=0..o=Zoiper_user
0 0 IN IP4
10.5.3.22..s=Zoiper_user..c=IN IP4 10.5.3.22..t=0 0..m=audio 12000
RTP/AVP 110 98 0 3 8 101..a=rtpmap:110 speex/8000..a=rtpmap:98
iLBC/8000..a=fmtp:98 mode=30..a
=rtpmap:0 PCMU/8000..a=rtpmap:3 GSM/8000..a=rtpmap:8
PCMA/8000..a=rtpmap:101 telephone-event/8000..a=fmtp:101 0-15..a=sendrecv..
the 302 message is as follows
=====================
In this case it answers per UPD as I explained before when OpenSER
T 10.10.2.13:5060 -> 10.10.2.24:27838 [AP]
SIP/2.0 302 Moved Temporarily
FROM: "6005"<sip:6005@my.openser.de>;tag=4b086b07;transport=UDP
TO: <sip:11111@my.openser.de>;transport=UDP;tag=9cca2fa224
CSEQ: 2 INVITE
CALL-ID: NjQxNjk3ZDczZDkzN2ZmMzI5MzdiNzhkMzdmZTg0YzM
MAX-FORWARDS: 70
VIA: SIP/2.0/TCP 10.10.2.24;branch=z9hG4bK3e88.e9631885.0,SIP/2.0/UDP
10.5.3.22:5060;received=82.135.xx.xxx;branch=z9hG4bK-d8754z-be756d81d31da419-1---d8754z-;rport=5060
CONTENT-LENGTH: 0..
SERVER: RTCC/2.0.6017.0..CONTACT: <sip:11111@10.10.2.13:5065;transport=UDP>
So CONTACT: <sip:11111@10.10.2.13:5065;transport=UDP> refers to UDP
When I send an INVITe with add_uri_param("transport=tcp");
(UA=192.168.178.60 local, 217.24.xxx.xxx external)
=====================
T 10.10.2.24:19034 -> 10.10.2.13:5060 [AP]
INVITE sip:11111@10.10.2.13;transport=tcp SIP/2.0..Record-Route:
<sip:88.217.xxx.x:5060:nat=yes;ftag=60263e79;lr=on>..Via: SIP/2.0/TCP
10.10.2.24;branch=z9hG4bK4
0d3.ce138151.0..Via: SIP/2.0/UDP
192.168.178.60:5060;received=217.24.xxx.xxx;branch=z9hG4bK-d8754z-83461a97f67a9e27-1---d8754z-;rport=5060..Max-Forwards:
69..Cont
act: <sip:6004@217.24.xxx.xxx:5060>..To:
<sip:11111@my.openser.de>..From:
"6004"<sip:6004@my.openser.de>;transport=UDP;tag=60263e79..Call-ID:
YzZiNmJkNTQ2MjI3ZT
c5MWQ5Yjk4N2ZkYjg0MDE0MGI...CSeq: 2 INVITE..Allow: INVITE, ACK,
CANCEL, OPTIONS, BYE, NOTIFY, REFER, MESSAGE, OPTIONS..Content-Type:
application/sdp..User-Agent:
Zoiper rev.416..Content-Length: 380..Remote-Party-ID:
8154712;party=calling;id-type=subscriber;screen=yes....v=0..o=Zoiper_user
484683138 1181609789 IN IP
4 192.168.178.60..s=Zoiper_user..c=IN IP4 192.168.178.60..t=0
0..m=audio 12000 RTP/AVP 3 110 97 8 0 98 101..a=fmtp:97
mode=30..a=fmtp:98 mode=20..a=fmtp:101 0-1
5..a=rtpmap:3 GSM/8000..a=rtpmap:110 speex/8000..a=rtpmap:97
iLBC/8000..a=rtpmap:8 PCMA/8000..a=rtpmap:0 PCMU/8000..a=rtpmap:98
iLBC/8000..a=rtpmap:101 telephone
-event/8000..
the 302 message is as follows
=====================
T 10.10.2.13:5060 -> 10.10.2.24:19034 [AP]
SIP/2.0 302 Moved Temporarily..
FROM: "6004"<sip:6004@my.openser.de>;tag=60263e79;transport=UDP
TO: <sip:11111@my.openser.de>;tag=1013625314
CSEQ: 2 INVITE..
CALL-ID: YzZiNmJkNTQ2MjI3ZTc5MWQ5Yjk4N2ZkYjg0MDE0MGI...
MAX-FORWARDS: 70..
VIA: SIP/2.0/TCP 10.10.2.24;branch=z9hG4bK40d3.ce138151.0,SIP/2.0/UDP
192.168.178.60:5060
;received=217.24.xxx.xxx;branch=z9hG4bK-d8754z-83461a97f67a9e27-1---d8754z-;rport=5060..
CONTENT-LENGTH: 0
SERVER: RTCC/2.0.6017.0
CONTACT: <sip:11111@10.10.2.13:5065;transport=tcp>....
##
So CONTACT: <sip:11111@10.10.2.13:5065;transport=tcp> refers to TCP
But then I get an Internal Server error 500 from OpenSER
=======================================================
Here is the complete sequence (ngrep) for the 2nd case
=======================================================
U 217.24.xxx.xxx:5060 -> 88.217.xxx.x:5060
INVITE sip:11111@my.openser.de SIP/2.0..Via: SIP/2.0/UDP
192.168.178.60:5060;branch=z9hG4bK-d8754z-272fe27654f4653a-1---d8754z-;rport..Max-Forwards:
70..Contact
: <sip:6004@192.168.178.60:5060>..To: <sip:11111@my.openser.de>..From:
"6004"<sip:6004@my.openser.de>;transport=UDP;tag=60263e79..Call-ID:
YzZiNmJkNTQ2MjI3ZTc5
MWQ5Yjk4N2ZkYjg0MDE0MGI...CSeq: 1 INVITE..Allow: INVITE, ACK, CANCEL,
OPTIONS, BYE, NOTIFY, REFER, MESSAGE, OPTIONS..Content-Type:
application/sdp..User-Agent: Z
oiper rev.416..Content-Length: 380....v=0..o=Zoiper_user 484683138
1181609789 IN IP4 192.168.178.60..s=Zoiper_user..c=IN IP4
192.168.178.60..t=0 0..m=audio 12000
RTP/AVP 3 110 97 8 0 98 101..a=fmtp:97 mode=30..a=fmtp:98
mode=20..a=fmtp:101 0-15..a=rtpmap:3 GSM/8000..a=rtpmap:110
speex/8000..a=rtpmap:97 iLBC/8000..a=rtpm
ap:8 PCMA/8000..a=rtpmap:0 PCMU/8000..a=rtpmap:98
iLBC/8000..a=rtpmap:101 telephone-event/8000..
#
U 88.217.xxx.x:5060 -> 217.24.xxx.xxx:5060
SIP/2.0 407 Proxy Authentication Required..Via: SIP/2.0/UDP
192.168.178.60:5060;branch=z9hG4bK-d8754z-272fe27654f4653a-1---d8754z-;rport=5060;received=217.24.11.
190..To:
<sip:11111@my.openser.de>;tag=92ef15cda537c38acdb588058fd30c38.748e..From:
"6004"<sip:6004@my.openser.de>;transport=UDP;tag=60263e79..Call-ID:
YzZiNmJ
kNTQ2MjI3ZTc5MWQ5Yjk4N2ZkYjg0MDE0MGI...CSeq: 1
INVITE..Proxy-Authenticate: Digest realm="my.openser.de",
nonce="478e68d5f3ba3bdacad52964091fe4a632835b6c"..Serve
r: OpenSER (1.3.0-tls (x86_64/linux))..Content-Length: 0....
#
U 217.24.xxx.xxx:5060 -> 88.217.xxx.x:5060
ACK sip:11111@my.openser.de SIP/2.0..Via: SIP/2.0/UDP
192.168.178.60:5060;branch=z9hG4bK-d8754z-272fe27654f4653a-1---d8754z-;rport..To:
<sip:11111@my.openser.d
e>;tag=92ef15cda537c38acdb588058fd30c38.748e..From:
"6004"<sip:6004@my.openser.de>;transport=UDP;tag=60263e79..Call-ID:
YzZiNmJkNTQ2MjI3ZTc5MWQ5Yjk4N2ZkYjg0MDE0
MGI...CSeq: 1 ACK..Content-Length: 0....
#
U 217.24.xxx.xxx:5060 -> 88.217.xxx.x:5060
INVITE sip:11111@my.openser.de SIP/2.0..Via: SIP/2.0/UDP
192.168.178.60:5060;branch=z9hG4bK-d8754z-83461a97f67a9e27-1---d8754z-;rport..Max-Forwards:
70..Contact
: <sip:6004@192.168.178.60:5060>..To: <sip:11111@my.openser.de>..From:
"6004"<sip:6004@my.openser.de>;transport=UDP;tag=60263e79..Call-ID:
YzZiNmJkNTQ2MjI3ZTc5
MWQ5Yjk4N2ZkYjg0MDE0MGI...CSeq: 2 INVITE..Allow: INVITE, ACK, CANCEL,
OPTIONS, BYE, NOTIFY, REFER, MESSAGE, OPTIONS..Content-Type:
application/sdp..Proxy-Authori
zation: Digest
username="6004",realm="my.openser.de",nonce="478e68d5f3ba3bdacad52964091fe4a632835b6c",uri="sip:11111@my.openser.de",response="536feade179b4eb35
f64e1eed75cf3e8",algorithm=MD5..User-Agent: Zoiper
rev.416..Content-Length: 380....v=0..o=Zoiper_user 484683138 1181609789
IN IP4 192.168.178.60..s=Zoiper_user..
c=IN IP4 192.168.178.60..t=0 0..m=audio 12000 RTP/AVP 3 110 97 8 0 98
101..a=fmtp:97 mode=30..a=fmtp:98 mode=20..a=fmtp:101 0-15..a=rtpmap:3
GSM/8000..a=rtpmap:
110 speex/8000..a=rtpmap:97 iLBC/8000..a=rtpmap:8
PCMA/8000..a=rtpmap:0 PCMU/8000..a=rtpmap:98 iLBC/8000..a=rtpmap:101
telephone-event/8000..
#interface: eth1 (10.10.0.0/255.255.0.0)
filter: (ip) and ( port 5060 )
####
T 10.10.2.24:19034 -> 10.10.2.13:5060 [AP]
INVITE sip:11111@10.10.2.13;transport=tcp SIP/2.0..Record-Route:
<sip:88.217.xxx.x:5060:nat=yes;ftag=60263e79;lr=on>..Via: SIP/2.0/TCP
10.10.2.24;branch=z9hG4bK4
0d3.ce138151.0..Via: SIP/2.0/UDP
192.168.178.60:5060;received=217.24.xxx.xxx;branch=z9hG4bK-d8754z-83461a97f67a9e27-1---d8754z-;rport=5060..Max-Forwards:
69..Cont
act: <sip:6004@217.24.xxx.xxx:5060>..To:
<sip:11111@my.openser.de>..From:
"6004"<sip:6004@my.openser.de>;transport=UDP;tag=60263e79..Call-ID:
YzZiNmJkNTQ2MjI3ZT
c5MWQ5Yjk4N2ZkYjg0MDE0MGI...CSeq: 2 INVITE..Allow: INVITE, ACK,
CANCEL, OPTIONS, BYE, NOTIFY, REFER, MESSAGE, OPTIONS..Content-Type:
application/sdp..User-Agent:
Zoiper rev.416..Content-Length: 380..Remote-Party-ID:
8154712;party=calling;id-type=subscriber;screen=yes....v=0..o=Zoiper_user
484683138 1181609789 IN IP
4 192.168.178.60..s=Zoiper_user..c=IN IP4 192.168.178.60..t=0
0..m=audio 12000 RTP/AVP 3 110 97 8 0 98 101..a=fmtp:97
mode=30..a=fmtp:98 mode=20..a=fmtp:101 0-1
5..a=rtpmap:3 GSM/8000..a=rtpmap:110 speex/8000..a=rtpmap:97
iLBC/8000..a=rtpmap:8 PCMA/8000..a=rtpmap:0 PCMU/8000..a=rtpmap:98
iLBC/8000..a=rtpmap:101 telephone
-event/8000..
#
T 10.10.2.13:5060 -> 10.10.2.24:19034 [AP]
SIP/2.0 100 Trying..FROM:
"6004"<sip:6004@my.openser.de>;tag=60263e79;transport=UDP..TO:
<sip:11111@my.openser.de>..CSEQ: 2 INVITE..CALL-ID: YzZiNmJkNTQ2MjI3ZT
c5MWQ5Yjk4N2ZkYjg0MDE0MGI...MAX-FORWARDS: 70..VIA: SIP/2.0/TCP
10.10.2.24;branch=z9hG4bK40d3.ce138151.0,SIP/2.0/UDP
192.168.178.60:5060;received=217.24.xxx.xxx;br
anch=z9hG4bK-d8754z-83461a97f67a9e27-1---d8754z-;rport=5060..CONTENT-LENGTH:
0....
##
T 10.10.2.13:5060 -> 10.10.2.24:19034 [AP]
SIP/2.0 302 Moved Temporarily..FROM:
"6004"<sip:6004@my.openser.de>;tag=60263e79;transport=UDP..TO:
<sip:11111@my.openser.de>;tag=1013625314..CSEQ: 2 INVITE..C
ALL-ID: YzZiNmJkNTQ2MjI3ZTc5MWQ5Yjk4N2ZkYjg0MDE0MGI...MAX-FORWARDS:
70..VIA: SIP/2.0/TCP
10.10.2.24;branch=z9hG4bK40d3.ce138151.0,SIP/2.0/UDP 192.168.178.60:5060
;received=217.24.xxx.xxx;branch=z9hG4bK-d8754z-83461a97f67a9e27-1---d8754z-;rport=5060..CONTENT-LENGTH:
0..SERVER: RTCC/2.0.6017.0..CONTACT: <sip:11111@10.10.2.13
:5065;transport=tcp>....
##
U 88.217.xxx.x:5060 -> 217.24.xxx.xxx:5060
SIP/2.0 100 Giving a try..Via: SIP/2.0/UDP
192.168.178.60:5060;branch=z9hG4bK-d8754z-83461a97f67a9e27-1---d8754z-;rport=5060;received=217.24.xxx.xxx..To:
<sip:111
11@my.openser.de>..From:
"6004"<sip:6004@my.openser.de>;transport=UDP;tag=60263e79..Call-ID:
YzZiNmJkNTQ2MjI3ZTc5MWQ5Yjk4N2ZkYjg0MDE0MGI...CSeq: 2 INVITE..Serv
er: OpenSER (1.3.0-tls (x86_64/linux))..Content-Length: 0....
#
U 88.217.xxx.x:5060 -> 217.24.xxx.xxx:5060
SIP/2.0 500 Internal Server Error..FROM:
"6004"<sip:6004@my.openser.de>;tag=60263e79;transport=UDP..TO:
<sip:11111@my.openser.de>;tag=78445986d6..CSEQ: 2 INVIT
E..CALL-ID:
YzZiNmJkNTQ2MjI3ZTc5MWQ5Yjk4N2ZkYjg0MDE0MGI...MAX-FORWARDS: 70..VIA:
SIP/2.0/UDP
192.168.178.60:5060;received=217.24.xxx.xxx;branch=z9hG4bK-d8754z-834
61a97f67a9e27-1---d8754z-;rport=5060..CONTENT-LENGTH: 0..SERVER:
RTCC/2.0.6017.0....
#
T 10.10.2.24:19034 -> 10.10.2.13:5060 [AP]
ACK sip:11111@10.10.2.13;transport=tcp SIP/2.0..Via: SIP/2.0/TCP
10.10.2.24;branch=z9hG4bK40d3.ce138151.0..From:
"6004"<sip:6004@my.openser.de>;transport=UDP;ta
g=60263e79..Call-ID: YzZiNmJkNTQ2MjI3ZTc5MWQ5Yjk4N2ZkYjg0MDE0MGI...TO:
<sip:11111@my.openser.de>;tag=1013625314..CSeq: 2 ACK..Max-Forwards:
70..User-Agent: Open
SER (1.3.0-tls (x86_64/linux))..Content-Length: 0....
#
U 217.24.xxx.xxx:5060 -> 88.217.xxx.x:5060
ACK sip:11111@my.openser.de SIP/2.0..Via: SIP/2.0/UDP
192.168.178.60:5060;branch=z9hG4bK-d8754z-83461a97f67a9e27-1---d8754z-;rport..To:
<sip:11111@my.openser.d
e>;tag=78445986d6..From:
"6004"<sip:6004@my.openser.de>;transport=UDP;tag=60263e79..Call-ID:
YzZiNmJkNTQ2MjI3ZTc5MWQ5Yjk4N2ZkYjg0MDE0MGI...CSeq: 2 ACK..Content-
Length: 0....
Iñaki Baz Castillo schrieb:
On Thursday 17 January 2008 10:11:48 Peter P GMX
wrote:
As UM requests a different port (5065) in the 302
message, I cannot use
t_relay with TCP in the failure_route. With t_relay I have to submit the
whole address like
t_relay(tcp: dest_ip:port) and I cannot always predict the port in this
case.
Could you show the received 302 from UM?
I understand that it's something as:
SIP/2.0 302 Redirection
...
Contact: <sip:other_user@10.10.2.13:5065>;transport=TCP
Is it?
And you say that sometime the "Contact" port is 5065 and sometimes 5060? or
there are more possible values?
In case they are a fixed number of values you can do a very dirty trick:
if ( $(ct{uri.port}) == "5065" )
t_relay("tcp:10.10.2.13:5065"
else if ( $(ct{uri.port}) == "5060" )
t_relay("tcp:10.10.2.13:5060"
18 Jan
18 Jan
12:36 p.m.
New subject: [OpenSER-Users] Openser 1.3 How to rewrite transport protocol from udp to tcp after redirect
On Thursday 17 January 2008 18:46:17 Peter P GMX wrote:
the 302 message is as follows
=====================
In this case it answers per UPD as I explained before when OpenSER
T 10.10.2.13:5060 -> 10.10.2.24:27838 [AP]
SIP/2.0 302 Moved Temporarily
FROM: "6005"<sip:6005@my.openser.de>;tag=4b086b07;transport=UDP
TO: <sip:11111@my.openser.de>;transport=UDP;tag=9cca2fa224
CSEQ: 2 INVITE
CALL-ID: NjQxNjk3ZDczZDkzN2ZmMzI5MzdiNzhkMzdmZTg0YzM
MAX-FORWARDS: 70
VIA: SIP/2.0/TCP 10.10.2.24;branch=z9hG4bK3e88.e9631885.0,SIP/2.0/UDP
10.5.3.22:5060;received=82.135.xx.xxx;branch=z9hG4bK-d8754z-be756d81d31da41
9-1---d8754z-;rport=5060 CONTENT-LENGTH: 0..
SERVER: RTCC/2.0.6017.0..CONTACT:
<sip:11111@10.10.2.13:5065;transport=UDP>
Hi, you say:
"In this case it answers per UPD as I explained before when OpenSER"
but it's not true, it's TCP, note the "T":
T 10.10.2.13:5060 -> 10.10.2.24:27838 [AP]
BTW, could you please capture the trace using ngrep with this syntax?:
~# ngrep -d any -P ' ' -W byline -T -t "" port 5060 or port 5065 or
port...
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
17 Jan
17 Jan
10:30 a.m.
New subject: [OpenSER-Users] Openser 1.3 How to rewrite transport protocol from udp to tcp after redirect
On Wednesday 16 January 2008 23:25:37 Peter P GMX wrote:
In Step 5 OpenSER invites
"sip:11111@10.10.2.13;transport=UDP>" with TCP
protocol (checked with ngrep) and UM2007 answers.
Does the parameter "transport=UDP" exist in the original INVITE from SIP UA?
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
6:17 p.m.
Yes it does. Any way to suppress it, before I set it to tcp?
Iñaki Baz Castillo schrieb:
On Wednesday 16 January 2008 23:25:37 Peter P GMX
wrote:
In Step 5 OpenSER invites
"sip:11111@10.10.2.13;transport=UDP>" with TCP
protocol (checked with ngrep) and UM2007 answers.
Does the parameter "transport=UDP" exist in the original INVITE from SIP UA?
6:28 p.m.
New subject: [OpenSER-Users] Openser 1.3 How to rewrite transport protocol from udp to tcp after redirect
On Thursday 17 January 2008 18:17:39 Peter P GMX wrote:
Yes it does. Any way to suppress it, before I set it
to tcp?
Is really needed "transport=XXX" parameter in the RURI ??? what for?
If the proxy must contact a UAS yb TCP then it will use TCP as transport
layer, but AFAIK is not necessary at all to indicate it in the RURI.
In fact, note that the INVITE from the proxy to UM server arrives by TCP
with "transport=UDP" in the RURI and the INVITE is accepted !
Or maybe I'm wrong? Regards.
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
7:40 p.m.
UM2007 gives back the transport parameter which it receives.
If I add transport=tcp then the next 302 message answers with contact:
...... transport=tcp, so OpenSER can Reinvite on TCP.
If I add transport=udp then the next 302 message answers with contact:
...... transport=udp, so OpenSER will Reinvite via UDP and UM will not
accept it.
Unfortunately UM2007 only accepts TCP so OpenSER has to mediate between
tcp and udp (UA).
Best regards
Peter
Iñaki Baz Castillo schrieb:
On Thursday 17 January 2008 18:17:39 Peter P GMX
wrote:
Yes it does. Any way to suppress it, before I set
it to tcp?
Is really needed "transport=XXX" parameter in the RURI ??? what for?
If the proxy must contact a UAS yb TCP then it will use TCP as transport
layer, but AFAIK is not necessary at all to indicate it in the RURI.
In fact, note that the INVITE from the proxy to UM server arrives by TCP
with "transport=UDP" in the RURI and the INVITE is accepted !
Or maybe I'm wrong? Regards.
24 Jan
24 Jan
4:26 p.m.
Hey Peter,
I tried getting this going a while ago and wound up reconfiguring UM to stop
doing the redirect with this command: Set-UMDialPlan -Identity "My DialPlan"
-VOIPSecurity:unsecured
In Unsecured mode there are no redirects... I still had trouble getting the
UDP <-> TCP gateway working as desired so I hope you post your config after
its working!
Peter P GMX wrote:
UM2007 gives back the transport parameter which it receives.
If I add transport=tcp then the next 302 message answers with contact:
...... transport=tcp, so OpenSER can Reinvite on TCP.
If I add transport=udp then the next 302 message answers with contact:
...... transport=udp, so OpenSER will Reinvite via UDP and UM will not
accept it.
Unfortunately UM2007 only accepts TCP so OpenSER has to mediate between
tcp and udp (UA).
Best regards
Peter
Iñaki Baz Castillo schrieb:
--
View this message in context:
http://www.nabble.com/Openser-1.3-How-to-rewrite-transport-protocol-from-ud…
Sent from the OpenSER Users Mailing List mailing list archive at Nabble.com.
On Thursday 17 January 2008 18:17:39 Peter P GMX
wrote:
_______________________________________________
Users mailing list
Users(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users
Yes it does. Any way to suppress it, before I set
it to tcp?
Is really needed "transport=XXX" parameter in the RURI ??? what for?
If the proxy must contact a UAS yb TCP then it will use TCP as transport
layer, but AFAIK is not necessary at all to indicate it in the RURI.
In fact, note that the INVITE from the proxy to UM server arrives by TCP
with "transport=UDP" in the RURI and the INVITE is accepted !
Or maybe I'm wrong? Regards.
5951
days inactive
5959
days old
10 comments
4 participants
participants (4)
-
Iñaki Baz Castillo -
Iñaki Baz Castillo -
Jon Webster -
Peter P GMX