Showing errors in kamailio syslogs for Register messages - sip

I am getting the below Error messages in syslog. Can anyone tell me why these two methods getting failed. Is there anything I am missing to configure in SIP phone.
ERROR: {1 2 REGISTER 619499693} [core/parser/parse_methods.c:456]: parse_methods(): Invalid method
ERROR: {1 2 REGISTER 619499693} [core/parser/parse_allow.c:65]: parse_allow_header(): bad allow body header
The captured register message below:
REGISTER sip:77.10.86.8;user=phone SIP/2.0
Via: SIP/2.0/UDP 77.10.86.9:5060;rport;branch=z9hG4bK1290987256
From: "USER1" sip:90000001#77.10.86.8;user=phone;tag=822848271
To: "USER1" sip:90000001#77.10.86.8;user=phone
Call-ID: 619499693
CSeq: 1 REGISTER
Contact: "USER1" sip:90000001#77.10.86.9:5060
Allow: INVITE, ACK, OPTIONS, BYE, CANCEL, UPDATE, INFO, SUBSCRIBER, NOTIFY, MESSAGE, PRACK, REFER
Max-Forwards: 70
User-Agent: eXosip/3.6.0
Expires: 3600
Supported: eventlist, replaces, tdialog, timer, 100rel
Allow-Events: dialog, message-summary, refer, reg, ua-profile
Content-Length: 0

The from and to headers do not comply with rfc3261 syntax:
From: "USER1" sip:90000001#77.10.86.8;user=phone;tag=822848271
To: "USER1" sip:90000001#77.10.86.8;user=phone
When a display name is used, the URI needs to be enclosed between <>
From: "USER1" <sip:90000001#77.10.86.8;user=phone>;tag=822848271
To: "USER1" <sip:90000001#77.10.86.8;user=phone>
You will find more details in rfc3261.
EDIT:
I was too fast in answering. The error mention a wrong value in Allow header. SUBSCRIBER (typo for SUBSCRIBE) is not defined by any specification. However, in rfc3261, such values (unknown) are allowed by the specification, and such header is correct from a syntax perspective.

Related

Process INVITES when recording is enabled on both parties phones in Cisco CUCM

I am using jain-sip to implement a sip server to process call events and then record the calls in Cisco CUCM. It works fine when a call is made from a recording-enabled phone to a recording-disabled phone or vice versa. I receive two INVITES one for each far-end and near-end phone.
But when a call is made between two phones where recording is enabled on both phones (think internal call), I receive four invites and there is no way of differentiating between far-end and near-end and no way of knowing which invites to process and which to ignore. Both phones send two invites, one for itself and one for the other phone. When call is ended, four BYEs are sent.
What is the proper way of handling this situation?
below are the four invites;
INVITE sip:88888#192.168.1.x.x:5060 SIP/2.0
Via: SIP/2.0/TCP 192.168..x.x:5060;branch=z9hG4bK2095e06f3b8;rport=58747
From: <sip:2400#192.168..x.x;x-nearend;x-refci=27425142;x-nearendclusterid=BR-Cluster2;x-nearenddevice=SEPD0C282D15AAF;x-nearendaddr=2400;x-farendrefci=27425141;x-farendclusterid=BR-Cluster2;x-farenddevice=sikander1;x-farendaddr=2701>;tag=519~00d3be95-408b-41c6-90cf-01ef66258892-27425149
To: <sip:88888#192.168.1.124>
Date: Mon, 09 Nov 2020 07:13:13 GMT
Call-ID: 6649000-fa81ec09-1f6-3001a8c0#192.168..x.x
Supported: timer,resource-priority,replaces,X-cisco-srtp-fallback,Geolocation
Min-SE: 120
User-Agent: Cisco-CUCM11.5
Allow: INVITE,OPTIONS,INFO,BYE,CANCEL,ACK,PRACK,UPDATE,REFER,SUBSCRIBE,NOTIFY
CSeq: 101 INVITE
Expires: 180
Allow-Events: presence,kpml
Call-Info: <sip:192.168..x.x:5060>;method="NOTIFY;Event=telephone-event;Duration=500"
Session-ID: 00000000000000000000000000000000;remote=00000000000000000000000000000000
Cisco-Guid: 0107253760-0000065536-0000000011-0805415104
Session-Expires: 120
P-Asserted-Identity: <sip:2400#192.168..x.x>
Remote-Party-ID: <sip:2400#192.168..x.x>;party=calling;screen=yes;privacy=off
Contact: <sip:2400#192.168..x.x:5060;transport=tcp>;isFocus
Max-Forwards: 70
Content-Length: 0
-----------------------------------------
INVITE sip:88888#192.168.x.x:5060 SIP/2.0
Via: SIP/2.0/TCP 192.168.x.x:5060;branch=z9hG4bK20a2071bec;rport=58747
From: <sip:2701#192.168.x.x;x-nearend;x-refci=27425141;x-nearendclusterid=BR-Cluster2;x-nearenddevice=sikander1;x-nearendaddr=2701;x-farendrefci=27425142;x-farendclusterid=BR-Cluster2;x-farenddevice=SEPD0C282D15AAF;x-farendaddr=2400>;tag=520~00d3be95-408b-41c6-90cf-01ef66258892-27425150
To: <sip:88888#192.168..x.x>
Date: Mon, 09 Nov 2020 07:13:13 GMT
Call-ID: 6649000-fa81ec09-1f7-3001a8c0#192.168..x.x
Supported: timer,resource-priority,replaces,X-cisco-srtp-fallback,Geolocation
Min-SE: 120
User-Agent: Cisco-CUCM11.5
Allow: INVITE,OPTIONS,INFO,BYE,CANCEL,ACK,PRACK,UPDATE,REFER,SUBSCRIBE,NOTIFY
CSeq: 101 INVITE
Expires: 180
Allow-Events: presence,kpml
Call-Info: <sip:192.168..x.x:5060>;method="NOTIFY;Event=telephone-event;Duration=500"
Session-ID: 00000000000000000000000000000000;remote=00000000000000000000000000000000
Cisco-Guid: 0107253760-0000065536-0000000012-0805415104
Session-Expires: 120
P-Asserted-Identity: <sip:2701#192.168..x.x>
Remote-Party-ID: <sip:2701#192.168.1.x.x>;party=calling;screen=yes;privacy=off
Contact: <sip:2701#192.168.x.x:5060;transport=tcp>;isFocus
Max-Forwards: 70
Content-Length: 0
-------------------------
INVITE sip:88888#192.168..x.x:5060 SIP/2.0
Via: SIP/2.0/TCP 192.168..x.x:5060;branch=z9hG4bK20b5eb383e9;rport=58747
From: <sip:2400#192.168..x.x;x-farend;x-refci=27425142;x-nearendclusterid=BR-Cluster2;x-nearenddevice=SEPD0C282D15AAF;x-nearendaddr=2400;x-farendrefci=27425141;x-farendclusterid=BR-Cluster2;x-farenddevice=sikander1;x-farendaddr=2701>;tag=521~00d3be95-408b-41c6-90cf-01ef66258892-27425155
To: <sip:88888#192.168..x.x>
Date: Mon, 09 Nov 2020 07:13:13 GMT
Call-ID: 6649000-fa81ec09-1f8-3001a8c0#192.168..x.x
Supported: timer,resource-priority,replaces,X-cisco-srtp-fallback,Geolocation
Min-SE: 120
User-Agent: Cisco-CUCM11.5
Allow: INVITE,OPTIONS,INFO,BYE,CANCEL,ACK,PRACK,UPDATE,REFER,SUBSCRIBE,NOTIFY
CSeq: 101 INVITE
Expires: 180
Allow-Events: presence,kpml
Call-Info: <sip:192.168..x.x:5060>;method="NOTIFY;Event=telephone-event;Duration=500"
Session-ID: 00000000000000000000000000000000;remote=00000000000000000000000000000000
Cisco-Guid: 0107253760-0000065536-0000000013-0805415104
Session-Expires: 120
P-Asserted-Identity: <sip:2400#192.168.x.x>
Remote-Party-ID: <sip:2400#192.168..x.x>;party=calling;screen=yes;privacy=off
Contact: <sip:2400#192.168..x.x:5060;transport=tcp>;isFocus
Max-Forwards: 70
Content-Length: 0
-------------------------
INVITE sip:88888#192.168.1.124:5060 SIP/2.0
Via: SIP/2.0/TCP 192.168..x.x:5060;branch=z9hG4bK20c2f880eb2;rport=58747
From: <sip:2701#192.168..x.x;x-farend;x-refci=27425141;x-nearendclusterid=BR-Cluster2;x-nearenddevice=sikander1;x-nearendaddr=2701;x-farendrefci=27425142;x-farendclusterid=BR-Cluster2;x-farenddevice=SEPD0C282D15AAF;x-farendaddr=2400>;tag=522~00d3be95-408b-41c6-90cf-01ef66258892-27425156
To: <sip:88888#192.168.1.124>
Date: Mon, 09 Nov 2020 07:13:13 GMT
Call-ID: 6649000-fa81ec09-1f9-3001a8c0#192.168..x.x
Supported: timer,resource-priority,replaces,X-cisco-srtp-fallback,Geolocation
Min-SE: 120
User-Agent: Cisco-CUCM11.5
Allow: INVITE,OPTIONS,INFO,BYE,CANCEL,ACK,PRACK,UPDATE,REFER,SUBSCRIBE,NOTIFY
CSeq: 101 INVITE
Expires: 180
Allow-Events: presence,kpml
Call-Info: <sip:192.168..x.x:5060>;method="NOTIFY;Event=telephone-event;Duration=500"
Session-ID: 00000000000000000000000000000000;remote=00000000000000000000000000000000
Cisco-Guid: 0107253760-0000065536-0000000014-0805415104
Session-Expires: 120
P-Asserted-Identity: <sip:2701#192.168..x.x>
Remote-Party-ID: <sip:2701#192.168..x.x>;party=calling;screen=yes;privacy=off
Contact: <sip:2701#192.168..x.x:5060;transport=tcp>;isFocus
Max-Forwards: 70
Content-Length: 0
I guess in general the idea would be to potentially record all 4 call legs - i.e. both sides of the 'same' call. An example might be software that analyzes the voice quality experienced by each party when both are recorded, in case one experiences RTP flow issues or other anomalies. Codec differences or transcoding may cause one 'version' of the same 2-party call to sound better/worse (or have larger storage requirements).
If you don't care about the RTP data at that level, you may need to check the x-refci and other From: fields, so you can 'de-dupe' them during or after the fact...

Is user part in sip 'Contact' header madatory?

I have a SIP Server which is registering to a trunk. So, SIP Server sends a REGISTER message to the trunk. But the trunk device sends a "406 Not Acceptable" error message. I have been told that this error is because there is no user part in 'Contact' header. However, as per RFC, Contact header on its own is not mandatory to be in a REGISTER request.
Could you please help to confirm if my understanding is right and advise accordingly?
REGISTER sip:10.5.5.1 SIP/2.0
From: sip:70999#10.5.5.1;tag=8CD78147-5BDB-40C1-87F6-64A6905F1A6D-9
To: <sip:70999#10.5.5.1>
Call-ID: FCC64207-4F2A-4622-AF85-B77BBE3C7796-9#10.5.5.2
CSeq: 1 REGISTER
Content-Length: 0
Via: SIP/2.0/UDP 10.5.5.2:5060;branch=z9hG4bKA761AE66-C376-4895-BBF7-51CF2C675C52-9
**Contact: <sip:10.5.5.2:5060>**
Expires: 600
SIP/2.0 406 Not Acceptable
Via: SIP/2.0/UDP 10.5.5.2:5060;branch=z9hG4bKA761AE66-C376-4895-BBF7-51CF2C675C52-9
From: <sip:70999#10.5.5.1>;tag=8CD78147-5BDB-40C1-87F6-64A6905F1A6D-9
To: <sip:70999#10.5.5.1>;tag=10a8faa5
Call-ID: FCC64207-4F2A-4622-AF85-B77BBE3C7796-9#10.5.5.2
CSeq: 1 REGISTER
User-Agent: XXX XXX XXX
Allow: INVITE, ACK, REGISTER, BYE, OPTIONS, INFO, CANCEL, REFER, NOTIFY, SUBSCRIBE, PRACK, UPDATE
Content-Length: 0
10.5.5.2 is my SIP Server and 10.5.5.1 is the Trunk device
Thank you.
You are correct. For all address of records, including any in a Contact header, the user portion is optional.
For REGISTER requests in particular see 10.2.1 Adding Bindings which states:
The Contact header field values of the request typically consist of
SIP or SIPS URIs that identify particular SIP endpoints (for example,
"sip:carol#cube2214a.chicago.com"), but they MAY use any URI scheme.
A SIP UA can choose to register telephone numbers (with the tel URL,
RFC 2806 [9]) or email addresses (with a mailto URL, RFC 2368 [32])
as Contacts for an address-of-record, for example.
For the case where the Contact header contains a SIP URI the rules are specified as shown below. The [userinfo] portion which contains the "user part" you're referring to is optional.
SIP-URI = "sip:" [ userinfo ] hostport
uri-parameters [ headers ]
SIPS-URI = "sips:" [ userinfo ] hostport
uri-parameters [ headers ]
userinfo = ( user / telephone-subscriber ) [ ":" password ] "#"
Despite the fact that you are correct most SIP servers do implement additional business rules. Some Registrars don't accept request with a private IP address in the Contact URI etc.

Cannot send RTP by SIPp tool

I am trying to replay an captured pcap file with sipp as follows:
In Sending.xml
...
<recv response="200" rrs="true">
<action>
<ereg regexp="(.*)" search_in="hdr" header="To:" assign_to="TO_REQUEST"/>
</action>
</recv>
<send >
<![CDATA[
ACK [next_url] SIP/2.0
To: [$TO_REQUEST]
From: [$FROM_REQUEST]
Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]
Call-ID: [call_id]
CSeq: [last_cseq_number] ACK
Contact: <sip:[local_ip]:[local_port]>
[routes]
Max-Forwards: 70
Subject: Performance Test
Content-Length: 0
]]>
</send>
<nop>
<action>
<exec play_pcap_audio="pcap/g711a.pcap"/>
</action>
</nop>
...
However, I always get the same error:
extract_rtp_remote_addr: no IP address found in SDP message body.
I tried to test with other *.pcap and *.raw files and edit my script but I still cannot.
When I only send the signal not RTP, the call is successful.
Anyone can help me send RTP by SIPp?
Thanks in advance!
I recall I had similar issues with that at some point due to my .pcap not being very 'clean'.
Are you sure the pcap contains just the RTP packets and nothing else?
For a working example of pcap played by sipp, you can check webrtc-test project and more specifically: .pcap and relevant sipp xml
Also notice that sipp usually only plays just one direction of the RTP media, so it's best if you have media flowing in both directions to make sure.
Hope this helps.
Best regards,
Antonis Tsakiridis
This may have to do with the SDP in your INVITE. extract_rtp_remote_addr will be looking for an IP address to send the RTP to.
Check your INVITE in the XML has the correct IP address in the c line.

i want to implement sip protocol on microcontroller i.e. using embedded c ,but i want to parse sip packets using perl or tcl

a typical sip packet looks like this
INVITE sip:bob#biloxi.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Bob <sip:bob#biloxi.com>
From: Alice <sip:alice#atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710#pc33.atlanta.com
CSeq: 314159 INVITE
Contact: <sip:alice#pc33.atlanta.com>
Content-Type: application/sdp
Content-Length: 142
so is it possible to embedd perl or tcl parser in c
I would use a packet sniffer in C. Then identify SIP protocol based on data, push it somewhere and parse it with Perl/TCL from there. Example:
http://www.tcpdump.org/sniffex.c, or you can build packet sniffer from Perl/TCL itself, very easy task just some considerations when handling TCP/UDP fragmentation

Record route ignoted while sending ack

I have a strange problem where pjsip ignores the record route info while sending the ack. Below are the sip message flow from the logs:
INVITE sip:+110#xxx.com;transport=tls SIP/2.0
Via: SIP/2.0/TLS ipv4.addr:38890;rport;branch=z9hG4bKPjdYP6TZrj4w7v8kicC3cBgABBNb47QHH2;alias
Max-Forwards: 70
From: "+558" <sip:+558#xxx.com>;tag=qfc3TEYcpfIBQHVXMOmh.7pyvqgmVdMh
To: sip:+110#xxx.com
Contact: "+558" <sip:+558#xxx.com>
Call-ID: 7FdLGhQ1L5BjAQsUrCPEOB3WbXipRfs1
CSeq: 18162 INVITE
Route: <sip:xxx.com:5061;transport=tls;lr>
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
Supported: replaces, 100rel, timer, norefersub
User-Agent: SecuVOICE BB10 CSE 2.14.0.1 on Z10 10.3.1.2243
Authorization: Digest xxxx
Content-Type: application/x-x509-user-cert
Content-Length:
SIP/2.0 200 OK
Max-Forwards: 10
Via: SIP/2.0/TLS ipv4.addr:38890;rport=38890;received=ipv4.addr;branch=z9hG4bKPjdYP6TZrj4w7v8kicC3cBgABBNb47QHH2;alias
Record-Route:<sip:xxx.com:5061;transport=tls;lr;ftag=qfc3TEYcpfIBQHVXMOmh.7pyvqgmVdMh;cookie_=e43.052768f7>
Call-ID: 7FdLGhQ1L5BjAQsUrCPEOB3WbXipRfs1
From: "+558" <sip:+558#xxx.com>;tag=qfc3TEYcpfIBQHVXMOmh.7pyvqgmVdMh
To: <sip:+110#xxx.com>;tag=RuDb.RX-9YD0V.BKh0rpj61-SK-ORE5B
CSeq: 18162 INVITE
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
Contact: "+110" <sip:+110#ipv4.addr:25365>
Supported: replaces, 100rel, timer, norefersub
Content-Type: multipart/mixed;boundary=SBC1hJLGTAfp3t2j3HYWIvvgUBsC1RpJ
Content-Length: 27
ACK sip:+110#ipv4.addr:25365 SIP/2.0
"+110" <sip:+110#ipv4.addr:25365>
Via: SIP/2.0/TLS ipv4.addr:38890;rport;branch=z9hG4bKPjkp-dUZmmgpXNWrZHe2ykqvrr9CgRvlm2;alias
Max-Forwards: 70
From: "+558" <sip:+558#xxx.com>;tag=qfc3TEYcpfIBQHVXMOmh.7pyvqgmVdMh
To: sip:+110#xxx.com;tag=RuDb.RX-9YD0V.BKh0rpj61-SK-ORE5B
Call-ID: 7FdLGhQ1L5BjAQsUrCPEOB3WbXipRfs1
CSeq: 18162 ACK
Route: <sip:xxx.com:5061;transport=tls;lr;ftag=qfc3TEYcpfIBQHVXMOmh.7pyvqgmVdMh;cookie_=e43.052768f7>
Content-Type: application/sdp
Content-Length: 709
Looking at the record route from 200 OK, I expected the ACK to look like
ACK sip:+110#ipv4.addr:25365;transport=tls;lr SIP/2.0
Why pjsip is ignoring the transport uri parameter?
Received Record-Route are copied as Route in a new outgoing request within the dialog.
The exception is if the Record-Route URI does not carry a ";lr" parameter. This is the backward compatible behaviour with RFC 2543
The Request URI of the outgoing request is set to the received Contact header.
See RFC 3261 Section 12.2.1.1
The UAC uses the remote target and route set to build the
Request-URI and Route header field of the request.
If the route set is empty, the UAC MUST place the remote target URI
into the Request-URI. The UAC MUST NOT add a Route header field to
the request.
If the route set is not empty, and the first URI in the route set
contains the lr parameter (see Section 19.1.1), the UAC MUST place
the remote target URI into the Request-URI and MUST include a Route
header field containing the route set values in order, including all
parameters.
If the route set is not empty, and its first URI does not contain
the lr parameter, the UAC MUST place the first URI from the route
set into the Request-URI, stripping any parameters that are not
allowed in a Request-URI. The UAC MUST add a Route header field
containing the remainder of the route set values in order,
including all parameters. The UAC MUST then place the remote
target URI into the Route header field as the last value.
The route set is either pre-configured, or learned through the Record-Route.
Target URI is updated when receiving a Contact header from the other party.