Google Assistant Camera Stream using WebRTC not hitting signaling URL when sending offer SDP - actions-on-google

I'm trying to integrate a webrtc stream to Google Assistant streaming on NestHub. When we send google an offer SDP, it doesn't hit our signaling url
https://developers.home.google.com/cloud-to-cloud/traits/camerastream
When sending a cameraStreamOffer SDP back as a response to Google for the EXECUTE response, it doesn't send any requests to the cameraStreamSignalingUrl endpoint. When we don't send an SDP back in the response, Google is able to send an offer SDP to the cameraStreamSignalingUrl endpoint, so it is able to hit the endpoint. There appears to be an issue with the SDP that we send to Google
This is the SDP that we are sending to Google
v=0
o=- 1669825024763224 1 IN IP4 ***.***.**.**
s=Mountpoint B83A9D500250_Live
t=0 0
a=group:BUNDLE video
a=msid-semantic: WMS janus
a=ice-lite
m=video 9 UDP/TLS/RTP/SAVPF 126 127
c=IN IP4 ***.***.**.**
a=sendonly
a=mid:video
a=rtcp-mux
a=ice-ufrag:Y2LQ
a=ice-pwd:ciqXQomtZh1SKUg+EEmYLE
a=fingerprint:sha-256 57:AB:50:F9:ED:88:EE:9D:27:21:91:F7:88:21:9C:EC:69:33:2E:41:CD:78:EA:68:CA:3E:61:87:B7:5B:A5:24
a=setup:actpass
a=rtpmap:126 H264/90000
a=fmtp:126 profile-level-id=42e01f;packetization-mode=1
a=rtcp-fb:126 nack
a=rtcp-fb:126 nack pli
a=rtcp-fb:126 goog-remb
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
a=rtpmap:127 rtx/90000
a=fmtp:127 apt=126
a=ssrc-group:FID 3122577054 1367657920
a=msid:janus janusv0
a=ssrc:3122577054 cname:janus
a=ssrc:3122577054 msid:janus janusv0
a=ssrc:3122577054 mslabel:janus
a=ssrc:3122577054 label:janusv0
a=ssrc:1367657920 cname:janus
a=ssrc:1367657920 msid:janus janusv0
a=ssrc:1367657920 mslabel:janus
a=ssrc:1367657920 label:janusv0
a=candidate:1 1 udp 2013266431 ***.***.**.** 27321 typ host
a=candidate:1 1 udp 2013266431 ***.**.***.*** 27321 typ host

Related

How to get Kamailio to set `Record-Route` header to internal IP for internal leg of call?

I have Kamailio 5.4.1 (and RTPEngine) running on an internal server with a private IP address 172.31.7.96 and One-to-one NAT to an external IP address. The external IP is 192.0.2.100. (Note: The internal IP addresses are all unedited, but the public IPs have been replaced with TEST-NET-1 and TEST-NET-2 example addresses.) I will eventually be doing transcoding with RTPEngine, but for now this is a simple SIP Proxy.
I have a Java application that sets up SIP calls running on an internal server with a private IP address 172.31.7.171. The Java application has set properties.setProperty("javax.sip.OUTBOUND_PROXY", "172.31.7.96"); to use Kamailio as an outbound SIP proxy.
The Kamailio server is a stock Kamailio sample configuration with the following changes:
#!define WITH_NAT
#!define WITH_RTPENGINE
#!define WITH_MYSQL
#!define WITH_AUTH
#!define WITH_IPAUTH
#!define WITH_DEBUG
listen=udp:0.0.0.0:5060 advertise 192.0.2.100:5060
#!define DBURL "mysql://kamailio:REAL_PASSWORD_HERE#127.0.0.1/kamailio"
I have added my Java server's IP to the Kamailio database as an allowed server using kamctl address add 172.31.7.171 32 5060.
I am trying to make a call to extension 2003 at a SIP server located at 198.51.100.200.
My Java server follows the OUTBOUND_PROXY setting and sends the following request to Kamailio:
INVITE sip:2003#198.51.100.200:5060 SIP/2.0
Call-ID: 7979ef9aadc442801835750ef2564a19#172.31.6.171
CSeq: 1 INVITE
From: <tel:+18005551234>;tag=1eu0cJThbWsUcycT
To: <sip:2003#198.51.100.200:5060>
Max-Forwards: 70
Contact: <sip:+18005551234#172.31.6.171:5060;lr>
Content-Type: application/sdp
Via: SIP/2.0/UDP 172.31.6.171:5060;branch=z9hG4bK-343236-823591d229bb5a87df35606cbc45e6e6
Content-Length: 788
v=0
o=- 3808349342 3808349342 IN IP4 172.31.6.171
s=Kurento Media Server
c=IN IP4 172.31.6.171
t=0 0
m=audio 29134 RTP/AVPF 96 0 97
a=setup:actpass
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=rtpmap:96 opus/48000/2
a=rtpmap:97 AMR/8000
a=rtcp:29135
a=sendrecv
a=mid:audio0
a=ssrc:3129303479 cname:user3476653135#host-5072a15e
m=video 15672 RTP/AVPF 102 103
a=setup:actpass
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=rtpmap:102 VP8/90000
a=rtpmap:103 H264/90000
a=rtcp:15673
a=sendrecv
a=mid:video0
a=rtcp-fb:102 nack
a=rtcp-fb:102 nack pli
a=rtcp-fb:102 goog-remb
a=rtcp-fb:102 ccm fir
a=rtcp-fb:103 nack
a=rtcp-fb:103 nack pli
a=rtcp-fb:103 ccm fir
a=ssrc:1221454331 cname:user3476653135#host-5072a15e
Kamailio correctly modifies and forwards this request to the SIP server:
INVITE sip:2003#198.51.100.200:5060 SIP/2.0
Record-Route: <sip:192.0.2.100;lr;nat=yes>
Call-ID: 7979ef9aadc442801835750ef2564a19#172.31.6.171
CSeq: 1 INVITE
From: <tel:+18005551234>;tag=1eu0cJThbWsUcycT
To: <sip:2003#198.51.100.200:5060>
Max-Forwards: 69
Contact: <sip:+18005551234#172.31.6.171:5060;lr;alias=172.31.6.171~5060~1>
Content-Type: application/sdp
Via: SIP/2.0/UDP 192.0.2.100:5060;branch=z9hG4bK9466.896020178e132b7f5da3e990cd54fe55.0
Via: SIP/2.0/UDP 172.31.6.171:5060;rport=5060;branch=z9hG4bK-343236-823591d229bb5a87df35606cbc45e6e6
Content-Length: 1048
P-Hint: outbound
v=0
o=- 3808349342 3808349342 IN IP4 172.31.7.96
s=Kurento Media Server
c=IN IP4 172.31.7.96
t=0 0
m=audio 50062 RTP/AVPF 96 0 97
a=ssrc:3129303479 cname:user3476653135#host-5072a15e
a=mid:audio0
a=rtpmap:96 opus/48000/2
a=rtpmap:0 PCMU/8000
a=rtpmap:97 AMR/8000
a=sendrecv
a=rtcp:50063
a=ice-ufrag:jd1CMyb6
a=ice-pwd:nOhBs6gMNStuK301ELxdXtu0qB
a=candidate:nA5nzY4ckB4NyJQB 1 UDP 2130706431 172.31.7.96 50062 typ host
a=candidate:nA5nzY4ckB4NyJQB 2 UDP 2130706430 172.31.7.96 50063 typ host
m=video 50094 RTP/AVPF 102 103
a=rtcp-fb:102 nack
a=rtcp-fb:102 nack pli
a=rtcp-fb:102 goog-remb
a=rtcp-fb:102 ccm fir
a=rtcp-fb:103 nack
a=rtcp-fb:103 nack pli
a=rtcp-fb:103 ccm fir
a=ssrc:1221454331 cname:user3476653135#host-5072a15ea=mid:video0
a=rtpmap:102 VP8/90000
a=rtpmap:103 H264/90000
a=sendrecv
a=rtcp:50095
a=ice-ufrag:k5OhtdDn
a=ice-pwd:R8U3hA1ocUe1ln1F5rpgyHRK98
a=candidate:nA5nzY4ckB4NyJQB 1 UDP 2130706431 172.31.7.96 50094 typ host
a=candidate:nA5nzY4ckB4NyJQB 2 UDP 2130706430 172.31.7.96 50095 typ host
After the expected 100 Trying and 180 Ringing packets, the SIP server sends back a 200 OK packet:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.0.2.100:5060;branch=z9hG4bK9466.896020178e132b7f5da3e990cd54fe55.0;received=192.0.2.100;rport=5060
Via: SIP/2.0/UDP 172.31.6.171:5060;rport=5060;branch=z9hG4bK-343236-823591d229bb5a87df35606cbc45e6e6
Record-Route: <sip:192.0.2.100;lr;nat=yes>
From: <tel:+18005551234>;tag=1eu0cJThbWsUcycT
To: <sip:2003#198.51.100.200:5060>;tag=as7825a958
Call-ID: 7979ef9aadc442801835750ef2564a19#172.31.6.171
CSeq: 1 INVITE
Server: FPBX-13.0.197.22(13.28.1)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Contact: <sip:2003#198.51.100.200:5060>
Content-Type: application/sdp
Content-Length: 311
v=0
o=root 2047371680 2047371680 IN IP4 198.51.100.200
s=Asterisk PBX 13.28.1
c=IN IP4 198.51.100.200
b=CT:384
t=0 0
m=audio 14980 RTP/AVPF 0
a=rtpmap:0 PCMU/8000
a=maxptime:150
a=sendrecv
m=video 12536 RTP/AVPF 103 102
a=rtpmap:103 H264/90000
a=rtpmap:102 VP8/90000
a=rtcp-fb:* ccm fir
a=sendrecv
Kamailio translates this and sends it back to my Java application:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.31.6.171:5060;rport=5060;branch=z9hG4bK-343236-823591d229bb5a87df35606cbc45e6e6
Record-Route: <sip:192.0.2.100;lr;nat=yes>
From: <tel:+16676664567>;tag=1eu0cJThbWsUcycT
To: <sip:2003#198.51.100.200:5060>;tag=as7825a958
Call-ID: 7979ef9aadc442801835750ef2564a19#172.31.6.171
CSeq: 1 INVITE
Server: FPBX-13.0.197.22(13.28.1)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Contact: <sip:2003#198.51.100.200:5060>
Content-Type: application/sdp
Content-Length: 363
v=0
o=root 2047371680 2047371680 IN IP4 172.31.7.96
s=Asterisk PBX 13.28.1
c=IN IP4 172.31.7.96
b=CT:384
t=0 0
m=audio 50076 RTP/AVPF 0
a=maxptime:150
a=mid:audio0
a=rtpmap:0 PCMU/8000
a=sendrecv
a=rtcp:50077
m=video 50116 RTP/AVPF 103 102
a=rtcp-fb:* ccm fir
a=mid:video0
a=rtpmap:103 H264/90000
a=rtpmap:102 VP8/90000
a=sendrecv
a=rtcp:50117
This is where the problem starts. My Java application sees the Record-Route header which says 192.0.2.100 and tries to send the ACK response to that address, as well as including it in a Route header:
ACK sip:2003#198.51.100.200:5060 SIP/2.0
Call-ID: 7979ef9aadc442801835750ef2564a19#172.31.6.171
CSeq: 1 ACK
Via: SIP/2.0/UDP 172.31.6.171:5060;branch=z9hG4bK-343236-57a2ec825886f425ef0b9f8cf2034887
From: <tel:+18005551234>;tag=1eu0cJThbWsUcycT
To: <sip:2003#198.51.100.200:5060>;tag=as7825a958
Max-Forwards: 70
Route: <sip:192.0.2.100;lr;nat=yes>
Record-Route: <sip:192.0.2.100;lr;nat=yes>
Content-Length: 0
The problem here is that my internal server cannot actually route traffic to the public IP of the Kamailio server so the ACK never gets there.
I tried adding a second listen directive to Kamailio like this and then set the OUTBOUND_PROXY to use port 5061, but then Kamailio tries to put 172.31.7.96:5061 in the outbound SIP messages too:
listen=udp:0.0.0.0:5060 advertise 192.0.2.100:5060
listen=udp:172.31.7.96:5061
How can I configure Kamailio to use its private IP when talking to the internal server and its public IP when talking to the external server?
To resolve such an issue I switched to use IPv6 on internal SIP servers for signaling and IPv4 for RTP media.

Unable to RTCPeerConnection::setRemoteDescription: Failed to set remote offer sdp: Failed to set remote video description send parameters

I keep getting this error on my android webrtc app using the webrtc flutter plugin when I take the sdp from janus-gateway and try to set it as remote description.
I've tried adjusting the sdp cause I thought it wasn't able to parse the string but it didn't work.
v=0
o=- 1560396930181938 1 IN IP4 "ip"
s=Mountpoint 99
t=0 0
a=group:BUNDLE video
a=msid-semantic: WMS janus
m=video 9 UDP/TLS/RTP/SAVPF 96
c=IN IP4 "ip"
a=sendonlyd
a=mid:video
a=rtcp-mux
a=ice-ufrag:fg6W
a=ice-pwd:wyQGuelBzLh8ToRawNUf9p
a=ice-options:trickle
a=fingerprint:sha-256
a=setup:actpass
a=rtpmap:96 H264/90000
a=fmtp:96 packetization-mode=1;profile-level-id=4d002a;sprop-parameter-sets=Z00AKpY1QPAET8s3AQEBQAAAAwBAAAAKIQ==,aO48gA==
a=rtcp-fb:96 nack
a=rtcp-fb:96 nack pli
a=rtcp-fb:96 goog-remb
a=ssrc:3959652904 cname:janus
a=ssrc:3959652904 msid:janus janusv0
a=ssrc:3959652904 mslabel:janus
a=ssrc:3959652904 label:janusv0
a=candidate:1 1 udp 2013266431 "ip" 50391 typ host
a=end-of-candidates
Apart from the "sendonlyd" typo that was already mentioned, pretty sure the cause is the H.264 profile the RTSP camera is setting (since it's a Janus Mountpoint offer, I guess that's what you're doing), which the browser very likely doesn't like. You can override the camera fmtp line using "videofmtp" in Janus. You can find more info on the Janus group, where this is a commonly asked question: https://groups.google.com/forum/#!forum/meetecho-janus
It looks like there is a typo in the SDP:
a=sendonlyd
should be a=sendonly

How do you do NAT traversal for RTP media using Kamailio for signalling?

There are three devices in question.
A VoIP phone behind NAT
My own Kamailio Server on an EC2 instance.
The Linphone application for android on my phone.
My phone is on mobile data, and since I have an MVNO, it appears to be NATed as well (private IP like 192.0.0.X).
My problem, is that Although SIP signalling is working just fine, I can't get either device to receive the other's RTP media streams.
I've defined WITH_NAT in the kamailio.cfg, but it doesn't seem to be helping with gathering candidates. Here's the invite before and after passing through Kamailio.
Before:
Via: SIP/2.0/UDP 192.0.0.4:46244;branch=z9hG4bK.bLB4chm4B;rport.
From: "the app" <sip:105#<SERVERDOMAIN>>;tag=EHCGj~8d5.
To: sip:104#<SERVERDOMAIN>.
CSeq: 20 INVITE.
Call-ID: SyOH-iCt1A.
Max-Forwards: 70.
Supported: replaces, outbound, gruu.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO, UPDATE.
Content-Type: application/sdp.
Content-Length: 721.
Contact: <sip:105#172.56.20.144:43565;transport=udp>;expires=3600;received="sip:172.56.20.144:43565";+sip.instance="<urn:uuid:f102067f-da3a-00f6-9530-ee66544ec6b4>".
User-Agent: <USERAGENT>/0.2.1-debug (Mobile Dev Environment 1) LinphoneSDK/4.1-366-g1b22291 (master) (belle-sip/1.6.3).
.
v=0.
o=105 911 2837 IN IP4 192.0.0.4.
s=Talk.
c=IN IP4 192.0.0.4.
t=0 0.
a=ice-pwd:42da1553a4faaaf4b57c93f2.
a=ice-ufrag:894dda61.
a=rtcp-xr:rcvr-rtt=all:10000 stat-summary=loss,dup,jitt,TTL voip-metrics.
m=audio 7078 RTP/AVP 0 8 101.
a=rtpmap:101 telephone-event/8000.
a=candidate:1 1 UDP 2130706303 192.0.0.4 7078 typ host.
a=candidate:1 2 UDP 2130706302 192.0.0.4 7079 typ host.
a=rtcp-fb:* trr-int 1000.
a=rtcp-fb:* ccm tmmbr.
m=video 9078 RTP/AVP 96.
a=rtpmap:96 H264/90000.
a=fmtp:96 profile-level-id=42801F.
a=candidate:1 1 UDP 2130706303 192.0.0.4 9078 typ host.
a=candidate:1 2 UDP 2130706302 192.0.0.4 9079 typ host.
a=rtcp-fb:* trr-int 1000.
a=rtcp-fb:* ccm tmmbr.
a=rtcp-fb:96 nack pli.
a=rtcp-fb:96 ccm fir.
After:
Record-Route: <sip:<SERVERDOMAIN>:<PORT>;lr;nat=yes>.
Via: SIP/2.0/UDP <SERVERDOMAIN>:<PORT>;branch=z9hG4bKdd88.20b5965a3ea168d68a6b0603ebaa6c80.0.
Via: SIP/2.0/UDP 192.0.0.4:46244;received=172.56.20.144;branch=z9hG4bK.bLB4chm4B;rport=43565.
From: "the app" <sip:105#<SERVERDOMAIN>>;tag=EHCGj~8d5.
To: sip:104#<SERVERDOMAIN>.
CSeq: 20 INVITE.
Call-ID: SyOH-iCt1A.
Max-Forwards: 69.
Supported: replaces, outbound, gruu.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO, UPDATE.
Content-Type: application/sdp.
Content-Length: 721.
Contact: <sip:105#172.56.20.144:43565;transport=udp;alias=172.56.20.144~43565~1>;expires=3600;received="sip:172.56.20.144:43565";+sip.instance="<urn:uuid:f102067f-da3a-00f6-9530-ee66544ec6b4>".
User-Agent: <USERAGENT>/0.2.1-debug (Mobile Dev Environment 1) LinphoneSDK/4.1-366-g1b22291 (master) (belle-sip/1.6.3).
.
v=0.
o=105 911 2837 IN IP4 192.0.0.4.
s=Talk.
c=IN IP4 192.0.0.4.
t=0 0.
a=ice-pwd:42da1553a4faaaf4b57c93f2.
a=ice-ufrag:894dda61.
a=rtcp-xr:rcvr-rtt=all:10000 stat-summary=loss,dup,jitt,TTL voip-metrics.
m=audio 7078 RTP/AVP 0 8 101.
a=rtpmap:101 telephone-event/8000.
a=candidate:1 1 UDP 2130706303 192.0.0.4 7078 typ host.
a=candidate:1 2 UDP 2130706302 192.0.0.4 7079 typ host.
a=rtcp-fb:* trr-int 1000.
a=rtcp-fb:* ccm tmmbr.
m=video 9078 RTP/AVP 96.
a=rtpmap:96 H264/90000.
a=fmtp:96 profile-level-id=42801F.
a=candidate:1 1 UDP 2130706303 192.0.0.4 9078 typ host.
a=candidate:1 2 UDP 2130706302 192.0.0.4 9079 typ host.
a=rtcp-fb:* trr-int 1000.
a=rtcp-fb:* ccm tmmbr.
a=rtcp-fb:96 nack pli.
a=rtcp-fb:96 ccm fir.
It's the same story for inbound calls.
I was expecting the nathelper module to add something like
a=candidate:2 1 UDP 1694498815 <SOME_PUBLIC_IP> <SOME_PUBLIC_PORT> typ srflx raddr
192.0.0.4 rport 7078
but clearly it is not. I can modify o= and c= in the headers to use the IP that the server received the invite from, but how is the server suppose to know which ports the RTP media should be sent to? The only ports the server could know are
The port that the invite was sent from (private and public side)
The ports provided in the sdp. But these are on the private-side. Surely they would be different on the public-side?
Any help on this would be appreciated.
You will need to setup rtpproxy or rtpengine.
Here is the simplest procedure for installing and configuring rtpproxy with Kamailio:
1- install rtpproxy
apt install rtpproxy
2- Enter these 2 lines in rtpproxy configuration file (/etc/default/rtpproxy):
CONTROL_SOCK=udp:127.0.0.1:7722
EXTRA_OPTS="-l IP-address"
IP-address is the external IP address of your host.
3- Enter this define near the top of Kamailio configuration file (/etc/kamailio/kamailio.cfg):
#!define WITH_NAT
4- Restart rtpproxy
systemctl restart rtpproxy
5- Restart Kamailio
systemctl restart kamailio
INVITE and 200 OK relayed by Kamailio should then have their SDP Contact IPs and Ports replaced with the ones for rtpproxy
Note: I noticed at least one of the UAC should use TCP Transport for the above to work.

Why am I getting SIP response 400: Bad Session Description?

I dumped The following SIP INVITE datagram from Linphone to a file with CR-LF line breaks, using wireshark:
INVITE sip:1002#172.16.76.21 SIP/2.0
Via: SIP/2.0/UDP 172.16.76.21:5060;rport;branch=z9hG4bK1936726928
From: <sip:1555#172.16.76.21>;tag=1350138383
To: <sip:1002#172.16.76.21>
Call-ID: 1393698667
CSeq: 20 INVITE
Contact: <sip:1555#172.16.76.20>
Content-Type: application/sdp
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
Max-Forwards: 70
User-Agent: Linphone/3.5.2 (eXosip2/3.6.0)
Subject: Phone call
Content-Length: 205
v=0
o=1555 1125 1125 IN IP4 172.16.76.21
s=Talk
c=IN IP4 172.16.76.21
t=0 0
m=audio 7078 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-11
I wrote a simple Python script that reads the file binary, puts in a UDP datagram and sends through a a socket bound to port 5060. When I send this to a client running user agent, I get 200 OK. When I try to send it to our SIP proxy, FreeSwitch, I get 400 Bad Session Description.
FreeSwitch responded with 200 OK when this message was originally sent by Linphone.
Apparently FreeSwitch does not tolerate them.
It's not an issue of FreeSwitch. As suggested by #Stanislav in his comment, your "Content-Length" value is wrong. It must be "Content-Length: 213" for your Session Description.
Most of these lines have trailing extra whitespaces. Apparently FreeSwitch does not tolerate them. Removing the trailing spaces works.
Also content-length is wrong. It should be 213.

pjsip sip header configuration

I am using Sip in my ios projects and siphon classes on top of pjsip sdk .
I have no problem with basic configuration and therefore I need to add some custom data to my sip header whenever I make a sip call.
I have the following header format
pjsua_core.c . TX 1123 bytes Request msg INVITE/cseq=31730 (tdta0x92aa400) to UDP xxxxx: 5060:
INVITE sip:xxx9#xxxxxx SIP/2.0
Via: SIP/2.0/UDP xxxxx:xxx;rport;branch=z9hG4bKPjt.fUN05fzpwxbm5zJvjoGSA.bnLvoAHl
Max-Forwards: 70
From: sip:xxxx#xxxxx;tag=d1Ww0T4iQNqygphKlqLQ.iNcYx-Cdsb2
To: sip:xxxx#xxxxxxxx
Contact:
Call-ID: a3zCaQtWPsnKrlbyYtLwwhUQgxnLs8hv
CSeq: 31730 INVITE
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
Supported: replaces, 100rel, timer, norefersub
Session-Expires: 1800
Min-SE: 90
User-Agent: Siphon PjSip v2.0.1svn/arm-apple-darwin9
;sdsd: BLABLABLA
Content-Type: application/sdp
Content-Length: 448
v=0
o=- 3563345387 3563345387 IN IP4 192.168.1.3
s=pjmedia
b=AS:84
t=0 0
a=X-nat:0
m=audio 40000 RTP/AVP 98 97 99 104 3 0 8 96
c=IN IP4 192.168.1.3
b=TIAS:64000
a=rtcp:40001 IN IP4 192.168.1.3
a=sendrecv
a=rtpmap:98 speex/16000
a=rtpmap:97 speex/8000
a=rtpmap:99 speex/32000
a=rtpmap:104 iLBC/8000
a=fmtp:104 mode=30
a=rtpmap:3 GSM/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-15
--end msg--
I want to change the following two lines
From: sip:xxxx#xxxxx;tag=d1Ww0T4iQNqygphKlqLQ.iNcYx-Cdsb2
To: sip:xxxx#xxxxxxxx
to look like this
From: sip:xxxx#xxxxx;tag=d1Ww0T4iQNqygphKlqLQ.iNcYx-Cdsb2;textid=1 ;texfrom=2;textto=4
To: sip:xxxx#xxxxxxxx
just like that.
Kindly, provide some clarity.
pjsip uses pjsua_call_make_call API to make a call. Inside this it creates a dialog with a call to pjsip_dlg_create_uac. You can pass your custom headers to this API. More information here