25 Jun
2008
25 Jun
'08
4:43 p.m.
Hello,
I'm testing with OpenSER 1.3.x revision 4393 with RTPProxy.
I'm trying to make a call from a Nokia E51 to a SIPp instance started with:
sipp -sn uas -p 6060 -mp 4000
The INVITE goes thru OpenSER to SIPp and then, SIPp replies with this:
SIPp to OpenSER:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 210.126.5.158;branch=z9hG4bK9c1e.f06224f3.0, SIP/2.0/UDP
192.168.0.4:5060;received=123.224.149.169
;branch=z9hG4bK5j85u8aa6jpebhelr55b8bj;rport=64351
From: <sip:1000@210.126.5.158 <sip%3A1000(a)210.126.5.158>
;tag=r5hbkuj8mlhc6o184cms
To:
<sip:22222222@210.126.5.158 <sip%3A22222222(a)210.126.5.158>
;user=phone>;tag=28909SIPpTag013
Call-ID: nLPxHi_hoIf-POcJ7OKojntw2wgQle
CSeq: 7342 INVITE
Contact: <sip:192.168.88.16:6060;transport=UDP>
Content-Type: application/sdp
Content-Length: 135
v=0
o=user1 53655765 2353687637 IN IP4 192.168.88.16
s=-
c=IN IP4 192.168.88.16
t=0 0
m=audio 4000 RTP/AVP 0
a=rtpmap:0 PCMU/8000
But when OpenSER relays this to E51, I can see it is adding
"a=nortpproxy:yes" immediatelly after the the last characters in the SDP
instead of prepending a CRLF.
OpenSER to Caller
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.0.4:5060;received=123.224.149.169
;branch=z9hG4bK5j85u8aa6jpebhelr55b8bj;rport=64351
From: <sip:1000@210.126.5.158 <sip%3A1000(a)210.126.5.158>
;tag=r5hbkuj8mlhc6o184cms
To:
<sip:22222222@210.126.5.158 <sip%3A22222222(a)210.126.5.158>
;user=phone>;tag=28909SIPpTag013
Call-ID: nLPxHi_hoIf-POcJ7OKojntw2wgQle
CSeq: 7342 INVITE
Contact: <sip:210.126.5.158:6060;transport=UDP;nat=yes>
Content-Type: application/sdp
Content-Length: 154
v=0
o=user1 53655765 2353687637 IN IP4 192.168.88.16
s=-
c=IN IP4 210.126.5.158
t=0 0
m=audio 36740 RTP/AVP 0
a=rtpmap:0 PCMU/8000a=nortpproxy:yes
Because of this, E51 ignores the message and doesn't send ACK.
I believe this is a bug in OpenSER.
Thanks,
Takeshi
25 Jun
25 Jun
5 p.m.
I suspect that the SDP does not contain CRLF at the end of the last line.
If this is the case, the SDP is not correct:
From RFC 4566:
Text fields such as the session name and information are octet
strings that may contain any octet with the exceptions of 0x00 (Nul),
0x0a (ASCII newline), and 0x0d (ASCII carriage return). The sequence
CRLF (0x0d0a) is used to end a record, although parsers SHOULD be
tolerant and also accept records terminated with a single newline
character.
Nevertheless openser should be tolerant and add the CRLF itself.
regards
klaus
mayamatakeshi schrieb:
Hello,
I'm testing with OpenSER 1.3.x revision 4393 with RTPProxy.
I'm trying to make a call from a Nokia E51 to a SIPp instance started with:
sipp -sn uas -p 6060 -mp 4000
The INVITE goes thru OpenSER to SIPp and then, SIPp replies with this:
SIPp to OpenSER:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 210.126.5.158
<http://210.126.5.158>;branch=z9hG4bK9c1e.f06224f3.0, SIP/2.0/UDP
192.168.0.4:5060;received=123.224.149.169
<http://123.224.149.169>;branch=z9hG4bK5j85u8aa6jpebhelr55b8bj;rport=64351
From: <sip:1000@210.126.5.158
<mailto:sip%3A1000@210.126.5.158>>;tag=r5hbkuj8mlhc6o184cms
To: <sip:22222222@210.126.5.158
<mailto:sip%3A22222222@210.126.5.158>;user=phone>;tag=28909SIPpTag013
Call-ID: nLPxHi_hoIf-POcJ7OKojntw2wgQle
CSeq: 7342 INVITE
Contact: <sip:192.168.88.16:6060;transport=UDP>
Content-Type: application/sdp
Content-Length: 135
v=0
o=user1 53655765 2353687637 IN IP4 192.168.88.16 <http://192.168.88.16>
s=-
c=IN IP4 192.168.88.16 <http://192.168.88.16>
t=0 0
m=audio 4000 RTP/AVP 0
a=rtpmap:0 PCMU/8000
But when OpenSER relays this to E51, I can see it is adding
"a=nortpproxy:yes" immediatelly after the the last characters in the SDP
instead of prepending a CRLF.
OpenSER to Caller
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.0.4:5060;received=123.224.149.169
<http://123.224.149.169>;branch=z9hG4bK5j85u8aa6jpebhelr55b8bj;rport=64351
From: <sip:1000@210.126.5.158
<mailto:sip%3A1000@210.126.5.158>>;tag=r5hbkuj8mlhc6o184cms
To: <sip:22222222@210.126.5.158
<mailto:sip%3A22222222@210.126.5.158>;user=phone>;tag=28909SIPpTag013
Call-ID: nLPxHi_hoIf-POcJ7OKojntw2wgQle
CSeq: 7342 INVITE
Contact: <sip:210.126.5.158:6060;transport=UDP;nat=yes>
Content-Type: application/sdp
Content-Length: 154
v=0
o=user1 53655765 2353687637 IN IP4 192.168.88.16 <http://192.168.88.16>
s=-
c=IN IP4 210.126.5.158 <http://210.126.5.158>
t=0 0
m=audio 36740 RTP/AVP 0
a=rtpmap:0 PCMU/8000a=nortpproxy:yes
Because of this, E51 ignores the message and doesn't send ACK.
I believe this is a bug in OpenSER.
Thanks,
Takeshi
------------------------------------------------------------------------
_______________________________________________
Users mailing list
Users(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users
5:20 p.m.
so it should be as simple as making SURE there is a \r\n at the end
On Wed, Jun 25, 2008 at 5:00 PM, Klaus Darilion <
klaus.mailinglists(a)pernau.at> wrote:
I suspect that the SDP does not contain CRLF at the
end of the last line.
If this is the case, the SDP is not correct:
From RFC 4566:
Text fields such as the session name and information are octet
strings that may contain any octet with the exceptions of 0x00 (Nul),
0x0a (ASCII newline), and 0x0d (ASCII carriage return). The sequence
CRLF (0x0d0a) is used to end a record, although parsers SHOULD be
tolerant and also accept records terminated with a single newline
character.
Nevertheless openser should be tolerant and add the CRLF itself.
regards
klaus
mayamatakeshi schrieb:
Hello,
I'm testing with OpenSER 1.3.x revision 4393 with RTPProxy.
I'm trying to make a call from a Nokia E51 to a SIPp instance started
with:
sipp -sn uas -p 6060 -mp 4000
The INVITE goes thru OpenSER to SIPp and then, SIPp replies with this:
SIPp to OpenSER:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 210.126.5.158
<http://210.126.5.158>;branch=z9hG4bK9c1e.f06224f3.0, SIP/2.0/UDP
192.168.0.4:5060;received=123.224.149.169
<http://123.224.149.169
;branch=z9hG4bK5j85u8aa6jpebhelr55b8bj;rport=64351
From: <sip:1000@210.126.5.158 <sip%3A1000(a)210.126.5.158>
<mailto:sip%3A1000@210.126.5.158 <sip%253A1000(a)210.126.5.158>
_______________________________________________
Users mailing list
Users(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users
;tag=r5hbkuj8mlhc6o184cms
To:
<sip:22222222@210.126.5.158 <sip%3A22222222(a)210.126.5.158>
<mailto:sip%3A22222222@210.126.5.158 <sip%253A22222222(a)210.126.5.158>
;user=phone>;tag=28909SIPpTag013
Call-ID: nLPxHi_hoIf-POcJ7OKojntw2wgQle
CSeq: 7342 INVITE
Contact: <sip:192.168.88.16:6060;transport=UDP>
Content-Type: application/sdp
Content-Length: 135
v=0
o=user1 53655765 2353687637 IN IP4 192.168.88.16 <http://192.168.88.16>
s=-
c=IN IP4 192.168.88.16 <http://192.168.88.16>
t=0 0
m=audio 4000 RTP/AVP 0
a=rtpmap:0 PCMU/8000
But when OpenSER relays this to E51, I can see it is adding
"a=nortpproxy:yes" immediatelly after the the last characters in the SDP
instead of prepending a CRLF.
OpenSER to Caller
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.0.4:5060;received=123.224.149.169
<http://123.224.149.169
;branch=z9hG4bK5j85u8aa6jpebhelr55b8bj;rport=64351
From: <sip:1000@210.126.5.158 <sip%3A1000(a)210.126.5.158>
<mailto:sip%3A1000@210.126.5.158 <sip%253A1000(a)210.126.5.158>
;tag=r5hbkuj8mlhc6o184cms
To:
<sip:22222222@210.126.5.158 <sip%3A22222222(a)210.126.5.158>
<mailto:sip%3A22222222@210.126.5.158 <sip%253A22222222(a)210.126.5.158>
;user=phone>;tag=28909SIPpTag013
Call-ID: nLPxHi_hoIf-POcJ7OKojntw2wgQle
CSeq: 7342 INVITE
Contact: <sip:210.126.5.158:6060;transport=UDP;nat=yes>
Content-Type: application/sdp
Content-Length: 154
v=0
o=user1 53655765 2353687637 IN IP4 192.168.88.16 <http://192.168.88.16>
s=-
c=IN IP4 210.126.5.158 <http://210.126.5.158>
t=0 0
m=audio 36740 RTP/AVP 0
a=rtpmap:0 PCMU/8000a=nortpproxy:yes
Because of this, E51 ignores the message and doesn't send ACK.
I believe this is a bug in OpenSER.
Thanks,
Takeshi
------------------------------------------------------------------------
_______________________________________________
Users mailing list
Users(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users
5:25 p.m.
You are right.
SIPp fails to add CRLF.
Thank you.
Regards,
Takeshi.
On Thu, Jun 26, 2008 at 12:00 AM, Klaus Darilion <
klaus.mailinglists(a)pernau.at> wrote:
I suspect that the SDP does not contain CRLF at the
end of the last line.
If this is the case, the SDP is not correct:
From RFC 4566:
Text fields such as the session name and information are octet
strings that may contain any octet with the exceptions of 0x00 (Nul),
0x0a (ASCII newline), and 0x0d (ASCII carriage return). The sequence
CRLF (0x0d0a) is used to end a record, although parsers SHOULD be
tolerant and also accept records terminated with a single newline
character.
Nevertheless openser should be tolerant and add the CRLF itself.
regards
klaus
mayamatakeshi schrieb:
Hello,
I'm testing with OpenSER 1.3.x revision 4393 with RTPProxy.
I'm trying to make a call from a Nokia E51 to a SIPp instance started
with:
sipp -sn uas -p 6060 -mp 4000
The INVITE goes thru OpenSER to SIPp and then, SIPp replies with this:
SIPp to OpenSER:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 210.126.5.158
<http://210.126.5.158>;branch=z9hG4bK9c1e.f06224f3.0,
SIP/2.0/UDP 192.168.0.4:5060;received=123.224.149.169 <
http://123.224.149.169>;branch=z9hG4bK5j85u8aa6jpebhelr55b8bj;rport=64351
From: <sip:1000@210.126.5.158 <sip%3A1000(a)210.126.5.158> <mailto:
sip%3A1000(a)210.126.5.158 <sip%253A1000(a)210.126.5.158>
>;tag=r5hbkuj8mlhc6o184cms
To:
<sip:22222222@210.126.5.158 <sip%3A22222222(a)210.126.5.158> <mailto:
sip%3A22222222(a)210.126.5.158 <sip%253A22222222(a)210.126.5.158>
;user=phone>;tag=28909SIPpTag013
Call-ID: nLPxHi_hoIf-POcJ7OKojntw2wgQle
CSeq: 7342 INVITE
Contact: <sip:192.168.88.16:6060;transport=UDP>
Content-Type: application/sdp
Content-Length: 135
v=0
o=user1 53655765 2353687637 IN IP4 192.168.88.16 <http://192.168.88.16>
s=-
c=IN IP4 192.168.88.16 <http://192.168.88.16>
t=0 0
m=audio 4000 RTP/AVP 0
a=rtpmap:0 PCMU/8000
But when OpenSER relays this to E51, I can see it is adding
"a=nortpproxy:yes" immediatelly after the the last characters in the SDP
instead of prepending a CRLF.
OpenSER to Caller
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.0.4:5060;received=123.224.149.169 <
http://123.224.149.169>;branch=z9hG4bK5j85u8aa6jpebhelr55b8bj;rport=64351
From: <sip:1000@210.126.5.158 <sip%3A1000(a)210.126.5.158> <mailto:
sip%3A1000(a)210.126.5.158 <sip%253A1000(a)210.126.5.158>
>;tag=r5hbkuj8mlhc6o184cms
To:
<sip:22222222@210.126.5.158 <sip%3A22222222(a)210.126.5.158> <mailto:
sip%3A22222222(a)210.126.5.158 <sip%253A22222222(a)210.126.5.158>
;user=phone>;tag=28909SIPpTag013
Call-ID: nLPxHi_hoIf-POcJ7OKojntw2wgQle
CSeq: 7342 INVITE
Contact: <sip:210.126.5.158:6060;transport=UDP;nat=yes>
Content-Type: application/sdp
Content-Length: 154
v=0
o=user1 53655765 2353687637 IN IP4 192.168.88.16 <http://192.168.88.16>
s=-
c=IN IP4 210.126.5.158 <http://210.126.5.158>
t=0 0
m=audio 36740 RTP/AVP 0
a=rtpmap:0 PCMU/8000a=nortpproxy:yes
Because of this, E51 ignores the message and doesn't send ACK.
I believe this is a bug in OpenSER.
Thanks,
Takeshi
------------------------------------------------------------------------
_______________________________________________
Users mailing list
Users(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users
5793
days inactive
5793
days old
3 comments
3 participants
participants (3)
-
David Villasmil -
Klaus Darilion -
mayamatakeshi