Send a user defined String within the SDP packet - sip

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.

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...

Incorret fmpt of telephone-event in received INVITE

We have a case where we have to apply the conditional codec policy on the egress side. But I have a problem with the script where sending telephone-event with payload-type 101 and 119 in the initial INVITE but did not received any fmtp for telephone-event whereas my scripts expects it to come. I am new to this field of SIP and SDP and unable to figure out the exact problem.
I thought the script is expecting what it shouldn't, so removed the expectation and the call is successfully completing. Below is the Sending and Received INVITE.
Sending INVITE with below SDP:
v=0
o=user1 53655765 2353687637 IN IP4 192.168.205.193
s=-
c=IN IP4 192.168.205.193
t=0 0
m=audio 10000 RTP/AVP 96 97 119
a=rtpmap:96 AMR/8000
a=rtpmap:97 AMR/8000
a=rtpmap:119 telephone-event/8000
a=fmtp:97 octet-align=1
Received INVITE with SDP:
v=0
o=user1 53655765 2353687637 IN IP4 192.168.205.195
s=-
c=IN IP4 192.168.205.195
t=0 0
m=audio 13008 RTP/AVP 102 100 0 96 97 101 119
a=rtpmap:102 AMR-WB/16000/1
a=fmtp:102 mode-set=0,1,2
a=rtpmap:100 AMR/8000
a=fmtp:100 mode-set=0,2,5,7
a=rtpmap:0 PCMU/8000
a=rtpmap:96 AMR/8000
a=rtpmap:97 AMR/8000
a=fmtp:97 octet-align=1
a=rtpmap:101 telephone-event/16000
a=rtpmap:119 telephone-event/8000
My script is expecting fmtp: 101 0-15 but missing from received INVITE, When and in which case fmtp of DTMF should be expected and with what payload type of dynamic codec should we receive? What if I remove the fmtp expectation of telephone-event in the received INVITE from the script?
Without knowing the requirement, but according to the DTMF RFCs, I would also have removed the expectation.
https://www.rfc-editor.org/rfc/rfc2833
Pg 10-11
Since all implementations MUST be able to receive events 0 through
15, listing these events in the a=fmtp line is OPTIONAL.
https://www.rfc-editor.org/rfc/rfc4733
Pg 10-11
... For backward compatibility, if
no "events" parameter is received, the sender SHOULD assume support
for the DTMF events 0-15 but for no other events.

DTMF digit with SIPP test

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.

Using SDP media type application with RTP/AVP (m=application <Port #> RTP/AVP <Payload>)

I am trying to get familiar with the anatomy of a SIP SDP. Here is a sample SDP from my Tandberg VC unit.
v=0
o=tandberg 1 3 IN IP4 192.168.1.94
s=-
c=IN IP4 192.168.1.94
b=AS:768
t=0 0
m=audio 47032 RTP/AVP 97 98 99 100 101 9 15 8 0 102
b=TIAS:64000
a=rtpmap:97 MP4A-LATM/90000
a=fmtp:97 profile-level-id=24;object=23;bitrate=64000
a=rtpmap:98 MP4A-LATM/90000
a=fmtp:98 profile-level-id=24;object=23;bitrate=56000
a=rtpmap:99 MP4A-LATM/90000
a=fmtp:99 profile-level-id=24;object=23;bitrate=48000
a=rtpmap:100 G7221/16000
a=fmtp:100 bitrate=32000
a=rtpmap:101 G7221/16000
a=fmtp:101 bitrate=24000
a=rtpmap:9 G722/8000
a=rtpmap:15 G728/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:102 telephone-event/8000
a=fmtp:102 0-15
m=video 47034 RTP/AVP 122 121 120 34 31
b=TIAS:768000
a=rtpmap:122 H264-RCDO/90000
a=fmtp:122 profile-level-id=008016;max-mbps=42000;max-fs=3600;max-smbps=323500
a=rtpmap:121 H264/90000
a=fmtp:121 profile-level-id=428016;max-mbps=35000;max-fs=3600;max-smbps=323500
a=rtpmap:120 H263-1998/90000
"a=fmtp:120 custom=1280,720,3;custom=1024,768,4;custom=1024,576,2;custom=800,600,3;cif4=2;custom=720,480,2;custom=640,480,2;
custom=512,288,1;cif=1;custom=352,240,1;qcif=1;sqcif=1;maxbr=7680"
a=rtpmap:34 H263/90000
a=fmtp:34 cif4=2;cif=1;qcif=1;sqcif=1;maxbr=7680
a=rtpmap:31 H261/90000
a=fmtp:31 cif=1;qcif=1;maxbr=7680
a=rtcp-fb:* nack pli
a=content:main
a=label:11
a=answer:full
m=application 5071 UDP/BFCP *
a=floorctrl:c-s
a=confid:1
a=floorid:2 mstrm:12
a=userid:1
a=setup:passive
a=connection:new
m=video 47036 RTP/AVP 120 34 31
b=TIAS:768000
a=rtpmap:120 H263-1998/90000
"a=fmtp:120 custom=1280,720,3;custom=1024,768,4;custom=1024,576,2;custom=800,600,3;cif4=2;custom=720,480,2;custom=640,480,2;custom=512,
288,1;cif=1;custom=352,240,1;qcif=1;sqcif=1;maxbr=7680"
a=rtpmap:34 H263/90000
a=fmtp:34 cif4=2;cif=1;qcif=1;sqcif=1;maxbr=7680
a=rtpmap:31 H261/90000
a=fmtp:31 cif=1;qcif=1;maxbr=7680
a=rtcp-fb:* nack pli
a=content:slides
a=label:12
m=application 47038 RTP/AVP 103
a=rtpmap:103 H224/4800
So my understanding is that RTP/AVP protocol can only be used with media-type audio or video. Keeping this in view I didn't understand the last two lines:
m=application 47038 RTP/AVP 103
a=rtpmap:103 H224/4800
Any ideas on what they mean?
You use SDP to negotiate a session between two peers. A session may consist of multiple media lines. If we want to use audio and video inside (= video-call) we need two media lines. Based on RFC4566 a media line is described as:
m= media port proto fmt ...
Where media can be:
is the media type. Currently defined media are "audio",
"video", "text", "application", and "message",
So in our case we would need two media lines, one for audio, one for video. Each media line describes the transport protocol port (e.g. UDP for audio) where e.g. audio shall be received.
So in your example the sender of the SDP message wants to receive packets on port 47038. Additionally we RTP to transmit information. AVP stands for audio video profile (see Wikipedia). In RTP we've a range of predefined codec numbers, e.g. number 0 stands for PCM U-law. In your case you're using a number of a dynamic range -> the idea is that I should be able to extend the codec map in RTP. Therefore RTP defines a dynamic codec number range ( = 96 -127).
We using a dynamic codec this codec has to be described in more detail. That's the job of the a=-line (attribute-line) below the media line.
RFC 4566:
Attributes are the primary means for extending SDP. Attributes may
be defined to be used as "session-level" attributes, "media-level"
attributes, or both.
A media description may have any number of attributes ("a=" fields)
that are media specific. These are referred to as "media-level"
attributes and add information about the media stream. Attribute
fields can also be added before the first media field; these
"session-level" attributes convey additional information that applies
to the conference as a whole rather than to individual media.
So you a=-line describes that the above media line uses a H224 codec for RTP, where the payload type number in RTP is set to 103. I guess that 4800 stands for the codec's sampling rate.
Hope that helps.
So my understanding is that RTP/AVP protocol can only be used with media-type audio or video.
There is no such restriction, RFC4566 states that
is the media type. Currently defined media are "audio",
"video", "text", "application", and "message", although this list
may be extended in the future (see Section 8).
Application-specific messages can also be sent over RTP, in your case the
m=application 47038 RTP/AVP 103
a=rtpmap:103 H224/4800
lines refer to RFC4573 which is a payload format used for remote camera control.

Asterisk API SDP Handling

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