25 Apr
2007
25 Apr
'07
4:35 p.m.
Hi,
I am using SER rel 2_0_0 from CVS.
I encountered the following situation.
My scenario was the following:
UA -> Application Serwer -> SER -> UA
1. UA sent an INVITE message to the application server.
2. Application Server changed the Request URI and forwarded statelessly the INVITE message
to SER.
3. Everything would be ok but SER replied to the Application server instead of the client.
Application server changed only the Request URI and nothing else.
Shouldn't SER sent the response according to the VIA header value??
I kindly ask for Your help.
Below is the ngrep:
192.168.0.112:5060 - this is application server
192.168.0.112:5061 - this is calling UA
U 2007/04/25 16:17:05.652934 192.168.0.112:5060 -> 192.168.0.165:5060
INVITE sip:sen@voip.rd.touk.pl SIP/2.0.
Via: SIP/2.0/UDP 192.168.0.112:5061;rport=5061;branch=z9hG4bKhnrxbtgp;received=127.0.0.1.
Max-Forwards: 70.
To: <sip:sen@voip.rd.touk.pl>.
From: <sip:pz@voip.rd.touk.pl>;tag=jlegd.
Call-ID: pfnqwekjwtuxbfv(a)192.168.0.112.
CSeq: 87 INVITE.
Contact: <sip:pz@192.168.0.112:5061>.
Content-Type: application/sdp.
Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,PRACK,REFER,NOTIFY,SUBSCRIBE,INFO.
Supported: 100rel.
User-Agent: Twinkle/0.9.
Content-Length: 304.
.
v=0.
o=pz 86411392 1733597180 IN IP4 192.168.0.112.
s=-.
c=IN IP4 192.168.0.112.
t=0 0.
m=audio 8000 RTP/AVP 98 97 8 0 3 101.
a=rtpmap:98 speex/16000.
a=rtpmap:97 speex/8000.
a=rtpmap:8 PCMA/8000.
a=rtpmap:0 PCMU/8000.
a=rtpmap:3 GSM/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.
a=ptime:20.
#
U 2007/04/25 16:17:05.699923 192.168.0.165:5060 -> 192.168.0.112:5060
SIP/2.0 407 Proxy Authentication Required.
Via: SIP/2.0/UDP
192.168.0.112:5061;rport=5060;branch=z9hG4bKhnrxbtgp;received=127.0.0.1;received=192.168.0.112.
To: <sip:sen@voip.rd.touk.pl>;tag=b27e1a1d33761e85846fc98f5f3a7e58.6a45.
From: <sip:pz@voip.rd.touk.pl>;tag=jlegd.
Call-ID: pfnqwekjwtuxbfv(a)192.168.0.112.
CSeq: 87 INVITE.
Proxy-Authenticate: Digest realm="voip.rd.touk.pl",
nonce="462f640d527dfc442d53379e1f0167c8a12a583d", qop="auth".
Server: Sip EXpress router (2.0.0-rc1 (x86_64/linux)).
Content-Length: 0.
Warning: 392 192.168.0.165:5060 "Noisy feedback tells: pid=20441
req_src_ip=192.168.0.112 req_src_port=5060 in_uri=sip:sen@voip.rd.touk.pl
out_uri=sip:sen@voip.rd.touk.pl via_cnt==1".
.
Cheers Tomasz
27 Apr
27 Apr
8:55 a.m.
Replies take the same path as requests, no matter what kind of proxy there
were on the way.
SER replies to the address it detected in the transport layer (UDP/IP) of
the request; the Via in your request will be used by the application server
to send the reply back to the UA and not by SER; SER doesn't even look at
that Via.
WL.
On 4/25/07, tzieleniewski <tzieleniewski(a)o2.pl> wrote:
Hi,
I am using SER rel 2_0_0 from CVS.
I encountered the following situation.
My scenario was the following:
UA -> Application Serwer -> SER -> UA
1. UA sent an INVITE message to the application server.
2. Application Server changed the Request URI and forwarded statelessly
the INVITE message to SER.
3. Everything would be ok but SER replied to the Application server
instead of the client. Application server changed only the Request URI and
nothing else.
Shouldn't SER sent the response according to the VIA header value??
I kindly ask for Your help.
Below is the ngrep:
192.168.0.112:5060 - this is application server
192.168.0.112:5061 - this is calling UA
U 2007/04/25 16:17:05.652934 192.168.0.112:5060 -> 192.168.0.165:5060
INVITE sip:sen@voip.rd.touk.pl SIP/2.0.
Via: SIP/2.0/UDP 192.168.0.112:5061
;rport=5061;branch=z9hG4bKhnrxbtgp;received=127.0.0.1.
Max-Forwards: 70.
To: <sip:sen@voip.rd.touk.pl>.
From: <sip:pz@voip.rd.touk.pl>;tag=jlegd.
Call-ID: pfnqwekjwtuxbfv(a)192.168.0.112.
CSeq: 87 INVITE.
Contact: <sip:pz@192.168.0.112:5061>.
Content-Type: application/sdp.
Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,PRACK,REFER,NOTIFY,SUBSCRIBE,INFO.
Supported: 100rel.
User-Agent: Twinkle/0.9.
Content-Length: 304.
.
v=0.
o=pz 86411392 1733597180 IN IP4 192.168.0.112.
s=-.
c=IN IP4 192.168.0.112.
t=0 0.
m=audio 8000 RTP/AVP 98 97 8 0 3 101.
a=rtpmap:98 speex/16000.
a=rtpmap:97 speex/8000.
a=rtpmap:8 PCMA/8000.
a=rtpmap:0 PCMU/8000.
a=rtpmap:3 GSM/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.
a=ptime:20.
#
U 2007/04/25 16:17:05.699923 192.168.0.165:5060 -> 192.168.0.112:5060
SIP/2.0 407 Proxy Authentication Required.
Via: SIP/2.0/UDP 192.168.0.112:5061
;rport=5060;branch=z9hG4bKhnrxbtgp;received=127.0.0.1;received=
192.168.0.112.
To: <sip:sen@voip.rd.touk.pl>;tag=b27e1a1d33761e85846fc98f5f3a7e58.6a45.
From: <sip:pz@voip.rd.touk.pl>;tag=jlegd.
Call-ID: pfnqwekjwtuxbfv(a)192.168.0.112.
CSeq: 87 INVITE.
Proxy-Authenticate: Digest realm="voip.rd.touk.pl",
nonce="462f640d527dfc442d53379e1f0167c8a12a583d", qop="auth".
Server: Sip EXpress router (2.0.0-rc1 (x86_64/linux)).
Content-Length: 0.
Warning: 392 192.168.0.165:5060 "Noisy feedback tells: pid=20441
req_src_ip=192.168.0.112 req_src_port=5060 in_uri=sip:sen@voip.rd.touk.plout_uri=
sip:sen@voip.rd.touk.pl via_cnt==1".
.
Cheers Tomasz
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
--
"C is a language that combines all the elegance and power of assembly
language with all the readability and maintainability of assembly language."
10:16 a.m.
New subject: [Serusers] Ser2.0 wrong behaviour of the sl_reply() function?
At 16:35 25/04/2007, tzieleniewski wrote:
Hi,
I am using SER rel 2_0_0 from CVS.
I encountered the following situation.
My scenario was the following:
UA -> Application Serwer -> SER -> UA
1. UA sent an INVITE message to the application server.
2. Application Server changed the Request URI and forwarded statelessly the INVITE message
to SER.
3. Everything would be ok but SER replied to the Application server instead of the client.
It can be that you meant to say something different, but that's standard
SIP behqviour that you send a reply to the most immediate upstream
entity (AS in this case).
Application server changed only the Request URI and
nothing else.
Shouldn't SER sent the response according to the VIA header value??
You mean to say that the AS didn't add its own Via in there?
That appear kind of odd to me, I would begin fixing there.
But if you think there is possibly some
value in it, there is I believe an option in SER to send back literally
to what is printed in Via (as opposed to reversely sending to previous
hop's transport address). It is normally turned off, becasue Via content
is frequently useless (e.g., due to presence of NATs).
Badly enough I don't recall the options' name and I'm offline right now
to dig it out for you :-(
-jiri
I kindly ask for Your help.
Below is the ngrep:
192.168.0.112:5060 - this is application server
192.168.0.112:5061 - this is calling UA
U 2007/04/25 16:17:05.652934 192.168.0.112:5060 -> 192.168.0.165:5060
INVITE sip:sen@voip.rd.touk.pl SIP/2.0.
Via: SIP/2.0/UDP 192.168.0.112:5061;rport=5061;branch=z9hG4bKhnrxbtgp;received=127.0.0.1.
Max-Forwards: 70.
To: <sip:sen@voip.rd.touk.pl>.
From: <sip:pz@voip.rd.touk.pl>;tag=jlegd.
Call-ID: pfnqwekjwtuxbfv(a)192.168.0.112.
CSeq: 87 INVITE.
Contact: <sip:pz@192.168.0.112:5061>.
Content-Type: application/sdp.
Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,PRACK,REFER,NOTIFY,SUBSCRIBE,INFO.
Supported: 100rel.
User-Agent: Twinkle/0.9.
Content-Length: 304.
.
v=0.
o=pz 86411392 1733597180 IN IP4 192.168.0.112.
s=-.
c=IN IP4 192.168.0.112.
t=0 0.
m=audio 8000 RTP/AVP 98 97 8 0 3 101.
a=rtpmap:98 speex/16000.
a=rtpmap:97 speex/8000.
a=rtpmap:8 PCMA/8000.
a=rtpmap:0 PCMU/8000.
a=rtpmap:3 GSM/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.
a=ptime:20.
#
U 2007/04/25 16:17:05.699923 192.168.0.165:5060 -> 192.168.0.112:5060
SIP/2.0 407 Proxy Authentication Required.
Via: SIP/2.0/UDP
192.168.0.112:5061;rport=5060;branch=z9hG4bKhnrxbtgp;received=127.0.0.1;received=192.168.0.112.
To: <sip:sen@voip.rd.touk.pl>;tag=b27e1a1d33761e85846fc98f5f3a7e58.6a45.
From: <sip:pz@voip.rd.touk.pl>;tag=jlegd.
Call-ID: pfnqwekjwtuxbfv(a)192.168.0.112.
CSeq: 87 INVITE.
Proxy-Authenticate: Digest realm="voip.rd.touk.pl",
nonce="462f640d527dfc442d53379e1f0167c8a12a583d", qop="auth".
Server: Sip EXpress router (2.0.0-rc1 (x86_64/linux)).
Content-Length: 0.
Warning: 392 192.168.0.165:5060 "Noisy feedback tells: pid=20441
req_src_ip=192.168.0.112 req_src_port=5060 in_uri=sip:sen@voip.rd.touk.pl
out_uri=sip:sen@voip.rd.touk.pl via_cnt==1".
.
Cheers Tomasz
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
--
Jiri Kuthan http://iptel.org/~jiri/
30 Apr
30 Apr
11:48 a.m.
New subject: [Serusers] Ser2.0 wrong behaviour of the sl_reply() function?
At 16:35 25/04/2007, tzieleniewski wrote:
Yes, the aim was to apply some external to SER modifications on the SIP massage
and then return it back to SER. It was suppose to be something like invocation of some
external logic outside the SIP routing procedures.
Hi,
I am using SER rel 2_0_0 from CVS.
I encountered the following situation.
My scenario was the following:
UA -> Application Serwer -> SER -> UA
1. UA sent an INVITE message to the application server.
2. Application Server changed the Request URI and forwarded statelessly the INVITE message
to SER.
3. Everything would be ok but SER replied to the Application server instead of the client.
It can be that you meant to say something different, but that's standard
SIP behqviour that you send a reply to the most immediate upstream
entity (AS in this case).
Application server changed only the Request URI
and nothing else.
Shouldn't SER sent the response according to the VIA header value??
You mean to say that the AS didn't add its own Via in there?
That appear kind of odd to me, I would begin fixing
there.
But if you think there is possibly some
value in it, there is I believe an option in SER to send back literally
to what is printed in Via (as opposed to reversely sending to previous
hop's transport address). It is normally turned off, becasue Via content
is frequently useless (e.g., due to presence of NATs).
Would be thanks full if you did:)
tomasz
Badly enough I don't recall the options' name
and I'm offline right now
to dig it out for you :-(
-jiri
I kindly ask for Your help.
Below is the ngrep:
192.168.0.112:5060 - this is application server
192.168.0.112:5061 - this is calling UA
U 2007/04/25 16:17:05.652934 192.168.0.112:5060 -> 192.168.0.165:5060
INVITE sip:sen@voip.rd.touk.pl SIP/2.0.
Via: SIP/2.0/UDP 192.168.0.112:5061;rport=5061;branch=z9hG4bKhnrxbtgp;received=127.0.0.1.
Max-Forwards: 70.
To: <sip:sen@voip.rd.touk.pl>.
From: <sip:pz@voip.rd.touk.pl>;tag=jlegd.
Call-ID: pfnqwekjwtuxbfv(a)192.168.0.112.
CSeq: 87 INVITE.
Contact: <sip:pz@192.168.0.112:5061>.
Content-Type: application/sdp.
Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,PRACK,REFER,NOTIFY,SUBSCRIBE,INFO.
Supported: 100rel.
User-Agent: Twinkle/0.9.
Content-Length: 304.
.
v=0.
o=pz 86411392 1733597180 IN IP4 192.168.0.112.
s=-.
c=IN IP4 192.168.0.112.
t=0 0.
m=audio 8000 RTP/AVP 98 97 8 0 3 101.
a=rtpmap:98 speex/16000.
a=rtpmap:97 speex/8000.
a=rtpmap:8 PCMA/8000.
a=rtpmap:0 PCMU/8000.
a=rtpmap:3 GSM/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.
a=ptime:20.
#
U 2007/04/25 16:17:05.699923 192.168.0.165:5060 -> 192.168.0.112:5060
SIP/2.0 407 Proxy Authentication Required.
Via: SIP/2.0/UDP
192.168.0.112:5061;rport=5060;branch=z9hG4bKhnrxbtgp;received=127.0.0.1;received=192.168.0.112.
To: <sip:sen@voip.rd.touk.pl>;tag=b27e1a1d33761e85846fc98f5f3a7e58.6a45.
From: <sip:pz@voip.rd.touk.pl>;tag=jlegd.
Call-ID: pfnqwekjwtuxbfv(a)192.168.0.112.
CSeq: 87 INVITE.
Proxy-Authenticate: Digest realm="voip.rd.touk.pl",
nonce="462f640d527dfc442d53379e1f0167c8a12a583d", qop="auth".
Server: Sip EXpress router (2.0.0-rc1 (x86_64/linux)).
Content-Length: 0.
Warning: 392 192.168.0.165:5060 "Noisy feedback tells: pid=20441
req_src_ip=192.168.0.112 req_src_port=5060 in_uri=sip:sen@voip.rd.touk.pl
out_uri=sip:sen@voip.rd.touk.pl via_cnt==1".
.
Cheers Tomasz
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
--
Jiri Kuthan http://iptel.org/~jiri/
11:53 a.m.
New subject: [Serusers] Ser2.0 wrong behaviour of the sl_reply () function?
At 11:48 30/04/2007, tzieleniewski wrote:
I would say it is a bit slippery slope to do this ...
... but if you really want to try, set reply_to_via=1.
-jiri
--
Jiri Kuthan http://iptel.org/~jiri/
At 16:35
25/04/2007, tzieleniewski wrote:
Yes, the aim was to apply some external to SER modifications on the SIP massage
and then return it back to SER. It was suppose to be something like invocation of some
external logic outside the SIP routing procedures. Hi,
I am using SER rel 2_0_0 from CVS.
I encountered the following situation.
My scenario was the following:
UA -> Application Serwer -> SER -> UA
1. UA sent an INVITE message to the application server.
2. Application Server changed the Request URI and forwarded statelessly the INVITE message
to SER.
3. Everything would be ok but SER replied to the Application server instead of the client.
It can be that you meant to say something different, but that's standard
SIP behqviour that you send a reply to the most immediate upstream
entity (AS in this case).
Application server changed only the Request URI
and nothing else.
Shouldn't SER sent the response according to the VIA header value??
You mean to say that the AS didn't add its own Via in there?
That appear
kind of odd to me, I would begin fixing there.
But if you think there is possibly some
value in it, there is I believe an option in SER to send back literally
to what is printed in Via (as opposed to reversely sending to previous
hop's transport address). It is normally turned off, becasue Via content
is frequently useless (e.g., due to presence of NATs).
Would be thanks full if you did:) 
12:49 p.m.
New subject: [Serusers] Ser2.0 wrong behaviour of the sl_reply () function?
That appear kind of odd to me, I would begin fixing
there.
But if you think there is possibly some
value in it, there is I believe an option in SER to send back literally
to what is printed in Via (as opposed to reversely sending to previous
hop's transport address). It is normally turned off, becasue Via content
is frequently useless (e.g., due to presence of NATs).
Would be thanks full if you did:)
6215
days inactive
6220
days old
5 comments
4 participants
participants (4)
-
Jiri Kuthan -
Michal Matyska -
tzieleniewski -
Weiter Leiter