linphone-developers
[Top][All Lists]
Advanced
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Linphone-developers] Incoming call error (Failed to parse SDP)

From: Ghislain MARY
Subject: Re: [Linphone-developers] Incoming call error (Failed to parse SDP)
Date: Wed, 7 Oct 2015 15:10:28 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
Hi Giacomo,

Thanks for having dug into this issue. There was really a bug in the attributes name parsing in belle-sip that was too restrictive.
I just fix the issue, so if you update belle-sip you should no longer have this parsing error.

Cheers,
Ghislain

On 10/07/2015 02:22 PM, Giacomo Furlan wrote:
Free thoughts

Line I'm trying to figure out what may be the problem: "a=ex_fmtp:102 2CIF=1"
Position 4 (assuming index starts from 0): "_"

Linphone seems to work fine with the previous audio codec's attribute, which does not use the underscore, but simply "fmtp" and not "ex_fmtp".
 It throws a token exception on the "_" character, and that is the very first time the parser encounters it in the whole message. May it be the linphone does not handle attributes that have the "_" symbol inside of the value?

I'm trying my best to try a solution, but it's very hard...

Thanks

Giacomo Furlan
Software developer
Software Solutions Designs

2015-10-07 9:53 GMT+02:00 Giacomo Furlan <address@hidden>:
Hello Gautier,

I thought that it may handy to have a "faulty" packet in order to send it to linphone and see what's wrong. This is thus the UDP packet that provoke the error:

5669613a205349502f322e302f554450203139322e3136382e302e3230313a353036303b72706f72743b6272616e63683d7a39684734624b323039353732373338320d0a46726f6d3a203c7369703a31303039393031403139322e3136382e302e3230313e3b7461673d313734373333373235300d0a546f3a203c7369703a31303530403139322e3136382e302e3137323a383838383e0d0a43616c6c2d49443a20313634373237363235360d0a435365713a20323020494e564954450d0a436f6e746163743a203c7369703a313030403139322e3136382e302e3230313a353036303e0d0a436f6e74656e742d547970653a206170706c69636174696f6e2f7364700d0a4d61782d466f7277617264733a2037300d0a557365722d4167656e743a20446e616b65566f69702076312e300d0a436f6e74656e742d4c656e6774683a2020203432360d0a0d0a

Also when the "488 not acceptable here" message is being sent, the SIP server will reply with an ACK which Linphone thinks it's malformed (always returns 400 Bad Request, due to ""Missing mandatory header [Max-Forwards] for message [ACK]"). This is the ACK message:

000ce7407428001fd06e4f75080045000122000040004011b705c0a800c9c0a800ac13c422b8010e90c341434b207369703a31303530403139322e3136382e302e3137323a38383838205349502f322e300d0a5669613a205349502f322e302f554450203139322e3136382e302e3230313a353036303b72706f72743b6272616e63683d7a39684734624b323039353732373338320d0a46726f6d3a203c7369703a31303039393031403139322e3136382e302e3230313e3b7461673d313734373333373235300d0a546f3a203c7369703a31303530403139322e3136382e302e3137323a383838383e3b7461673d52454e476f36380d0a43616c6c2d49443a20313634373237363235360d0a435365713a2032302041434b0d0a436f6e74656e742d4c656e6774683a20300d0a0d0a

Thank you


Giacomo Furlan
Software developer
Software Solutions Designs
2015-10-06 16:09 GMT+02:00 Giacomo Furlan <address@hidden>:
Hello Gautier,

thanks for the reply. I've got the very same issue both with the Android Play Store version and the one I've compiled from the sources. When I first tried the Play Store version I thought it was something to do with the ports, but logcat'ing it I found that was indeed the error and the cause of failure of the call.

Thank you for any hint :)

Giacomo Furlan
Software developer
Software Solutions Designs
2015-10-06 16:07 GMT+02:00 Gautier Pelloux-Prayer <address@hidden>:
Do you reproduce the issue with Linphone ?

Cheers,

Gautier Pelloux-Prayer
Software Engineer @ Belledonne Communications

> On 06 Oct 2015, at 15:22, Giacomo Furlan <address@hidden> wrote:
>
> Further digging, I think it's about this particular line:
>
> a=ex_fmtp:102 2CIF=1
>
> which is the 15th line of the SDP message. But on column 4 there is no CR LF? Maybe that's what's causing the exception?
>
> I've digged in the source code and, if I'm not wrong, this depends on submodules/belle-sip/src/grammars/belle_sdp.g line 411 (row 22)... but I've got NO idea on how to edit this particular line, as I don't know the ANTLR4 grammar syntax.
>
> I know of other libraries working with this SDP message, so I think they figured out a way (or this may even be a linphone bug? I'm not sure at all)
>
>
> At this point I think I've came to a dead-end, so any help would be appreciated.
>
> Thank you!
>
> Giacomo Furlan
> Software developer
> Software Solutions Designs
>
> 2015-10-06 14:41 GMT+02:00 Giacomo Furlan <address@hidden>:
> Hello again!
>
> The more I read the code, the more I understand how things work in the lib. AFAIK the problem resides in the ending empty line (composed thus only by CR LF characters). Where should I look in order to "fix" this by reading and in case removing empty lines from SDP messages? I know it's a hack and this is why probably you didn't put in the code, but I'm working on a closed-source SIP server and I can't edit it, so I can only try to edit Linphone's behavior.
>
> Thank you very much!
>
> Giacomo Furlan
> Software developer
> Software Solutions Designs
>
> 2015-10-06 10:46 GMT+02:00 Giacomo Furlan <address@hidden>:
> Hello!
>
> I've succeded registering to the service learning from the mini example found in the sources. Now I'm able to connect correctly and I see the server communication.
>
> The next step is to receive calls. I've got two questions:
>
> 1. even if I've enabled OpenH264 (X264) compiling the library, it seems that the library doesn't find the H264 codec when I set it up (message: Could not find encoder for H264). It says encoder, but I don't find any line about the codec. I need to read the stream, not to create it... so am I good?
>
> 2. When I receive a call, it immediately fails on the other side and on mine there is the following log, I think because it fails to parse the SDP message?
>
> 10-06 16:39:12.680 14680-14734/com.be_ssd.sipinterphone I/SIPManager: bellesip_wake_lock_acquire(): Android wake lock acquired [ref=0x1df0029a]
> 10-06 16:39:12.680 14680-14734/com.be_ssd.sipinterphone I/SIPManager: channel [0x66e5f008]: starting recv background task with id=[1df0029a].
> 10-06 16:39:12.680 14680-14734/com.be_ssd.sipinterphone I/SIPManager: channel [0x66e5f008]: received [804] new bytes from [UDP://192.168.0.201:5060]:
> 10-06 16:39:12.680 14680-14734/com.be_ssd.sipinterphone I/SIPManager: INVITE sip:address@hidden:8888 SIP/2.0
> 10-06 16:39:12.680 14680-14734/com.be_ssd.sipinterphone I/SIPManager: Via: SIP/2.0/UDP 192.168.0.201:5060;rport;branch=z9hG4bK2140099773
> 10-06 16:39:12.680 14680-14734/com.be_ssd.sipinterphone I/SIPManager: From: <sip:address@hidden>;tag=1735352582
> 10-06 16:39:12.680 14680-14734/com.be_ssd.sipinterphone I/SIPManager: To: <sip:address@hidden:8888>
> 10-06 16:39:12.680 14680-14734/com.be_ssd.sipinterphone I/SIPManager: Call-ID: 1674329296
> 10-06 16:39:12.680 14680-14734/com.be_ssd.sipinterphone I/SIPManager: CSeq: 20 INVITE
> 10-06 16:39:12.680 14680-14734/com.be_ssd.sipinterphone I/SIPManager: Contact: <sip:address@hidden:5060>
> 10-06 16:39:12.680 14680-14734/com.be_ssd.sipinterphone I/SIPManager: Content-Type: application/sdp
> 10-06 16:39:12.680 14680-14734/com.be_ssd.sipinterphone I/SIPManager: Max-Forwards: 70
> 10-06 16:39:12.680 14680-14734/com.be_ssd.sipinterphone I/SIPManager: User-Agent: DnakeVoip v1.0
> 10-06 16:39:12.680 14680-14734/com.be_ssd.sipinterphone I/SIPManager: Content-Length:   428
> 10-06 16:39:12.680 14680-14734/com.be_ssd.sipinterphone I/SIPManager:
> 10-06 16:39:12.680 14680-14734/com.be_ssd.sipinterphone I/SIPManager: v=0
> 10-06 16:39:12.680 14680-14734/com.be_ssd.sipinterphone I/SIPManager: o=dnake 508646889 508646889 IN IP4 192.168.0.201
> 10-06 16:39:12.680 14680-14734/com.be_ssd.sipinterphone I/SIPManager: s=dnake
> 10-06 16:39:12.680 14680-14734/com.be_ssd.sipinterphone I/SIPManager: c=IN IP4 192.168.0.201
> 10-06 16:39:12.680 14680-14734/com.be_ssd.sipinterphone I/SIPManager: t=0 0
> 10-06 16:39:12.680 14680-14734/com.be_ssd.sipinterphone I/SIPManager: m=audio 6000 RTP/AVP 0 8 101
> 10-06 16:39:12.680 14680-14734/com.be_ssd.sipinterphone I/SIPManager: a=rtpmap:0 PCMU/8000/1
> 10-06 16:39:12.680 14680-14734/com.be_ssd.sipinterphone I/SIPManager: a=rtpmap:8 PCMA/8000/1
> 10-06 16:39:12.680 14680-14734/com.be_ssd.sipinterphone I/SIPManager: a=rtpmap:101 telephone-event/8000/1
> 10-06 16:39:12.680 14680-14734/com.be_ssd.sipinterphone I/SIPManager: a=fmtp:101 0-11
> 10-06 16:39:12.680 14680-14734/com.be_ssd.sipinterphone I/SIPManager: a=sendrecv
> 10-06 16:39:12.680 14680-14734/com.be_ssd.sipinterphone I/SIPManager: m=video 6200 RTP/AVP 102
> 10-06 16:39:12.680 14680-14734/com.be_ssd.sipinterphone I/SIPManager: a=rtpmap:102 H264/90000
> 10-06 16:39:12.680 14680-14734/com.be_ssd.sipinterphone I/SIPManager: a=fmtp:102 profile-level-id=4D0029; packetization-mode=1
> 10-06 16:39:12.680 14680-14734/com.be_ssd.sipinterphone I/SIPManager: a=ex_fmtp:102 2CIF=1
> 10-06 16:39:12.680 14680-14734/com.be_ssd.sipinterphone I/SIPManager: a=ex_multicast:102 ip=238.9.0.201; port=6300
> 10-06 16:39:12.680 14680-14734/com.be_ssd.sipinterphone I/SIPManager: a=sendrecv
> 10-06 16:39:12.680 14680-14734/com.be_ssd.sipinterphone I/SIPManager: channel [0x66e5f008] [376] bytes parsed
> 10-06 16:39:12.680 14680-14734/com.be_ssd.sipinterphone I/SIPManager: channel [0x66e5f008] read [428] bytes of body from [192.168.0.201:5060]
> 10-06 16:39:12.690 14680-14734/com.be_ssd.sipinterphone I/SIPManager: Changing [server] [INVITE] transaction [0x66e11f28], from state [INIT] to [PROCEEDING]
> 10-06 16:39:12.690 14680-14734/com.be_ssd.sipinterphone I/SIPManager: channel [0x66e5f008]: message sent to [UDP://192.168.0.201:5060], size: [211] bytes
> 10-06 16:39:12.690 14680-14734/com.be_ssd.sipinterphone I/SIPManager: SIP/2.0 100 Trying
> 10-06 16:39:12.690 14680-14734/com.be_ssd.sipinterphone I/SIPManager: Via: SIP/2.0/UDP 192.168.0.201:5060;rport;branch=z9hG4bK2140099773
> 10-06 16:39:12.690 14680-14734/com.be_ssd.sipinterphone I/SIPManager: From: <sip:address@hidden>;tag=1735352582
> 10-06 16:39:12.690 14680-14734/com.be_ssd.sipinterphone I/SIPManager: To: sip:address@hidden:8888
> 10-06 16:39:12.690 14680-14734/com.be_ssd.sipinterphone I/SIPManager: Call-ID: 1674329296
> 10-06 16:39:12.690 14680-14734/com.be_ssd.sipinterphone I/SIPManager: CSeq: 20 INVITE
> 10-06 16:39:12.690 14680-14734/com.be_ssd.sipinterphone I/SIPManager:
> 10-06 16:39:12.690 14680-14734/com.be_ssd.sipinterphone I/SIPManager: New server dialog [0x66e457b0] , local tag [], remote tag [1735352582]
> 10-06 16:39:12.690 14680-14734/com.be_ssd.sipinterphone I/SIPManager: op [0x66e42240] : set_or_update_dialog() current=[0x0] new=[0x66e457b0]
> 10-06 16:39:12.690 14680-14734/com.be_ssd.sipinterphone I/SIPManager: new incoming call from [sip:address@hidden] to [sip:address@hidden:8888]
> 10-06 16:39:12.690 14680-14734/com.be_ssd.sipinterphone I/SIPManager: [org.antlr.runtime.MismatchedTokenException] reason [()* loopback of 411:22: ( attribute CR LF )*] at line[15] position[4]
> 10-06 16:39:12.690 14680-14734/com.be_ssd.sipinterphone I/SIPManager: [org.antlr.runtime.MismatchedTokenException] reason [()* loopback of 411:22: ( attribute CR LF )*] at line[15] position[4]
> 10-06 16:39:12.690 14680-14734/com.be_ssd.sipinterphone E/SIPManager: session_description parser error for [v=0
> 10-06 16:39:12.690 14680-14734/com.be_ssd.sipinterphone E/SIPManager: o=dnake 508646889 508646889 IN IP4 192.168.0.201
> 10-06 16:39:12.690 14680-14734/com.be_ssd.sipinterphone E/SIPManager: s=dnake
> 10-06 16:39:12.690 14680-14734/com.be_ssd.sipinterphone E/SIPManager: c=IN IP4 192.168.0.201
> 10-06 16:39:12.690 14680-14734/com.be_ssd.sipinterphone E/SIPManager: t=0 0
> 10-06 16:39:12.690 14680-14734/com.be_ssd.sipinterphone E/SIPManager: m=audio 6000 RTP/AVP 0 8 101
> 10-06 16:39:12.690 14680-14734/com.be_ssd.sipinterphone E/SIPManager: a=rtpmap:0 PCMU/8000/1
> 10-06 16:39:12.690 14680-14734/com.be_ssd.sipinterphone E/SIPManager: a=rtpmap:8 PCMA/8000/1
> 10-06 16:39:12.690 14680-14734/com.be_ssd.sipinterphone E/SIPManager: a=rtpmap:101 telephone-event/8000/1
> 10-06 16:39:12.690 14680-14734/com.be_ssd.sipinterphone E/SIPManager: a=fmtp:101 0-11
> 10-06 16:39:12.690 14680-14734/com.be_ssd.sipinterphone E/SIPManager: a=sendrecv
> 10-06 16:39:12.690 14680-14734/com.be_ssd.sipinterphone E/SIPManager: m=video 6200 RTP/AVP 102
> 10-06 16:39:12.690 14680-14734/com.be_ssd.sipinterphone E/SIPManager: a=rtpmap:102 H264/90000
> 10-06 16:39:12.690 14680-14734/com.be_ssd.sipinterphone E/SIPManager: a=fmtp:102 profile-level-id=4D0029; packetization-mode=1
> 10-06 16:39:12.690 14680-14734/com.be_ssd.sipinterphone E/SIPManager: a=ex_fmtp:102 2CIF=1
> 10-06 16:39:12.690 14680-14734/com.be_ssd.sipinterphone E/SIPManager: a=ex_multicast:102 ip=238.9.0.201; port=6300
> 10-06 16:39:12.690 14680-14734/com.be_ssd.sipinterphone E/SIPManager: a=sendrecv
> 10-06 16:39:12.690 14680-14734/com.be_ssd.sipinterphone E/SIPManager: ]
> 10-06 16:39:12.690 14680-14734/com.be_ssd.sipinterphone E/SIPManager: Failed to parse SDP message.
>
>
> After that message, I've got repeated log messages like the following one:
>
> 10-06 16:39:44.220 14680-14734/com.be_ssd.sipinterphone I/SIPManager: channel [0x66e5f008] [262] bytes parsed
> 10-06 16:39:44.220 14680-14734/com.be_ssd.sipinterphone E/SIPManager: Missing mandatory header [Max-Forwards] for message [ACK]
> 10-06 16:39:44.220 14680-14734/com.be_ssd.sipinterphone I/SIPManager: channel [0x66e5f008]: message sent to [UDP://192.168.0.201:5060], size: [227] bytes
> 10-06 16:39:44.220 14680-14734/com.be_ssd.sipinterphone I/SIPManager: SIP/2.0 400 Bad request
> 10-06 16:39:44.220 14680-14734/com.be_ssd.sipinterphone I/SIPManager: Via: SIP/2.0/UDP 192.168.0.201:5060;rport;branch=z9hG4bK2140099773
> 10-06 16:39:44.220 14680-14734/com.be_ssd.sipinterphone I/SIPManager: From: <sip:address@hidden>;tag=1735352582
> 10-06 16:39:44.220 14680-14734/com.be_ssd.sipinterphone I/SIPManager: To: <sip:address@hidden:8888>;tag=O0JZGYV
> 10-06 16:39:44.220 14680-14734/com.be_ssd.sipinterphone I/SIPManager: Call-ID: 1674329296
> 10-06 16:39:44.220 14680-14734/com.be_ssd.sipinterphone I/SIPManager: CSeq: 20 ACK
>
> Thank you very much for any reply
>
> Giacomo Furlan
> Software developer
> Software Solutions Designs
>
>
> _______________________________________________
> Linphone-developers mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/linphone-developers


_______________________________________________
Linphone-developers mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/linphone-developers





_______________________________________________
Linphone-developers mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/linphone-developers

reply via email to
[Prev in Thread] Current Thread [Next in Thread]