Hello Daniel,

Thank for reply !

do you have the pcap for such message?

Here is the message, I capture via Wireshark on client: *Session Initiation Protocol (INVITE)* * Request-Line: INVITE sip:buiduchahai@happy.anttel-pro.ab-kz-02.antbuddy.com sip%3Abuiduchahai@happy.anttel-pro.ab-kz-02.antbuddy.com SIP/2.0* * Message Header* * Via: SIP/2.0/TCP 10.0.2.15:57735;rport;branch=z9hG4bKPjaXcUF2ZkxyQGYCb3a57cPQ3rkcKMY.eS;alias* * Max-Forwards: 70* * From: "Phap Huynh" <sip:huynhngocphap@happy.anttel-pro.ab-kz-02.antbuddy.com sip%3Ahuynhngocphap@happy.anttel-pro.ab-kz-02.antbuddy.com>;tag=zJBNvD67y3E.1I5Y5ZrRI4JmP5JKeNWO* * To: <sip:buiduchahai@happy.anttel-pro.ab-kz-02.antbuddy.com sip%3Abuiduchahai@happy.anttel-pro.ab-kz-02.antbuddy.com>* * Contact: sip:huynhngocphap@49.156.54.54:50785;transport=TCP;ob* * Call-ID: ftMudIpIQeKWwP8kQDi2z1S0D1sV3KaB* * CSeq: 29055 INVITE* * Route: sip:125.212.212.40;transport=tcp;lr* * Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS* * Supported: replaces, 100rel, timer, norefersub* * Session-Expires: 1800* * Min-SE: 9* * User-Agent: CSipSimple_hlteatt-19/r55* * [truncated]Proxy-Authorization: Digest username="huynhngocphap", realm="happy.anttel-pro.ab-kz-02.antbuddy.com http://happy.anttel-pro.ab-kz-02.antbuddy.com", nonce="452a7bce-d326-11e6-a605-e9dce514db6e", uri="sip:buiduchahai@happy.anttel-pro.ab-kz-02.antbuddy.com sip%3Abuiduchahai@happy.anttel-pro.ab-kz-02.antbuddy.com", response="71749de* * Content-Type: application/sdp* * Content-Length: 299* * Message Body* * Session Description Protocol* * Session Description Protocol Version (v): 0* * Owner/Creator, Session Id (o): - 3692596134 3692596134 IN IP4 10.0.2.15* * Session Name (s): pjmedia* * Connection Information (c): IN IP4 10.0.2.15* * Time Description, active time (t): 0 0* * Media Description, name and address (m): audio 4002 RTP/AVP 9 0 8 101* * Connection Information (c): IN IP4 10.0.2.15* * Media Attribute (a): rtcp:4003 IN IP4 10.0.2.15* * Media Attribute (a): sendrecv* * Media Attribute (a): rtpmap:9 G722/8000* * Media Attribute (a): rtpmap:0 PCMU/8000* * Media Attribute (a): rtpmap:8 PCMA/8000* * Media Attribute (a): rtpmap:101 telephone-event/8000* * Media Attribute (a): fmtp:101 0-16*

And this is message I receive on Freeswitch: ------------------------------------------------------------------------ INVITE sip:buiduchahai@happy.anttel-pro.ab-kz-02.antbuddy.com SIP/2.0 Record-Route: sip:125.212.212.40;transport=tcp;lr=on;ftag=zJBNvD67y3E.1I5Y5ZrRI4JmP5JKeNWO Via: SIP/2.0/TCP 125.212.212.40:5060 ;branch=z9hG4bK0d89.3807a4cf41ce9b48a7d1a75826762d6e.0;i=533c Via: SIP/2.0/TCP 10.0.2.15:57735 ;received=49.156.54.54;rport=50785;branch=z9hG4bKPjaXcUF2ZkxyQGYCb3a57cPQ3rkcKMY.eS;alias Max-Forwards: 50 From: "Phap Huynh" < sip:huynhngocphap@happy.anttel-pro.ab-kz-02.antbuddy.com

;tag=zJBNvD67y3E.1I5Y5ZrRI4JmP5JKeNWO

To: sip:buiduchahai@happy.anttel-pro.ab-kz-02.antbuddy.com Contact: sip:huynhngocphap@49.156.54.54:50785;transport=TCP;ob Call-ID: ftMudIpIQeKWwP8kQDi2z1S0D1sV3KaB CSeq: 29055 INVITE Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS Supported: replaces, 100rel, timer, norefersub Session-Expires: 1800 Min-SE: 9 User-Agent: CSipSimple_hlteatt-19/r55 Proxy-Authorization: Digest username="huynhngocphap", realm=" happy.anttel-pro.ab-kz-02.antbuddy.com", nonce="452a7bce-d326-11e6-a605-e9dce514db6e", uri=" sip:buiduchahai@happy.anttel-pro.ab-kz-02.antbuddy.com", response="71749de35a220aef0b92c9ade03f90b7", algorithm=MD5, cnonce="px.OiQUg2zZmYh.0-MmLC0f.-ZPXYa1V", qop=auth, nc=00000001 Content-Type: application/sdp Content-Length: 289 X-AUTH-IP: 49.156.54.54 X-AUTH-PORT: 50785

v=0 o=- 3692596134 3692596134 IN IP4 49.156.54.54 s=pjmedia c=IN IP4 49.156.54.54 t=0 0 m=audio 4002 RTP/AVP 9 0 8 101 c=IN IP4 49.156.54.54 a=rtcp:4003 a=sendrecv a=rtpmap:9 G722/8000 a=rtpmap:0 PCMU/8000 a=oldmediaip:10.0.2.15 a=oldmediaip:10.0.2.15 a=oldmediaip:10.0.2.15 ------------------------------------------------------------------------

You can see, it missing: * Media Attribute (a): rtpmap:8 PCMA/8000* * Media Attribute (a): rtpmap:101 telephone-event/8000* * Media Attribute (a): fmtp:101 0-16*

Is it happening for the ACK you pasted or some other message?

It only happen on ACK messages, when my client reply 200 OK /SDP to server to establish call.

For more detail: I use another soft phone on Android like Zoiper and test with the same scenario, it work ok. And when my client use 3G, it still work ok.

Regards, Hai Bui

On Thu, Jan 5, 2017 at 10:25 PM, Daniel-Constantin Mierla <miconda@gmail.com

wrote:

Hello,

do you have the pcap for such message? Is it happening for the ACK you pasted or some other message?

Cheers, Daniel

On 05/01/2017 12:16, Hai Bui Duc Ha wrote:

Hi all,

I have problem when make call with my Android mobile use PJSIP library. Scenario:

my client -> Kamailio -> Freeswitch (media server) -> another client (soft phone on Windows)

my client:

• use Bluestack
• Capture via Wireshark
• use Wifi

Issue: The call will be drop after ~ 30 second.

I see the error on Kamailio: *Jan 5 16:08:59 ab-kz-02 kamailio[6343]: ERROR: <core> [parser/parse_fline.c:257]: parse_first_line(): parse_first_line: bad message (offset: 13)* *Jan 5 16:08:59 ab-kz-02 kamailio[6343]: ERROR: <core> [parser/parse_fline.c:257]: parse_first_line(): parse_first_line: bad message (offset: 13)* *Jan 5 16:08:59 ab-kz-02 kamailio[6343]: ERROR: <core> [parser/msg_parser.c:690]: parse_msg(): ERROR: parse_msg: message=<p:8 PCMA/8000#015#012a=rtpmap:101 telephone-event/8000#015#012a=fmtp:101 0-16#015#012ACK sip:buiduchahai@125.212.212.36:11000;transport=tcp SIP/2.0#015#012Via: SIP/2.0/TCP 10.0.2.15:57735;rport;branch=z9hG4bKPjlgc13AjrUrFJHq60vWhGqsUaGXi2F98Z;alias#015#012Max-Forwards: 70#015#012From: "Phap Huynh" <sip:huynhngocphap@happy.anttel-pro.ab-kz-02.antbuddy.com sip%3Ahuynhngocphap@happy.anttel-pro.ab-kz-02.antbuddy.com>;tag=zJBNvD67y3E.1I5Y5ZrRI4JmP5JKeNWO#015#012To: <sip:buiduchahai@happy.anttel-pro.ab-kz-02.antbuddy.com sip%3Abuiduchahai@happy.anttel-pro.ab-kz-02.antbuddy.com>;tag=2SF4D790Zy6Kj#015#012Call-ID: ftMudIpIQeKWwP8kQDi2z1S0D1sV3KaB#015#012CSeq: 29055 ACK#015#012Route: sip:125.212.212.40;transport=tcp;lr;ftag=zJBNvD67y3E.1I5Y5ZrRI4JmP5JKeNWO#015#012Content-Length: 0#015#012#015#012>* *Jan 5 16:08:59 ab-kz-02 kamailio[6343]: ERROR: <core> [receive.c:129]: receive_msg(): core parsing of SIP message failed (49.156.54.54:50785/2 http://49.156.54.54:50785/2)*

Seem to the server error when parse (on INVITE SDP)

*a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16*

(on new ACK message) *ACK sip:buiduchahai@125.212.212.36:11000;transport=tcp SIP/2.0* *Via: SIP/2.0/TCP 10.0.2.15:57735;rport;branch=z9hG4bKPjlgc13AjrUrFJHq60vWhGqsUaGXi2F98Z;alias* *Max-Forwards: 70* *From: "Phap Huynh" <sip:huynhngocphap@happy.anttel-pro.ab-kz-02.antbuddy.com sip%3Ahuynhngocphap@happy.anttel-pro.ab-kz-02.antbuddy.com>;tag=zJBNvD67y3E.1I5Y5ZrRI4JmP5JKeNWO* *To: <sip:buiduchahai@happy.anttel-pro.ab-kz-02.antbuddy.com sip%3Abuiduchahai@happy.anttel-pro.ab-kz-02.antbuddy.com>;tag=2SF4D790Zy6Kj* *Call-ID: ftMudIpIQeKWwP8kQDi2z1S0D1sV3KaB* *CSeq: 29055 ACK* *Route: sip:125.212.212.40;transport=tcp;lr;ftag=zJBNvD67y3E.1I5Y5ZrRI4JmP5JKeNWO* *Content-Length: 0*

I think the SIP message is fragmented but when resume package is not correct. Do you have any advice ? Thank you for watching !

Regards, Hai Bui

-- Hai Bui VoIP engineer, Cvoice team, HTK-HCM Office Mobile: +84-165-618-9876

---

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

-- Daniel-Constantin Mierlawww.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.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

Hello,

apparently I missed the follow ups on this discussion, dragged in by other topics on mailing list.

Can you get the pcap with all the traffic taken on kamailio server for the call (from initial invite to the end of the call)? I expect that content length is mismatching or there is a '\0' inside the sdp.

On 06/01/2017 03:39, Hai Bui Duc Ha wrote:

Hello Daniel,

Thank for reply !

do you have the pcap for such message?

Here is the message, I capture via Wireshark on client:
/Session Initiation Protocol (INVITE)/
/    Request-Line: INVITE
sip:buiduchahai@happy.anttel-pro.ab-kz-02.antbuddy.com
<mailto:sip%3Abuiduchahai@happy.anttel-pro.ab-kz-02.antbuddy.com>
SIP/2.0/
/    Message Header/
/        Via: SIP/2.0/TCP
10.0.2.15:57735;rport;branch=z9hG4bKPjaXcUF2ZkxyQGYCb3a57cPQ3rkcKMY.eS;alias/
/        Max-Forwards: 70/
/        From: "Phap Huynh"
<sip:huynhngocphap@happy.anttel-pro.ab-kz-02.antbuddy.com
<mailto:sip%3Ahuynhngocphap@happy.anttel-pro.ab-kz-02.antbuddy.com>>;tag=zJBNvD67y3E.1I5Y5ZrRI4JmP5JKeNWO/
/        To:
<sip:buiduchahai@happy.anttel-pro.ab-kz-02.antbuddy.com
<mailto:sip%3Abuiduchahai@happy.anttel-pro.ab-kz-02.antbuddy.com>>/
/        Contact:
<sip:huynhngocphap@49.156.54.54:50785;transport=TCP;ob>/
/        Call-ID: ftMudIpIQeKWwP8kQDi2z1S0D1sV3KaB/
/        CSeq: 29055 INVITE/
/        Route: <sip:125.212.212.40;transport=tcp;lr>/
/        Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO,
SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS/
/        Supported: replaces, 100rel, timer, norefersub/
/        Session-Expires: 1800/
/        Min-SE: 9/
/        User-Agent: CSipSimple_hlteatt-19/r55/
/         [truncated]Proxy-Authorization: Digest
username="huynhngocphap",
realm="happy.anttel-pro.ab-kz-02.antbuddy.com
<http://happy.anttel-pro.ab-kz-02.antbuddy.com>",
nonce="452a7bce-d326-11e6-a605-e9dce514db6e",
uri="sip:buiduchahai@happy.anttel-pro.ab-kz-02.antbuddy.com
<mailto:sip%3Abuiduchahai@happy.anttel-pro.ab-kz-02.antbuddy.com>",
response="71749de/
/        Content-Type: application/sdp/
/        Content-Length:   299/
/    Message Body/
/        Session Description Protocol/
/            Session Description Protocol Version (v): 0/
/            Owner/Creator, Session Id (o): - 3692596134
3692596134 IN IP4 10.0.2.15/
/            Session Name (s): pjmedia/
/            Connection Information (c): IN IP4 10.0.2.15/
/            Time Description, active time (t): 0 0/
/            Media Description, name and address (m): audio 4002
RTP/AVP 9 0 8 101/
/            Connection Information (c): IN IP4 10.0.2.15/
/            Media Attribute (a): rtcp:4003 IN IP4 10.0.2.15/
/            Media Attribute (a): sendrecv/
/            Media Attribute (a): rtpmap:9 G722/8000/
/            Media Attribute (a): rtpmap:0 PCMU/8000/
/*            Media Attribute (a): rtpmap:8 PCMA/8000*/
/*            Media Attribute (a): rtpmap:101 telephone-event/8000*/
/*            Media Attribute (a): fmtp:101 0-16*/
/*
*/
And this is message I receive on Freeswitch:
 ------------------------------------------------------------------------
   INVITE sip:buiduchahai@happy.anttel-pro.ab-kz-02.antbuddy.com
<mailto:sip%3Abuiduchahai@happy.anttel-pro.ab-kz-02.antbuddy.com>
SIP/2.0
   Record-Route:
<sip:125.212.212.40;transport=tcp;lr=on;ftag=zJBNvD67y3E.1I5Y5ZrRI4JmP5JKeNWO>
   Via: SIP/2.0/TCP
125.212.212.40:5060;branch=z9hG4bK0d89.3807a4cf41ce9b48a7d1a75826762d6e.0;i=533c
   Via: SIP/2.0/TCP
10.0.2.15:57735;received=49.156.54.54;rport=50785;branch=z9hG4bKPjaXcUF2ZkxyQGYCb3a57cPQ3rkcKMY.eS;alias
   Max-Forwards: 50
   From: "Phap Huynh"
<sip:huynhngocphap@happy.anttel-pro.ab-kz-02.antbuddy.com
<mailto:sip%3Ahuynhngocphap@happy.anttel-pro.ab-kz-02.antbuddy.com>>;tag=zJBNvD67y3E.1I5Y5ZrRI4JmP5JKeNWO
   To: <sip:buiduchahai@happy.anttel-pro.ab-kz-02.antbuddy.com
<mailto:sip%3Abuiduchahai@happy.anttel-pro.ab-kz-02.antbuddy.com>>
   Contact: <sip:huynhngocphap@49.156.54.54:50785;transport=TCP;ob>
   Call-ID: ftMudIpIQeKWwP8kQDi2z1S0D1sV3KaB
   CSeq: 29055 INVITE
   Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO,
SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
   Supported: replaces, 100rel, timer, norefersub
   Session-Expires: 1800
   Min-SE: 9
   User-Agent: CSipSimple_hlteatt-19/r55
   Proxy-Authorization: Digest username="huynhngocphap",
realm="happy.anttel-pro.ab-kz-02.antbuddy.com
<http://happy.anttel-pro.ab-kz-02.antbuddy.com>",
nonce="452a7bce-d326-11e6-a605-e9dce514db6e",
uri="sip:buiduchahai@happy.anttel-pro.ab-kz-02.antbuddy.com
<mailto:sip%3Abuiduchahai@happy.anttel-pro.ab-kz-02.antbuddy.com>",
response="71749de35a220aef0b92c9ade03f90b7", algorithm=MD5,
cnonce="px.OiQUg2zZmYh.0-MmLC0f.-ZPXYa1V", qop=auth, nc=00000001
   Content-Type: application/sdp
   Content-Length:   289
   X-AUTH-IP: 49.156.54.54
   X-AUTH-PORT: 50785

   v=0
   o=- 3692596134 3692596134 IN IP4 49.156.54.54
   s=pjmedia
   c=IN IP4 49.156.54.54
   t=0 0
   m=audio 4002 RTP/AVP 9 0 8 101
   c=IN IP4 49.156.54.54
   a=rtcp:4003
   a=sendrecv
   a=rtpmap:9 G722/8000
   a=rtpmap:0 PCMU/8000
   a=oldmediaip:10.0.2.15
   a=oldmediaip:10.0.2.15
   a=oldmediaip:10.0.2.15

 ------------------------------------------------------------------------

You can see, it missing: /* Media Attribute (a): rtpmap:8 PCMA/8000*/ /* Media Attribute (a): rtpmap:101 telephone-event/8000*/ /* Media Attribute (a): fmtp:101 0-16*/

Is it happening for the ACK you pasted or some other message?

It only happen on ACK messages, when my client reply 200 OK /SDP
to server to establish call.

For more detail: I use another soft phone on Android like Zoiper and test with the same scenario, it work ok. And when my client use 3G, it still work ok.

Regards, Hai Bui

/* */

On Thu, Jan 5, 2017 at 10:25 PM, Daniel-Constantin Mierla <miconda@gmail.com mailto:miconda@gmail.com> wrote:

Hello,

do you have the pcap for such message? Is it happening for the ACK
you pasted or some other message?

Cheers,
Daniel


On 05/01/2017 12:16, Hai Bui Duc Ha wrote:

...

Hi all,

I have problem when make call with my Android mobile use PJSIP
library.
Scenario:

my client  -> Kamailio -> Freeswitch (media server) -> another
client (soft phone on Windows)

my client:
 + use Bluestack
 + Capture via Wireshark
 + use Wifi

Issue: The call will be drop after ~ 30 second.

I see the error on Kamailio:
/Jan  5 16:08:59 ab-kz-02 kamailio[6343]: ERROR: <core>
[parser/parse_fline.c:257]: parse_first_line(): parse_first_line:
bad message (offset: 13)/
/Jan  5 16:08:59 ab-kz-02 kamailio[6343]: ERROR: <core>
[parser/parse_fline.c:257]: parse_first_line(): parse_first_line:
bad message (offset: 13)/
/Jan  5 16:08:59 ab-kz-02 kamailio[6343]: ERROR: <core>
[parser/msg_parser.c:690]: parse_msg(): ERROR: parse_msg:
message=<p:8 PCMA/8000#015#012a=rtpmap:101
telephone-event/8000#015#012a=fmtp:101 0-16#015#012ACK
sip:buiduchahai@125.212.212.36:11000;transport=tcp
SIP/2.0#015#012Via: SIP/2.0/TCP
10.0.2.15:57735;rport;branch=z9hG4bKPjlgc13AjrUrFJHq60vWhGqsUaGXi2F98Z;alias#015#012Max-Forwards:
70#015#012From: "Phap Huynh"
<sip:huynhngocphap@happy.anttel-pro.ab-kz-02.antbuddy.com
<mailto:sip%3Ahuynhngocphap@happy.anttel-pro.ab-kz-02.antbuddy.com>>;tag=zJBNvD67y3E.1I5Y5ZrRI4JmP5JKeNWO#015#012To:
<sip:buiduchahai@happy.anttel-pro.ab-kz-02.antbuddy.com
<mailto:sip%3Abuiduchahai@happy.anttel-pro.ab-kz-02.antbuddy.com>>;tag=2SF4D790Zy6Kj#015#012Call-ID:
ftMudIpIQeKWwP8kQDi2z1S0D1sV3KaB#015#012CSeq: 29055
ACK#015#012Route:
<sip:125.212.212.40;transport=tcp;lr;ftag=zJBNvD67y3E.1I5Y5ZrRI4JmP5JKeNWO>#015#012Content-Length:
 0#015#012#015#012>/
/Jan  5 16:08:59 ab-kz-02 kamailio[6343]: ERROR: <core>
[receive.c:129]: receive_msg(): core parsing of SIP message
failed (49.156.54.54:50785/2 <http://49.156.54.54:50785/2>)/

Seem to the server error when parse
(on INVITE SDP)
/a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16/

(on new ACK message)
/ACK sip:buiduchahai@125.212.212.36:11000;transport=tcp SIP/2.0/
/Via: SIP/2.0/TCP
10.0.2.15:57735;rport;branch=z9hG4bKPjlgc13AjrUrFJHq60vWhGqsUaGXi2F98Z;alias/
/Max-Forwards: 70/
/From: "Phap Huynh"
<sip:huynhngocphap@happy.anttel-pro.ab-kz-02.antbuddy.com
<mailto:sip%3Ahuynhngocphap@happy.anttel-pro.ab-kz-02.antbuddy.com>>;tag=zJBNvD67y3E.1I5Y5ZrRI4JmP5JKeNWO/
/To: <sip:buiduchahai@happy.anttel-pro.ab-kz-02.antbuddy.com
<mailto:sip%3Abuiduchahai@happy.anttel-pro.ab-kz-02.antbuddy.com>>;tag=2SF4D790Zy6Kj/
/Call-ID: ftMudIpIQeKWwP8kQDi2z1S0D1sV3KaB/
/CSeq: 29055 ACK/
/Route:
<sip:125.212.212.40;transport=tcp;lr;ftag=zJBNvD67y3E.1I5Y5ZrRI4JmP5JKeNWO>/
/Content-Length:  0/

I think the SIP message is fragmented but when resume package is
not correct.
Do you have any advice ? Thank you for watching !

Regards,
Hai Bui


-- 
Hai Bui
VoIP engineer, Cvoice team, HTK-HCM Office
Mobile: +84-165-618-9876


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

-- 
Daniel-Constantin Mierla
www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com <http://www.kamailioworld.com>

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

-- Hai Bui VoIP engineer, Cvoice team, HTK-HCM Office Mobile: +84-165-618-9876

Hello,

On 19/01/2017 10:48, Hai Bui Duc Ha wrote:

Hi Daniel,

Thank you for reply.

On Tue, Jan 17, 2017 at 6:05 PM, Daniel-Constantin Mierla <miconda@gmail.com mailto:miconda@gmail.com> wrote:

Hello,

apparently I missed the follow ups on this discussion, dragged in
by other topics on mailing list. 

Can you get the pcap with all the traffic taken on kamailio server
for the call (from initial invite to the end of the call)?

I send you the pcap at enclosed file. You can see the packet *No.5 *, it missing SIP message body: /* Media Attribute (a): rtpmap:8 PCMA/8000*/ /* Media Attribute (a): rtpmap:101 telephone-event/8000*/ /* Media Attribute (a): fmtp:101 0-16*/

I expect that content length is mismatching or there is a '\0'
inside the sdp.

Can you explain me more about this ?

TCP is a stream protocol, meaning that the application (kamailio) need to read and parse to figure out the end of a SIP message. The state machine as per RFC requires the application to read and identify the Content-Length header, take its value, read until the end of headers is found (an empty line) and from there on read as much as the value of Content-Length to get the body and consider the end of message there.

If the sending application puts a lower value in the Content-Length than the number of chars in the body, the rest remains in the buffer and the receiving application (kamailio) attempts to parse a new SIP message.

The other thing I was thinking of was the presence of '\0' which marks the end of string in C.

I will look at the pcap very soon and see what I find there.

Cheers, Daniel

Hi Daniel,

Thank for your advice. I will capture and analyze the call log on both client and kamailio to check the packet size.

Regards, Hai Bui

On Fri, Jan 20, 2017 at 3:38 PM, Daniel-Constantin Mierla <miconda@gmail.com

wrote:

On 19/01/2017 22:56, Daniel-Constantin Mierla wrote:

Hello,

On 19/01/2017 10:48, Hai Bui Duc Ha wrote:

Hi Daniel,

Thank you for reply.

On Tue, Jan 17, 2017 at 6:05 PM, Daniel-Constantin Mierla < miconda@gmail.com> wrote:

...

Hello,

apparently I missed the follow ups on this discussion, dragged in by other topics on mailing list.

Can you get the pcap with all the traffic taken on kamailio server for the

...

call (from initial invite to the end of the call)?

I send you the pcap at enclosed file. You can see the packet *No.5 *, it missing SIP message body:

•        Media Attribute (a): rtpmap:8 PCMA/8000*
  

•        Media Attribute (a): rtpmap:101 telephone-event/8000*
  

•        Media Attribute (a): fmtp:101 0-16*
  
  

...

I expect that content length is mismatching or there is a '\0' inside the sdp.

Can you explain me more about this ?

TCP is a stream protocol, meaning that the application (kamailio) need to read and parse to figure out the end of a SIP message. The state machine as per RFC requires the application to read and identify the Content-Length header, take its value, read until the end of headers is found (an empty line) and from there on read as much as the value of Content-Length to get the body and consider the end of message there.

If the sending application puts a lower value in the Content-Length than the number of chars in the body, the rest remains in the buffer and the receiving application (kamailio) attempts to parse a new SIP message.

The other thing I was thinking of was the presence of '\0' which marks the end of string in C.

I will look at the pcap very soon and see what I find there.

The problem is the value of Content-Lenght set by the client -- it is set only to the size that it is view as part of the invite. A bit later the client sends more sdp, but exceeding the size sent in C-L header. That part of SDP remains as garbage.

So there is a bug in client app.

Cheers, Daniel

-- Daniel-Constantin Mierlawww.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com

Hello,

with TCP there is no MTU. In the previous pcap you sent there was a wrong Content-Length value. Was that fixed?

Cheers, Daniel

On 06/02/2017 12:24, Hai Bui Duc Ha wrote:

Hi Daniel,

I send you the pcap files on both client and server side. Analyse this files, I see the packet can not "reassemble" INVITE message at server side:

• At client.pcapng, it can detect 6 and 7th packets are one.
• But on server.pcap, it can not "reassemble" 18 and 21st packets.

I just explain as my understand. If you have any information, please ask me. I think the problem relate the MTU - fragmentation. But I'm not sure about this. Thank you for support !

Regards, Hai Bui

On Sun, Jan 22, 2017 at 4:33 PM, Hai Bui Duc Ha <hai.bui@htklabs.com mailto:hai.bui@htklabs.com> wrote:

Hi Daniel,

Thank for your advice.
I will capture and analyze the call log on both client and
kamailio to check the packet size.

Regards,
Hai Bui


On Fri, Jan 20, 2017 at 3:38 PM, Daniel-Constantin Mierla
<miconda@gmail.com <mailto:miconda@gmail.com>> wrote:



    On 19/01/2017 22:56, Daniel-Constantin Mierla wrote:

...

    Hello,


    On 19/01/2017 10:48, Hai Bui Duc Ha wrote:

...

    Hi Daniel,

    Thank you for reply.

    On Tue, Jan 17, 2017 at 6:05 PM, Daniel-Constantin Mierla
    <miconda@gmail.com <mailto:miconda@gmail.com>> wrote:

        Hello,

        apparently I missed the follow ups on this discussion,
        dragged in by other topics on mailing list. 

        Can you get the pcap with all the traffic taken on
        kamailio server for the call (from initial invite to the
        end of the call)?

    I send you the pcap at enclosed file. You can see the packet
    *No.5 *, it missing SIP message body:
    /*            Media Attribute (a): rtpmap:8 PCMA/8000*/
    /*            Media Attribute (a): rtpmap:101
    telephone-event/8000*/
    /*            Media Attribute (a): fmtp:101 0-16*/

        I expect that content length is mismatching or there is
        a '\0' inside the sdp.

    Can you explain me more about this ?

    TCP is a stream protocol, meaning that the application
    (kamailio) need to read and parse to figure out the end of a
    SIP message. The state machine as per RFC requires the
    application to read and identify the Content-Length header,
    take its value, read until the end of headers is found (an
    empty line) and from there on read as much as the value of
    Content-Length to get the body and consider the end of
    message there.

    If the sending application puts a lower value in the
    Content-Length than the number of chars in the body, the rest
    remains in the buffer and the receiving application
    (kamailio) attempts to parse a new SIP message.

    The other thing I was thinking of was the presence of '\0'
    which marks the end of string in C.

    I will look at the pcap very soon and see what I find there.

    The problem is the value of Content-Lenght set by the client
    -- it is set only to the size that it is view as part of the
    invite. A bit later the client sends more sdp, but exceeding
    the size sent in C-L header. That part of SDP remains as garbage.

    So there is a bug in client app.

    Cheers,
    Daniel

    -- 
    Daniel-Constantin Mierla
    www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
    Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com <http://www.kamailioworld.com>




-- 
Hai Bui
VoIP engineer, Cvoice team, HTK-HCM Office
Mobile: +84-165-618-9876

-- Hai Bui VoIP engineer, Cvoice team, HTK-HCM Office Mobile: +84-165-618-9876