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...
Related
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.
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
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.
I have two SIP clients ( "A" and "B" ) connected to asterisk on generic bridge mode.
"A"'s video is playing back on "B" but "B"'s video is NOT playing back on "A". I triple checked with wireshark that the media ( audio / video )
is arriving at "A"'s ip address. Audio is working well on both sides.
My best guess is that this issue is related to asterisk's internal SDP handling.
So, lets delve into the problem.
"A" sends the followind INVITE:
INVITE sip:700#192.168.7.227 SIP/2.0
Via: SIP/2.0/UDP 192.168.7.225:10074;branch=z9hG4bK-224696310;rport
From: "danflu-portsip"<sip:danflu-portsip#192.168.7.227>;tag=87652133
To: <sip:700#192.168.7.227>
Contact: <sip:danflu-portsip#192.168.7.225:10074;transport=udp>;
Call-ID: YTc0NDRjNDYtMWRhMS01MzE2LWVlNDEtYmV
CSeq: 1354707857 INVITE
Content-Type: application/sdp
Content-Length: 447
Max-Forwards: 70
Authorization: Digest username="danflu-portsip",realm="asterisk",nonce="5ac40c6d",uri="sip:700#192.168.7.227",response="fae8a78ba97 2f6cb0c76846d76f13786",algorithm=MD5
User-Agent: PortSIP SDK for IOS
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, REGISTER, SUBSCRIBE, INFO
P-Preferred-Identity: <sip:danflu-portsip#192.168.7.227>
Supported: 100rel
v=0
o=portsip 2013 678901 IN IP4 192.168.7.225
s=-
c=IN IP4 192.168.7.225
t=0 0
m=audio 20554 RTP/AVP 8 0 97 18
a=ptime:20
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:97 SPEEX/8000
a=rtpmap:18 g729/8000
a=fmtp:18 annexb=yes
a=sendrecv
a=ssrc:258325709 cname:258325709
m=video 29350 RTP/AVP 104
a=rtpmap:104 H264/90000
a=fmtp:104 profile-level-id=42801E; packetization-mode=1
a=sendrecv
a=ssrc:1956389748 cname:1956389748
and receives a "200 OK" message from Asterisk:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.7.225:10010;branch=z9hG4bK-282879312 received=192.168.7.225;
rport=10010
From: "danflu-portsip"<sip:danflu-portsip#192.168.7.227>;tag=539964865
To: <sip:9993#192.168.7.227>;tag=as1b6086b5
Call-ID: OTE4MjM3NzUtMDIzNy1mNTM1LWM3MzYtOGZ
CSeq: 1074035624 INVITE
Server: Asterisk PBX SVN-branch-1.8-r402287M
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Contact: <sip:9993#192.168.7.227:5060>
Content-Type: application/sdp
Content-Length: 375
v=0
o=root 826339596 826339596 IN IP4 192.168.7.227
s=Asterisk PBX SVN-branch-1.8-r402287M
c=IN IP4 192.168.7.227
b=CT:384
t=0 0
m=audio 9540 RTP/AVP 8 0 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv
m=video 7450 RTP/AVP 104
a=rtpmap:104 H264/90000
a=sendrecv
Note that the lines:
a=fmtp:104 profile-level-id=42801E; packetization-mode=1
and
a=ssrc:1956389748 cname:1956389748
simply disappeared in the response and I really think thats the reason the video is not working.
So, my question:
What API can I use to customize this behavior, so the lines above are not removed when Asterisk handles the SDP from both sides ?
If there is not an official API where could I look in the code for this ? So I could maybe write a patch for my specific situation ?
I looked in chan_sip.c and there is a function:
static int process_sdp(struct sip_pvt *p, struct sip_request *req, int t38action)
But I'm not sure if this SDP handling ( removing lines and the like ) is perfomed by asterisk core or by the sip channel driver.
Thanks
Asterisk video is very strange thing. Becuase asterisk not do transcoding for video codecs/streams.
Only really working mode - all video codecs are turned off and only single codec turned on on all peers.
For more info see Asterisk Video on voip-info.org
is there a way to send a short user defined string from the Caller to the Callee within the SDP part of an INVITE message (in a manner like steganography)? I tried to set the string with a length of approximately 15, in the k=, p=, e=, u= field. However the Asterisk server does not accept the Invite message. For sure, I set the new length in the IP-Header and UDP-Header furthermore I calculated the new Internet checksum of the IP-Header. As well I considered the CRLF scheme and the order of the fields.
Goal is, to transport data within the SDP data from the Caller to the Callee and vice versa, when the Callee responds with the 200 OK message to the Caller.
Thank you in advance!
Message with i=111.111.111.111 which is not accepted by the Asterisk:
INVITE sip:1000#192.168.0.14 SIP/2.0
Via: SIP/2.0/UDP 192.168.11.2:6060;rport;branch=z9hG4bKGvBkM0qF4
Max-Forwards: 70
To: <sip:1000#192.168.0.14>
From: <sip:2000#192.168.0.14>;tag=SOXFP4ir
Call-ID: BEkXWRwn-1318101970419#x61.local
CSeq: 39 INVITE
Content-Length: 231
Content-Type: application/sdp
Contact: <sip:2000#192.168.11.2:6060;transport=UDP>
v=0
o=user1 1396633799 2096570444 IN IP4 192.168.11.2
s=-
i=111.111.111.111
c=IN IP4 192.168.11.2
t=0 0
m=audio 8000 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=sendrecv
Same Message but without i=111.111.111.111. This packet is accepted and the call proceeding ends successfully (with TRYING, RING 200OK)
INVITE sip:1000#192.168.0.14 SIP/2.0
Via: SIP/2.0/UDP 192.168.11.2:6060;rport;branch=z9hG4bKESGSZD1V6
Max-Forwards: 70
To: <sip:1000#192.168.0.14>
From: <sip:2000#192.168.0.14>;tag=YPPrCWLp
Call-ID: 10MpKHYD-1318102031971#x61.local
CSeq: 41 INVITE
Content-Length: 211
Content-Type: application/sdp
Contact: <sip:2000#192.168.11.2:6060;transport=UDP>
v=0
o=user1 1682420165 643979666 IN IP4 192.168.11.2
s=-
c=IN IP4 192.168.11.2
t=0 0
m=audio 8000 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=sendrecv
Actually everything looks fine. And I can not see the response. I am intercepting the packets over iptables with NFQUEUE. Then just a few strstr, memcpy etc. to alter and build the new packets. I know there are some SDP stacks/APIs but in my case the quick and dirty solution is sufficient.
Try the i= field. As stated in RFC 4566:
The "i=" field is intended to provide a free-form human-readable description of the session or the purpose of a media stream. It is not suitable for parsing by automata.
So the Asterisk server shouldn't validate that field, enabling you to put the text you want there.