Incorret fmpt of telephone-event in received INVITE - sip

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.

Related

Duplicate payload type for same codec but different fmtp line is it valid scenario?

I am developing a voip application. In one of the scenario, I'm receiving following SDP from network:
`m=audio 10660 RTP/AVP 18 18 8 0 108
a=fmtp:18 annexb=yes
a=fmtp:18 annexb=no
a=rtpmap:108 telephone-event/16000
a=fmtp:108 0-15
a=ptime:20`
There are 2 instances of payload type 18 for different fmtp line.
Is it valid scenario as per rfc?
That scenario is not valid.
First its missing the rtpmap that identifies the codec, assuming its G729 due to the codec mention the offer should be something like:
m=audio 10660 RTP/AVP 18 8 0 108
a=rtpmap:18 G729/16000
a=fmtp:18 annexb=yes
a=rtpmap:108 telephone-event/16000
a=fmtp:108 0-15
a=ptime:20
Regarding the annexb part, if supported it should be offered with '=yes' then answerer has the option to accept with "=no" as per RFC:
https://www.rfc-editor.org/rfc/rfc7261

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.

Mobicents DTMF rtp event detection

I found in Mobicents MMS description (http://www.mobicents.org/mms/mms-main.html) i found that it supports DTMF inband and also RFC2833.
In practical tests I found that MS prefer inband DTMF. Is there configuration option to force RFC2833, or is it hardcoded? And if is hardcoded, cound you give me a hint, where should I change it in the code? Example of SDP with codec list looks like:
m=audio 11284 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-15
a=sendrecv

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

Send a user defined String within the SDP packet

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.