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
Related
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.
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.
I am trying to send the DTMF digits through sipp to IVR application
This is my sip xml and works good except action part...
Call is successful but DTMF digit 1 is not received. It is showing that digit received as null..not getting the actual problem is there any configuration for this pcap ?or anytthing problem with the script?
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE scenario SYSTEM "sipp.dtd">
<scenario name="UAC with media">
<send retrans="500">
<![CDATA[
INVITE sip:[field0]#[remote_ip]:[remote_port] SIP/2.0
Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]
From: sipp <sip:[field1]#[local_ip]:[local_port]>;tag=[call_number]
To: sut <sip:[field0]#[remote_ip]:[remote_port]>
Call-ID: [call_id]
CSeq: 1 INVITE
Contact: sip:[field1]#[local_ip]:[local_port]
Max-Forwards: 70
Subject: Performance Test
Content-Type: application/sdp
Content-Length: [len]
v=0
o=user1 53655765 2353687637 IN IP[local_ip_type] [local_ip]
s=-
c=IN IP[local_ip_type] [local_port]
t=0 0
m=audio [auto_media_port] RTP/AVP 96 0 9 8 101 13
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-1
]]>
</send>
<recv response="100" optional="true">
</recv>
<recv response="183" optional="true">
</recv>
<recv response="200">
</recv>
<![CDATA[
ACK sip:[field0]#[remote_ip]:[remote_port] SIP/2.0
Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]
From: sipp <sip:[field1]#[local_ip]:[local_port]>;tag=[call_number]
To: sut <sip:[field0]#[remote_ip]:[remote_port]>[peer_tag_param]
Call-ID: [call_id]
CSeq: 1 ACK
Contact: sip:sipp#[local_ip]:[local_port]
Max-Forwards: 70
Subject: Performance Test
Content-Length: 0
]]>
</send>
<pause milliseconds="5000"/>
<nop>
<action>
<exec play_pcap_audio="pcap/dtmf_2833_1.pcap"/>
</action>
</nop>
<pause milliseconds="2000"/>
<recv request="BYE"> </recv>
<send>
<![CDATA[
SIP/2.0 200 OK sip:[service]#[remote_ip]:[remote_port] SIP/2.0
Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]
From: sipp <sip:[field]#[local_ip]:[local_port]>;tag=[call_number]
To: sut <sip:[service]#[remote_ip]:[remote_port]>[peer_tag_param]
Call-ID: [call_id]
CSeq: 1 INVITE
Contact: sip:sipp[call_number]#[local_ip]:[local_port]
Max-Forwards: 70
Subject: Performance Test
Content-Length: 0
]]>
</send>
<ResponseTimeRepartition value="10, 20, 30, 40, 50, 100, 150, 200"/>
Actually you have in your script an explicit request to negotiate dtmf in-band using
RTP events :
m=audio [auto_media_port] RTP/AVP 96 0 9 8 101 13
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-1
The peer has accepted you offer I assume and is waiting dtmf as a rtp event packet; you should be able to send a pcap with an rtp event or if not switch to sip notify or info.
This mode is documented in RFC 2833 first and updated by rfc5244.
You have multiple ways of sending DTMF
In-band: where the tone is sent mixed in the audio stream (what you are trying to do)
Out-of-band: in a separate SIP message like SIP INFO or SIP NOTIFY, which are basically messages saying "DTMF 1 was pressed" without putting it in the audio stream. Much easier for an IVR programmer, and more reliable.
The out-of-band method has become so commonplace, that many vendors will not bother turning on their in-band detectors by default. You may want to search for a configuration setting named like "In-band DTMF detection" or "DTMF recognizer" ...
Of course, I don't know the system you are using so "digit received as null" may mean:
"nothing received", possibly meaning the in-band detector is not enabled
"something received but could not understand it", possibly meaning something wrong with your audio file content OR transmission of that content
Since it's SIP-to-SIP I would recommend switching to an out-of-band dtmf message.
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 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.