It seems that the P-Asserted-Identity header is not correctly formatted in the INVITE. It must be a sip, sips, or tel URI. This would be something that your proxy is adding to the INVITE. Here is a quote from section RFC 3325. 9.1 The P-Asserted-Identity Header The P-Asserted-Identity header field is used among trusted SIP entities (typically intermediaries) to carry the identity of the user sending a SIP message as it was verified by authentication. PAssertedID = "P-Asserted-Identity" HCOLON PAssertedID-value *(COMMA PAssertedID-value) PAssertedID-value = name-addr / addr-spec A P-Asserted-Identity header field value MUST consist of exactly one name-addr or addr-spec. There may be one or two P-Asserted-Identity values. If there is one value, it MUST be a sip, sips, or tel URI. -- Raj Jain On Thu, Dec 4, 2008 at 6:41 AM, Samuel Muller <sml(a)720.fr> wrote:

Hello guys, many thanks, you were right :) I changed the PAI and the RPID stuff and it works ... -- KAMAILIO -- # flag 9 = clir if (is_avp_set("$avp(s:caller_cli)/s") && !isflagset(9)) { if (is_present_hf("P-Asserted-Identity")) { remove_hf("P-Asserted-Identity"); } if (is_present_hf("Remote-Party-ID")) { remove_hf("Remote-Party-ID"); } append_hf("P-Asserted-Identity: $avp(s:caller_cli) <sip:$avp(s:caller_cli)@$fd>\r\n"); append_hf("Remote-Party-ID: $avp(s:caller_cli) <sip:$avp(s:caller_cli)@$si>;party=caller;privacy=none;screen=yes\r\n"); } Do you have a better solution to have the best rpid and pai coding way ? And, is the P-Preferred-Identity really necessary for PSTN ? log in the gateway : -- AUDIOCODES -- 4d:15h:33m:43s ( lgr_flow)(51994 ) ---- Incoming SIP Message from 77.246.81.132:5060 ---- INVITE sip:0663128505@77.246.81.136:5062;transport=udp SIP/2.0 Record-Route: <sip:77.246.81.132;lr=on;ftag=a4143abfbda0611ao0;nat=yesVia: SIP/2.0/UDP 77.246.81.132;branch=z9hG4bK89df.da4cd5e2.0 Via: SIP/2.0/UDP 192.168.0.113:5060;rport=15170;received=77.246.81.162 ;branch=z9hG4bK-8a13206a From: "Sam" <sip:0123451010@sip.720.fr &lt;sip%3A0123451010(a)sip.720.frTo: <sip:0663128505@sip.720.fr &lt;sip%3A0663128505(a)sip.720.fr&gt;Call-ID: ced89363-47d540c6(a)192.168.0.113 CSeq: 102 INVITE Max-Forwards: 49 Contact: "Sam" <sip:0123451010@77.246.81.162:15170Expires: 240 User-Agent: Linksys/SPA941-5.1.8 Content-Length: 281 Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, REFER Supported: 100rel, replaces Content-Type: application/sdp P-Asserted-Identity: 0123451010 <sip:0123451010@sip.720.fr<sip%3A0123451010@sip.720.frRemote-Party-ID: 0123451010 <sip:0123451010@77.246.81.162<sip%3A0123451010@77.246.81.162 v=0 o=- 28033614 28033614 IN IP4 192.168.0.113 s=- c=IN IP4 77.246.81.133 t=0 0 m=audio 35056 RTP/AVP 18 0 8 101 a=rtpmap:18 G729a/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:30 a=sendrecv a=nortpproxy:yes [Time: 15:33:43] ( lgr_flow)(51996 ) | | new GetNewSIPCall created - #357 [Time: 15:33:43] ( sip_stack)(51997 ) new AcSIPCallAPI created - #285 [Time: 15:33:43] ( lgr_stk_mngr)(51998 ) Resource StackSession <#285> Allocated [Time: 15:33:43] ( lgr_flow)(51999 ) | |(SIPTU#357)INVITE State:Idle() [Time: 15:33:43] ( sip_stack)(52000 ) SIPCall(#357) changes state from Idle to Invited [Time: 15:33:43] ( lgr_flow)(52001 ) | | | #285:SIP_SETUP_EV(ced89363-47d540c6@192.168.0.113) [Time: 15:33:43] ( lgr_callf)(52002 ) new Call created - #285 [Time: 15:33:43] ( lgr_stk_ses)(52003 ) SIPStackSession::HandleStackSetupEV - NEWCALL: SrcPN=0 [Time: 15:33:43] ( lgr_stk_ses)(52004 ) <SESSION #285> SendToCall - event: NEW_CALL_EV m_Call = 108260848 [Time: 15:33:43] ( lgr_flow)(52033 ) ---- Incoming SIP Message from 77.246.81.132:5060 ---- [Time: 15:33:43] ACK sip:0663128505@77.246.81.136:5062;transport=udp SIP/2.0 Via: SIP/2.0/UDP 77.246.81.132;branch=z9hG4bK89df.da4cd5e2.0 From: "Sam" <sip:0123451010@sip.720.fr &lt;sip%3A0123451010(a)sip.720.frCall-ID: ced89363-47d540c6(a)192.168.0.113 To: <sip:0663128505@sip.720.fr &lt;sip%3A0663128505(a)sip.720.frCSeq: 102 ACK Max-Forwards: 70 User-Agent: kamailio 1.4.2 - 720 DEGRES Content-Length: 0 ( sip_stack)(52035 ) UdpRtxMngr::Remove 404 Response 102 INVITE [Time: 15:33:43] ( lgr_flow)(52036 ) | |(SIPTU#357)ACK State:Disconnected( ced89363-47d540c6(a)192.168.0.113) [Time: 15:33:43] Again, thanks guys :) .Sam. On Thu, Dec 4, 2008 at 1:35 PM, Klaus Darilion &lt;klaus.mailinglists(a)pernau.at > Further, the log message does not have an empty line between SIP headers > and the body. Either you have forgotten to add \r\n when adding the header > or this is just not diplays correctly in the logfile. > klaus > Raj Jain schrieb: > It seems that the P-Asserted-Identity header is not correctly >> formatted in the INVITE. It must be a sip, sips, or tel URI. This >> would be something that your proxy is adding to the INVITE. Here is a >> quote from section RFC 3325. >>>> 9.1 The P-Asserted-Identity Header >>> The P-Asserted-Identity header field is used among trusted SIP >> entities (typically intermediaries) to carry the identity of the user >> sending a SIP message as it was verified by authentication. >>> PAssertedID = "P-Asserted-Identity" HCOLON PAssertedID-value >> *(COMMA PAssertedID-value) >> PAssertedID-value = name-addr / addr-spec >>> A P-Asserted-Identity header field value MUST consist of exactly one >> name-addr or addr-spec. There may be one or two P-Asserted-Identity >> values. If there is one value, it MUST be a sip, sips, or tel URI. >>> -- >> Raj Jain >>> On Thu, Dec 4, 2008 at 6:41 AM, Samuel Muller &lt;sml(a)720.fr>>>> Hello all, >>>>> I recently add a classical Audiocodes Mediant 2000 with 2x 8E1, the >>> purpose >>> is to have several interconnections with PSTN. >>>>> I configured it like this : >>>>> Audiocodes registers as a gateway to the Kamailio, using a dedicated port >>> (5062). >>> Registration seems to be OK, and the pstn gw uses OPTIONS method to ping >>> the >>> proxy. >>> I can attack the Audiocodes with a SIP phone behind Kamailio, no pbm. >>>>> But the audiocodes returns some errors about SIP headers sent by Kamailio >>> : >>>>> ( sip_stack)(44732 ) AcSIPParser: Problem in SIP Message Headers [Time: >>> 12:30:26] >>> ( sip_stack)(44733 ) !! [ERROR] AcSIPParser: Parse Error. Unexpected >>> symbol >>> '0' in scheme. ALPHA expected >>>>> Here you have the example of an INVITE from a SIP phone to the PSTN : >>>>> ** audiocodes debug ** >>>>> 4d:12h:30m:26s ( lgr_flow)(44730 ) ---- Incoming SIP Message from >>> 77.246.81.132:5060 ---- >>>>> INVITE sip:0323719001@77.246.81.136:5062;transport=udp SIP/2.0 >>> Record-Route: <sip:77.246.81.132;lr=on;ftag=71078b346a20fb3eo0;nat=yes>>> Via: SIP/2.0/UDP 77.246.81.132;branch=z9hG4bKdace.1ab1d59.0 >>> Via: SIP/2.0/UDP >>> 192.168.0.113:5060;rport=15170;received=77.246.81.162 >>> ;branch=z9hG4bK-b432f96 >>> From: "Sam" <sip:0123451010@sip.720.fr &lt;sip%3A0123451010(a)sip.720.fr>>> >;tag=71078b346a20fb3eo0 >>> To: <sip:0323719001@sip.720.fr &lt;sip%3A0323719001(a)sip.720.fr&gt;>>> Call-ID: 944d8aec-27503ee6(a)192.168.0.113 >>> CSeq: 102 INVITE >>> Max-Forwards: 49 >>> Contact: "Sam" <sip:0123451010@77.246.81.162:15170>>> Expires: 240 >>> User-Agent: Linksys/SPA941-5.1.8 >>> Content-Length: 281 >>> Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, REFER >>> Supported: 100rel, replaces >>> Content-Type: application/sdp >>> P-Asserted-Identity: <0123451010>>> Remote-Party-ID: <0123451010>>> v=0 >>> o=- 26933860 26933860 IN IP4 192.168.0.113 >>> s=- >>> c=IN IP4 77.246.81.133 >>> t=0 0 >>> m=audio 35038 RTP/AVP 18 0 8 101 >>> a=rtpmap:18 G729a/8000 >>> a=rtpmap:0 PCMU/8000 >>> a=rtpmap:8 PCMA/8000 >>> a=rtpmap:101 telephone-event/8000 >>> a=fmtp:101 0-15 >>> a=ptime:30 >>> a=sendrecv >>> a=nortpproxy:yes >>>>> ( sip_stack)(44732 ) AcSIPParser: Problem in SIP Message Headers [Time: >>> 12:30:26] >>> ( sip_stack)(44733 ) !! [ERROR] AcSIPParser: Parse Error. Unexpected >>> symbol >>> '0' in scheme. ALPHA expected >>> ( sip_stack)(44734 ) !! [ERROR] Message type: INVITE [Time: 12:30:26] >>> ( sip_stack)(44735 ) !! [ERROR] Source header: [Time: 12:30:26] >>> ( sip_stack)(44736 ) !! [ERROR] Line: 17. Column: 23 [Time: 12:30:26] >>>>>>> The outgoing INVITE from Kamailio is exactly the same received by the >>> AudioCodes. >>> When I searched over Google, I just found 2 answers about Asterisk / >>> Audiocodes unsolved problem, but no more informations. >>>>> I supposed that the problem is as indicated : " s=- " where source is >>> empty >>> in place of "NULL" / "0" or something like this ... >>> Someone can confirm or already met the problem ? >>>>> Many thanks all :) >>>>> .Sam. >>>>>>>>>>>>> _______________________________________________ >>> Users mailing list >>> Users(a)lists.kamailio.org >>> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users >>>>>>>> _______________________________________________ >> Users mailing list >> Users(a)lists.kamailio.org >> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users > -- Samuel MULLER Ingénieur Reseaux & Telecom 720 DEGRES +33 (0)663 128 505 sml(a)720.fr

Samuel Muller-2 wrote: -- View this message in context: http://old.nabble.com/AudioCodes-%2B-Kamailio-%3A-Problem-in-SIP-Message-He… Sent from the OpenSER Users Mailing List mailing list archive at Nabble.com.