[Kamailio-Users] AudioCodes + Kamailio : Problem in SIP Message Headers

Discussion:

Samuel Muller

2008-12-04 11:41:44 UTC

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-***@public.gmane.org: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-***@public.gmane.org
<sip%3A0123451010-***@public.gmane.org>>;tag=71078b346a20fb3eo0

To: <sip:0323719001-***@public.gmane.org <sip%3A0323719001-***@public.gmane.org>>
Call-ID: 944d8aec-27503ee6-Q0ErXNX1RuaWc+***@public.gmane.org
CSeq: 102 INVITE
Max-Forwards: 49
Contact: "Sam" <sip:0123451010-***@public.gmane.org: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>;party=caller;privacy=none;screen=yes
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.

Raj Jain

2008-12-04 12:28:51 UTC

Permalink

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

Post by Samuel Muller
Hello all,
I recently add a classical Audiocodes Mediant 2000 with 2x 8E1, the purpose
is to have several interconnections with PSTN.
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.
12:30:26]
( sip_stack)(44733 ) !! [ERROR] AcSIPParser: Parse Error. Unexpected symbol
'0' in scheme. ALPHA expected
** audiocodes debug **
4d:12h:30m:26s ( lgr_flow)(44730 ) ---- Incoming SIP Message from
77.246.81.132:5060 ----
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
CSeq: 102 INVITE
Max-Forwards: 49
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>;party=caller;privacy=none;screen=yes
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
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
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users

Klaus Darilion

2008-12-04 12:35:11 UTC

Permalink

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

Post by Raj Jain
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

_______________________________________________
Users mailing list
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users

Samuel Muller

2008-12-04 15:21:18 UTC

Permalink

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-***@public.gmane.org:5062;transport=udp SIP/2.0
Record-Route: <sip:77.246.81.132;lr=on;ftag=a4143abfbda0611ao0;nat=yes>
Via: 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

;tag=a4143abfbda0611ao0

To: <sip:0663128505-***@public.gmane.org <sip%3A0663128505-***@public.gmane.org>>
Call-ID: ced89363-47d540c6-Q0ErXNX1RuaWc+***@public.gmane.org
CSeq: 102 INVITE
Max-Forwards: 49
Contact: "Sam" <sip:0123451010-***@public.gmane.org: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
<sip:0123451010-***@public.gmane.org<sip%3A0123451010-***@public.gmane.org>
Remote-Party-ID: 0123451010

;party=caller;privacy=none;screen=yes

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-Q0ErXNX1RuaWc+***@public.gmane.org)
[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-***@public.gmane.org:5062;transport=udp SIP/2.0
Via: SIP/2.0/UDP 77.246.81.132;branch=z9hG4bK89df.da4cd5e2.0

;tag=a4143abfbda0611ao0
;tag=1c249703390

CSeq: 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-Q0ErXNX1RuaWc+***@public.gmane.org) [Time: 15:33:43]

Again, thanks guys :)

.Sam.

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
It seems that the P-Asserted-Identity header is not correctly

Post by Raj Jain
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

Post by Samuel Muller
;tag=71078b346a20fb3eo0

CSeq: 102 INVITE
Max-Forwards: 49
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>;party=caller;privacy=none;screen=yes
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
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
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users

_______________________________________________
Users mailing list
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users

--
Samuel MULLER
Ingénieur Reseaux & Telecom
720 DEGRES
+33 (0)663 128 505
sml-***@public.gmane.org

Iñaki Baz Castillo

2008-12-04 15:28:00 UTC

Permalink

Post by Samuel Muller
append_hf("P-Asserted-Identity: $avp(s:caller_cli)
append_hf("Remote-Party-ID: $avp(s:caller_cli)
}
Do you have a better solution to have the best rpid and pai coding way ?

It's ok now.

Post by Samuel Muller
And, is the P-Preferred-Identity really necessary for PSTN ?

It depends on the gateway configuration, but basically PPI shouldn't
be used when sending the request to a gateway (they usually expect
RPID or PAI).

--
Iñaki Baz Castillo
<***@aliax.net>

cong

2012-09-26 06:55:02 UTC

Permalink

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