27 Oct
2010
27 Oct
'10
3:27 p.m.
Never ever send private emails - they will be discarded, keep the
mailing list cc-ed.
Iptel org is running SIP Express Router 3.1. Take a ngrep of the traffic
and send it here, the hexa codes you send are not for humans to read,
like we are here on mailing lists. Otherwise make a tar.gz of pcap file.
SER changes content length only if it is an update to sdp (for nat
traversal), otherwise is the one set by the other phone.
Daniel
On 10/27/10 12:21 PM, t wrote:
Thanks Daniel,
fyi, the Content-Length doesn't match the actual length in the invite
ok returned from iptel.org <http://iptel.org> (213.192.59.75), and
the same situation also occurs from ekiga.net <http://ekiga.net>.
libosip2 interprets the rfc as saying that this 'should' be correct.
(and I buy this!).
it looks like an openser (opensips?) quirk.
anyway, I have put in code locally to fixup the Content-Length.
Thanks,
Tony.
73 75 62 0d 0a 43 6f 6e 74 65 6e 74 2d 4c 65 6e sub..Content-Len
67 74 68 3a 20 20 20 32 30 31 0d 0a 0d 0a 76 3d gth: 201....v=
30 0d 0a 6f 3d 74 77 69 6e 6b 6c 65 20 31 33 33 0..o=twinkle 133
33 37 30 37 32 38 39 20 38 30 39 37 35 37 36 37 3707289 80975767
33 20 49 4e 20 49 50 34 20 31 39 32 2e 31 36 38 3 IN IP4 192.168
2e 32 35 34 2e 31 0d 0a 73 3d 2d 0d 0a 63 3d 49 .254.1..s=-..c=I
4e 20 49 50 34 20 31 39 32 2e 31 36 38 2e 32 35 N IP4 192.168.25
34 2e 31 0d 0a 74 3d 30 20 30 0d 0a 6d 3d 61 75 4.1..t=0 0..m=au
64 69 6f 20 35 30 32 32 20 52 54 50 2f 41 56 50 dio 5022 RTP/AVP
20 39 38 20 31 30 31 0d 0a 61 3d 72 74 70 6d 61 98 101..a=rtpma
70 3a 39 38 20 73 70 65 65 78 2f 31 36 30 30 30 p:98 speex/16000
0d 0a 61 3d 72 74 70 6d 61 70 3a 31 30 31 20 74 ..a=rtpmap:101 t
65 6c 65 70 68 6f 6e 65 2d 65 76 65 6e 74 2f 38 elephone-event/8
30 30 30 0d 0a 61 3d 66 6d 74 70 3a 31 30 31 20 000..a=fmtp:101
30 2d 31 35 0d 0a 0-15..
On Wed, Oct 27, 2010 at 5:40 AM, Daniel-Constantin Mierla
<miconda(a)gmail.com <mailto:miconda@gmail.com>> wrote:
Hello,
you claim that contact header is malformed or libosip2 has issues
in parsing a good content header?
In case of first option, can you tell what it believes is wrong.
Your message is hard to follow since is not clear text, next time
send only the text part.
For the second option, you have to approach libosip2 support forums.
Cheers,
Daniel
On 10/25/10 10:44 PM, t wrote:
--
Daniel-Constantin Mierla
http://www.asipto.com
Hi,
Not sure how to provide this info (or even if anybody cares), but
libosip2 parser objects to incorrect (short) Content-Length from
iptel.org <http://iptel.org>.
Regards,
Tony.
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org <mailto:sr-users@lists.sip-router.org>
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla
http://www.asipto.com
27 Oct
27 Oct
9:10 p.m.
New subject: libosip2 parse body error
The hex output Tony sent is actually much more useful than plain-text
ngrep output you're asking for because it allows you to see the
problem--you can easily count the number of bytes in the payload.
The hex output may not be for humans to read, but it is for humans to count.
And it appears that he is right. I counted 200 bytes (2 + 12*16 + 6)
in the payload while the Content-Length header says 201.
-Jan
On Wed, Oct 27, 2010 at 6:27 AM, Daniel-Constantin Mierla
<miconda(a)gmail.com> wrote:
Never ever send private emails - they will be
discarded, keep the mailing
list cc-ed.
Iptel org is running SIP Express Router 3.1. Take a ngrep of the traffic and
send it here, the hexa codes you send are not for humans to read, like we
are here on mailing lists. Otherwise make a tar.gz of pcap file. SER changes
content length only if it is an update to sdp (for nat traversal), otherwise
is the one set by the other phone.
Daniel
On 10/27/10 12:21 PM, t wrote:
Thanks Daniel,
fyi, the Content-Length doesn't match the actual length in the invite ok
returned from iptel.org (213.192.59.75), and the same situation also occurs
from ekiga.net.
libosip2 interprets the rfc as saying that this 'should' be correct. (and I
buy this!).
it looks like an openser (opensips?) quirk.
anyway, I have put in code locally to fixup the Content-Length.
Thanks,
Tony.
73 75 62 0d 0a 43 6f 6e 74 65 6e 74 2d 4c 65 6e sub..Content-Len
67 74 68 3a 20 20 20 32 30 31 0d 0a 0d 0a 76 3d gth: 201....v=
30 0d 0a 6f 3d 74 77 69 6e 6b 6c 65 20 31 33 33 0..o=twinkle 133
33 37 30 37 32 38 39 20 38 30 39 37 35 37 36 37 3707289 80975767
33 20 49 4e 20 49 50 34 20 31 39 32 2e 31 36 38 3 IN IP4 192.168
2e 32 35 34 2e 31 0d 0a 73 3d 2d 0d 0a 63 3d 49 .254.1..s=-..c=I
4e 20 49 50 34 20 31 39 32 2e 31 36 38 2e 32 35 N IP4 192.168.25
34 2e 31 0d 0a 74 3d 30 20 30 0d 0a 6d 3d 61 75 4.1..t=0 0..m=au
64 69 6f 20 35 30 32 32 20 52 54 50 2f 41 56 50 dio 5022 RTP/AVP
20 39 38 20 31 30 31 0d 0a 61 3d 72 74 70 6d 61 98 101..a=rtpma
70 3a 39 38 20 73 70 65 65 78 2f 31 36 30 30 30 p:98 speex/16000
0d 0a 61 3d 72 74 70 6d 61 70 3a 31 30 31 20 74 ..a=rtpmap:101 t
65 6c 65 70 68 6f 6e 65 2d 65 76 65 6e 74 2f 38 elephone-event/8
30 30 30 0d 0a 61 3d 66 6d 74 70 3a 31 30 31 20 000..a=fmtp:101
30 2d 31 35 0d 0a 0-15..
On Wed, Oct 27, 2010 at 5:40 AM, Daniel-Constantin Mierla
<miconda(a)gmail.com> wrote:
Hello,
you claim that contact header is malformed or libosip2 has issues in
parsing a good content header?
In case of first option, can you tell what it believes is wrong. Your
message is hard to follow since is not clear text, next time send only the
text part.
For the second option, you have to approach libosip2 support forums.
Cheers,
Daniel
On 10/25/10 10:44 PM, t wrote:
Hi,
Not sure how to provide this info (or even if anybody cares), but libosip2
parser objects to incorrect (short) Content-Length from iptel.org.
Regards,
Tony.
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla
http://www.asipto.com
--
Daniel-Constantin Mierla
http://www.asipto.com
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
9:35 p.m.
New subject: libosip2 parse body error
What is interesting in this particular 200ok, is the fact that only
the IP was fixed:
- the private IP was substituted with the public IP:
- 192.168.254.1 -> 66.49.235.129
- the length of both IPs is the same
- the port was _not_ touched
- 5022 was provided and 5022 was sent back
I don't know what kind of media proxy module is used by iptel.org, but
both mediaproxy and nathelper modules are changing the port number
too. Don't know about iptrtpproxy.
Regards,
Ovidiu Sas
On Wed, Oct 27, 2010 at 12:10 PM, Jan Janak <jan(a)ryngle.com> wrote:
The hex output Tony sent is actually much more useful
than plain-text
ngrep output you're asking for because it allows you to see the
problem--you can easily count the number of bytes in the payload.
The hex output may not be for humans to read, but it is for humans to count.
And it appears that he is right. I counted 200 bytes (2 + 12*16 + 6)
in the payload while the Content-Length header says 201.
-Jan
On Wed, Oct 27, 2010 at 6:27 AM, Daniel-Constantin Mierla
<miconda(a)gmail.com> wrote:
Never ever send private emails - they will be
discarded, keep the mailing
list cc-ed.
Iptel org is running SIP Express Router 3.1. Take a ngrep of the traffic and
send it here, the hexa codes you send are not for humans to read, like we
are here on mailing lists. Otherwise make a tar.gz of pcap file. SER changes
content length only if it is an update to sdp (for nat traversal), otherwise
is the one set by the other phone.
Daniel
On 10/27/10 12:21 PM, t wrote:
Thanks Daniel,
fyi, the Content-Length doesn't match the actual length in the invite ok
returned from iptel.org (213.192.59.75), and the same situation also occurs
from ekiga.net.
libosip2 interprets the rfc as saying that this 'should' be correct. (and I
buy this!).
it looks like an openser (opensips?) quirk.
anyway, I have put in code locally to fixup the Content-Length.
Thanks,
Tony.
73 75 62 0d 0a 43 6f 6e 74 65 6e 74 2d 4c 65 6e sub..Content-Len
67 74 68 3a 20 20 20 32 30 31 0d 0a 0d 0a 76 3d gth: 201....v=
30 0d 0a 6f 3d 74 77 69 6e 6b 6c 65 20 31 33 33 0..o=twinkle 133
33 37 30 37 32 38 39 20 38 30 39 37 35 37 36 37 3707289 80975767
33 20 49 4e 20 49 50 34 20 31 39 32 2e 31 36 38 3 IN IP4 192.168
2e 32 35 34 2e 31 0d 0a 73 3d 2d 0d 0a 63 3d 49 .254.1..s=-..c=I
4e 20 49 50 34 20 31 39 32 2e 31 36 38 2e 32 35 N IP4 192.168.25
34 2e 31 0d 0a 74 3d 30 20 30 0d 0a 6d 3d 61 75 4.1..t=0 0..m=au
64 69 6f 20 35 30 32 32 20 52 54 50 2f 41 56 50 dio 5022 RTP/AVP
20 39 38 20 31 30 31 0d 0a 61 3d 72 74 70 6d 61 98 101..a=rtpma
70 3a 39 38 20 73 70 65 65 78 2f 31 36 30 30 30 p:98 speex/16000
0d 0a 61 3d 72 74 70 6d 61 70 3a 31 30 31 20 74 ..a=rtpmap:101 t
65 6c 65 70 68 6f 6e 65 2d 65 76 65 6e 74 2f 38 elephone-event/8
30 30 30 0d 0a 61 3d 66 6d 74 70 3a 31 30 31 20 000..a=fmtp:101
30 2d 31 35 0d 0a 0-15..
On Wed, Oct 27, 2010 at 5:40 AM, Daniel-Constantin Mierla
<miconda(a)gmail.com> wrote:
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Hello,
you claim that contact header is malformed or libosip2 has issues in
parsing a good content header?
In case of first option, can you tell what it believes is wrong. Your
message is hard to follow since is not clear text, next time send only the
text part.
For the second option, you have to approach libosip2 support forums.
Cheers,
Daniel
On 10/25/10 10:44 PM, t wrote:
Hi,
Not sure how to provide this info (or even if anybody cares), but libosip2
parser objects to incorrect (short) Content-Length from iptel.org.
Regards,
Tony.
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla
http://www.asipto.com
--
Daniel-Constantin Mierla
http://www.asipto.com
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
28 Oct
28 Oct
1:14 a.m.
New subject: libosip2 parse body error
Ovidiu Sas wrote:
What is interesting in this particular 200ok, is the
fact that only
the IP was fixed:
- the private IP was substituted with the public IP:
- 192.168.254.1 -> 66.49.235.129
- the length of both IPs is the same
- the port was _not_ touched
- 5022 was provided and 5022 was sent back
I remember having seen this behaviour (bug) from iptel.org proxy; it
seemed to me this may happen if both caller and callee are behind the
same NAT.
Stefan
1:54 a.m.
New subject: libosip2 parse body error
Well, then somebody at iptel.org should take a look at this ...
because there's something wrong there ...
Regards,
Ovidiu Sas
On Wed, Oct 27, 2010 at 4:14 PM, Stefan Sayer
<stefan.sayer(a)googlemail.com> wrote:
Ovidiu Sas wrote:
What is interesting in this particular 200ok, is the fact that only
the IP was fixed:
- the private IP was substituted with the public IP:
- 192.168.254.1 -> 66.49.235.129
- the length of both IPs is the same
- the port was _not_ touched
- 5022 was provided and 5022 was sent back
I remember having seen this behaviour (bug) from iptel.org proxy; it seemed
to me this may happen if both caller and callee are behind the same NAT.
Stefan
27 Oct
27 Oct
9:43 p.m.
New subject: libosip2 parse body error
On 10/27/10 6:10 PM, Jan Janak wrote:
The hex output Tony sent is actually much more useful
than plain-text
ngrep output you're asking for because it allows you to see the
problem--you can easily count the number of bytes in the payload.
The hex output may not be for humans to read, but it is for humans to count.
And it appears that he is right. I counted 200 bytes (2 + 12*16 + 6)
in the payload while the Content-Length header says 201.
If you read the email
again, then you may get what I wanted to say, I
asked for pcap tar.gz or ngrep.
Pcap is better to import in wireshark or even ngrep where you can
analyze thoroughly - tar.gz is recommended for pcap otherwise some email
clients do text encoding and the format gets broken.
Ngrep is easier to read directly and discover if the sdp is altered by
the proxy or is the one from them the phone.
Now, if it is easier for you to count hex codes by hart in a combined
content, then it is fine. For me is easier to get the body in text
format and use wc tool to count.
Cheers,
Daniel
-Jan
On Wed, Oct 27, 2010 at 6:27 AM, Daniel-Constantin Mierla
<miconda(a)gmail.com> wrote:
--
Daniel-Constantin Mierla
http://www.asipto.com
Never ever send private emails - they will be
discarded, keep the mailing
list cc-ed.
Iptel org is running SIP Express Router 3.1. Take a ngrep of the traffic and
send it here, the hexa codes you send are not for humans to read, like we
are here on mailing lists. Otherwise make a tar.gz of pcap file. SER changes
content length only if it is an update to sdp (for nat traversal), otherwise
is the one set by the other phone.
Daniel
On 10/27/10 12:21 PM, t wrote:
Thanks Daniel,
fyi, the Content-Length doesn't match the actual length in the invite ok
returned from iptel.org (213.192.59.75), and the same situation also occurs
from ekiga.net.
libosip2 interprets the rfc as saying that this 'should' be correct. (and I
buy this!).
it looks like an openser (opensips?) quirk.
anyway, I have put in code locally to fixup the Content-Length.
Thanks,
Tony.
73 75 62 0d 0a 43 6f 6e 74 65 6e 74 2d 4c 65 6e sub..Content-Len
67 74 68 3a 20 20 20 32 30 31 0d 0a 0d 0a 76 3d gth: 201....v=
30 0d 0a 6f 3d 74 77 69 6e 6b 6c 65 20 31 33 33 0..o=twinkle 133
33 37 30 37 32 38 39 20 38 30 39 37 35 37 36 37 3707289 80975767
33 20 49 4e 20 49 50 34 20 31 39 32 2e 31 36 38 3 IN IP4 192.168
2e 32 35 34 2e 31 0d 0a 73 3d 2d 0d 0a 63 3d 49 .254.1..s=-..c=I
4e 20 49 50 34 20 31 39 32 2e 31 36 38 2e 32 35 N IP4 192.168.25
34 2e 31 0d 0a 74 3d 30 20 30 0d 0a 6d 3d 61 75 4.1..t=0 0..m=au
64 69 6f 20 35 30 32 32 20 52 54 50 2f 41 56 50 dio 5022 RTP/AVP
20 39 38 20 31 30 31 0d 0a 61 3d 72 74 70 6d 61 98 101..a=rtpma
70 3a 39 38 20 73 70 65 65 78 2f 31 36 30 30 30 p:98 speex/16000
0d 0a 61 3d 72 74 70 6d 61 70 3a 31 30 31 20 74 ..a=rtpmap:101 t
65 6c 65 70 68 6f 6e 65 2d 65 76 65 6e 74 2f 38 elephone-event/8
30 30 30 0d 0a 61 3d 66 6d 74 70 3a 31 30 31 20 000..a=fmtp:101
30 2d 31 35 0d 0a 0-15..
On Wed, Oct 27, 2010 at 5:40 AM, Daniel-Constantin Mierla
<miconda(a)gmail.com> wrote:
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users Hello,
you claim that contact header is malformed or libosip2 has issues in
parsing a good content header?
In case of first option, can you tell what it believes is wrong. Your
message is hard to follow since is not clear text, next time send only the
text part.
For the second option, you have to approach libosip2 support forums.
Cheers,
Daniel
On 10/25/10 10:44 PM, t wrote:
Hi,
Not sure how to provide this info (or even if anybody cares), but libosip2
parser objects to incorrect (short) Content-Length from iptel.org.
Regards,
Tony.
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla
http://www.asipto.com
--
Daniel-Constantin Mierla
http://www.asipto.com
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
28 Oct
28 Oct
12:54 a.m.
New subject: libosip2 parse body error
On 10/27/2010 12:43 PM, Daniel-Constantin Mierla wrote:
Now, if it is easier for you to count hex codes by
hart in a combined
content, then it is fine. For me is easier to get the body in text
format and use wc tool to count.
Except it is hard to say if there is CR, CRLF, LF
(whatever) at the end
of the message :-)
regards
klaus
1:07 a.m.
New subject: libosip2 parse body error
On 10/27/10 9:54 PM, Klaus Darilion wrote:
On 10/27/2010 12:43 PM, Daniel-Constantin Mierla
wrote:
not sure what version you use, but in my ngpre, and as far
as I can
remember in the past, CR and LF were always printed as dot '.' unless
you use -W byline when the LF is printed as new line, CR is still '.'.
Further you can use -P to change the '.' to something else
So regarding the content length that is enough and I do use the command
for long time to check the body size -- if you have -W byline just add
'wc -l'.
But counting by hart, with wc or something else is a completely
different story and maybe was not clear in my first email as people
started to debate this instead of trying to figure out the real problem,
so repeating here -- I haven't doubted that the content length header
value is different that the size of the body, as Tony said that clear.
I asked ngrep or pcap to see if the body was altered by the proxy or is
the one from the other phone. I mentioned the proxy does not change the
body and content length unless is nat traversal involved (or, of course,
textops-like changes to body).
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com
Now, if it is easier for you to count hex codes
by hart in a combined
content, then it is fine. For me is easier to get the body in text
format and use wc tool to count.
Except it is hard to say if there is CR, CRLF, LF
(whatever) at the
end of the message :-)
4933
days inactive
4933
days old
7 comments
5 participants
participants (5)
-
Daniel-Constantin Mierla -
Jan Janak -
Klaus Darilion -
Ovidiu Sas -
Stefan Sayer