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

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@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@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@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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

---

SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

On 10/27/10 9:54 PM, Klaus Darilion wrote:

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 :-)

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