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.
Related
Closed. This question is not about programming or software development. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 4 months ago.
Improve this question
Issue Description
Freeswitch not sending SIP ACK when call answer event (200 OK) is received from the remote gateway. The gateway repeatedly sends 200 OK for 30 seconds and then drops the call due to a ACK timeout.
This is resulting in all outbound calls through the gateway dropping after 32-33 seconds even though 2-way media is established.
All incoming calls through the same gateway work fine.
Outbound calls to registered extensions also work fine. The extensions are also registering to the Freeswitch over the internet using the external IP of Freeswitch server.
Setup
Freeswitch 1.10.8-dev running on an AWS EC2 instance with an elastic IP.
Variables external_sip_ip and external_rtp_ip are both set to be deduced via STUN.
Remote gateway reached over the internet. Transport used is TCP. SRTP/ZRTP disabled.
acl.conf.xml whitelists the remote gateway IP under "domains".
Security group/Firewall rules allow full communication with remote gateway (0-65353 on both UDP and TCP) for the time being.
Expected behaviour
Outbound calls through the gateway should work seamlessly just like inbound calls through gateway and extension calls. Outbound calls through gateway should not drop after about 30 seconds.
Freeswitch version
1.10.8-dev
Gateway xml
<include>
<gateway name="airtel">
<param name="username" value=""/>
<param name="password" value=""/>
<param name="realm" value="remote.gateway.ip.addr:6060"/>
<param name="proxy" value="remote.gateway.ip.addr:6060;transport=tcp"/>
<param name="from-user" value="+917654321098"/>
<param name="from-domain" value="fs.ext.ip.addr"/>
<param name="register-transport" value="tcp" />
<param name="register" value="false" />
<param name="auth-calls" value="false"/>
<param name="caller-id-in-from" value="true"/>
<param name="vad" value="both"/>
<variables>
<variable name="rtp_secure_media" value="false"/>
</variables>
</gateway>
</include>
Trace logs
INVITE sip:+919876543210#remote.gateway.ip.addr:6060;transport=tcp SIP/2.0
Via: SIP/2.0/TCP fs.ext.ip.addr;rport;branch=z9hG4bKXyZrZU4jZUjve
Max-Forwards: 70
From: <sip:0000000000#fs.ext.ip.addr>;tag=SmjU29t0HXt2g
To: <sip:+919876543210#remote.gateway.ip.addr:6060;transport=tcp>
Call-ID: 0bbd8929-ae0f-123b-08b9-02e5070a49dd
CSeq: 56984975 INVITE
Contact: <sip:gw+airtel#fs.ext.ip.addr:5060;transport=tcp;gw=airtel>
User-Agent: FreeSWITCH-mod_sofia/1.10.8-dev+git~20220427T172338Z~7e2d6384bc~64bit
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
Supported: timer, path, replaces
Allow-Events: talk, hold, conference, presence, as-feature-event, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 266
X-HiveName: nithish_kubernetes
X-FS-Support: update_display,send_info
Remote-Party-ID: <sip:0000000000#fs.ext.ip.addr>;party=calling;screen=yes;privacy=off
v=0
o=FreeSWITCH 1663056732 1663056733 IN IP4 fs.ext.ip.addr
s=FreeSWITCH
c=IN IP4 fs.ext.ip.addr
t=0 0
m=audio 20802 RTP/AVP 0 8 9 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:9 G722/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
SIP/2.0 100 Trying
Via: SIP/2.0/TCP fs.ext.ip.addr;rport=57679;branch=z9hG4bKXyZrZU4jZUjve
From: <sip:0000000000#fs.ext.ip.addr>;tag=SmjU29t0HXt2g
To: <sip:+919876543210#remote.gateway.ip.addr:6060;transport=tcp>
Call-ID: 0bbd8929-ae0f-123b-08b9-02e5070a49dd
CSeq: 56984975 INVITE
Content-Length: 0
SIP/2.0 183 Session Progress
Via: SIP/2.0/TCP fs.ext.ip.addr;rport=57679;branch=z9hG4bKXyZrZU4jZUjve
From: <sip:0000000000#fs.ext.ip.addr>;tag=SmjU29t0HXt2g
To: <sip:+919876543210#remote.gateway.ip.addr:6060;transport=tcp>;tag=007d7ff6a00e45fe15ffbb8ea6137e87
Call-ID: 0bbd8929-ae0f-123b-08b9-02e5070a49dd
CSeq: 56984975 INVITE
Contact: <sip:+919876543210#remote.gateway.ip.addr:17828;transport=TCP>
Supported: replaces
Content-Type: application/sdp
Content-Length: 199
v=0
o=host 321988 321989 IN IP4 remote.gateway.ip.addr
s=-
c=IN IP4 remote.gateway.ip.addr
t=0 0
m=audio 41860 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-11
a=ptime:20
SIP/2.0 200 OK
Via: SIP/2.0/TCP fs.ext.ip.addr;rport=57679;branch=z9hG4bKXyZrZU4jZUjve
From: <sip:0000000000#fs.ext.ip.addr>;tag=SmjU29t0HXt2g
To: <sip:+919876543210#remote.gateway.ip.addr:6060;transport=tcp>;tag=007d7ff6a00e45fe15ffbb8ea6137e87
Call-ID: 0bbd8929-ae0f-123b-08b9-02e5070a49dd
CSeq: 56984975 INVITE
Contact: <sip:+919876543210#remote.gateway.ip.addr:17828;transport=TCP>
Supported: replaces
Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, INFO, UPDATE, NOTIFY, REFER
Content-Type: application/sdp
Content-Length: 199
v=0
o=host 322940 322941 IN IP4 remote.gateway.ip.addr
s=-
c=IN IP4 remote.gateway.ip.addr
t=0 0
m=audio 41860 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-11
a=ptime:20
SIP/2.0 200 OK
Via: SIP/2.0/TCP fs.ext.ip.addr;rport=57679;branch=z9hG4bKXyZrZU4jZUjve
From: <sip:0000000000#fs.ext.ip.addr>;tag=SmjU29t0HXt2g
To: <sip:+919876543210#remote.gateway.ip.addr:6060;transport=tcp>;tag=007d7ff6a00e45fe15ffbb8ea6137e87
Call-ID: 0bbd8929-ae0f-123b-08b9-02e5070a49dd
CSeq: 56984975 INVITE
Contact: <sip:+919876543210#remote.gateway.ip.addr:17828;transport=TCP>
Supported: replaces
Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, INFO, UPDATE, NOTIFY, REFER
Content-Type: application/sdp
Content-Length: 199
v=0
o=host 322940 322941 IN IP4 remote.gateway.ip.addr
s=-
c=IN IP4 remote.gateway.ip.addr
t=0 0
m=audio 41860 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-11
a=ptime:20
SIP/2.0 200 OK
Via: SIP/2.0/TCP fs.ext.ip.addr;rport=57679;branch=z9hG4bKXyZrZU4jZUjve
From: <sip:0000000000#fs.ext.ip.addr>;tag=SmjU29t0HXt2g
To: <sip:+919876543210#remote.gateway.ip.addr:6060;transport=tcp>;tag=007d7ff6a00e45fe15ffbb8ea6137e87
Call-ID: 0bbd8929-ae0f-123b-08b9-02e5070a49dd
CSeq: 56984975 INVITE
Contact: <sip:+919876543210#remote.gateway.ip.addr:17828;transport=TCP>
Supported: replaces
Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, INFO, UPDATE, NOTIFY, REFER
Content-Type: application/sdp
Content-Length: 199
v=0
o=host 322940 322941 IN IP4 remote.gateway.ip.addr
s=-
c=IN IP4 remote.gateway.ip.addr
t=0 0
m=audio 41860 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-11
a=ptime:20
SIP/2.0 200 OK
Via: SIP/2.0/TCP fs.ext.ip.addr;rport=57679;branch=z9hG4bKXyZrZU4jZUjve
From: <sip:0000000000#fs.ext.ip.addr>;tag=SmjU29t0HXt2g
To: <sip:+919876543210#remote.gateway.ip.addr:6060;transport=tcp>;tag=007d7ff6a00e45fe15ffbb8ea6137e87
Call-ID: 0bbd8929-ae0f-123b-08b9-02e5070a49dd
CSeq: 56984975 INVITE
Contact: <sip:+919876543210#remote.gateway.ip.addr:17828;transport=TCP>
Supported: replaces
Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, INFO, UPDATE, NOTIFY, REFER
Content-Type: application/sdp
Content-Length: 199
v=0
o=host 322940 322941 IN IP4 remote.gateway.ip.addr
s=-
c=IN IP4 remote.gateway.ip.addr
t=0 0
m=audio 41860 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-11
a=ptime:20
SIP/2.0 200 OK
Via: SIP/2.0/TCP fs.ext.ip.addr;rport=57679;branch=z9hG4bKXyZrZU4jZUjve
From: <sip:0000000000#fs.ext.ip.addr>;tag=SmjU29t0HXt2g
To: <sip:+919876543210#remote.gateway.ip.addr:6060;transport=tcp>;tag=007d7ff6a00e45fe15ffbb8ea6137e87
Call-ID: 0bbd8929-ae0f-123b-08b9-02e5070a49dd
CSeq: 56984975 INVITE
Contact: <sip:+919876543210#remote.gateway.ip.addr:17828;transport=TCP>
Supported: replaces
Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, INFO, UPDATE, NOTIFY, REFER
Content-Type: application/sdp
Content-Length: 199
v=0
o=host 322940 322941 IN IP4 remote.gateway.ip.addr
s=-
c=IN IP4 remote.gateway.ip.addr
t=0 0
m=audio 41860 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-11
a=ptime:20
SIP/2.0 200 OK
Via: SIP/2.0/TCP fs.ext.ip.addr;rport=57679;branch=z9hG4bKXyZrZU4jZUjve
From: <sip:0000000000#fs.ext.ip.addr>;tag=SmjU29t0HXt2g
To: <sip:+919876543210#remote.gateway.ip.addr:6060;transport=tcp>;tag=007d7ff6a00e45fe15ffbb8ea6137e87
Call-ID: 0bbd8929-ae0f-123b-08b9-02e5070a49dd
CSeq: 56984975 INVITE
Contact: <sip:+919876543210#remote.gateway.ip.addr:17828;transport=TCP>
Supported: replaces
Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, INFO, UPDATE, NOTIFY, REFER
Content-Type: application/sdp
Content-Length: 199
v=0
o=host 322940 322941 IN IP4 remote.gateway.ip.addr
s=-
c=IN IP4 remote.gateway.ip.addr
t=0 0
m=audio 41860 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-11
a=ptime:20
SIP/2.0 200 OK
Via: SIP/2.0/TCP fs.ext.ip.addr;rport=57679;branch=z9hG4bKXyZrZU4jZUjve
From: <sip:0000000000#fs.ext.ip.addr>;tag=SmjU29t0HXt2g
To: <sip:+919876543210#remote.gateway.ip.addr:6060;transport=tcp>;tag=007d7ff6a00e45fe15ffbb8ea6137e87
Call-ID: 0bbd8929-ae0f-123b-08b9-02e5070a49dd
CSeq: 56984975 INVITE
Contact: <sip:+919876543210#remote.gateway.ip.addr:17828;transport=TCP>
Supported: replaces
Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, INFO, UPDATE, NOTIFY, REFER
Content-Type: application/sdp
Content-Length: 199
v=0
o=host 322940 322941 IN IP4 remote.gateway.ip.addr
s=-
c=IN IP4 remote.gateway.ip.addr
t=0 0
m=audio 41860 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-11
a=ptime:20
SIP/2.0 200 OK
Via: SIP/2.0/TCP fs.ext.ip.addr;rport=57679;branch=z9hG4bKXyZrZU4jZUjve
From: <sip:0000000000#fs.ext.ip.addr>;tag=SmjU29t0HXt2g
To: <sip:+919876543210#remote.gateway.ip.addr:6060;transport=tcp>;tag=007d7ff6a00e45fe15ffbb8ea6137e87
Call-ID: 0bbd8929-ae0f-123b-08b9-02e5070a49dd
CSeq: 56984975 INVITE
Contact: <sip:+919876543210#remote.gateway.ip.addr:17828;transport=TCP>
Supported: replaces
Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, INFO, UPDATE, NOTIFY, REFER
Content-Type: application/sdp
Content-Length: 199
v=0
o=host 322940 322941 IN IP4 remote.gateway.ip.addr
s=-
c=IN IP4 remote.gateway.ip.addr
t=0 0
m=audio 41860 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-11
a=ptime:20
BYE sip:gw+airtel#fs.ext.ip.addr:5060;transport=tcp;gw=airtel SIP/2.0
Via: SIP/2.0/TCP remote.gateway.ip.addr:17828;branch=z9hG4bKe8b79e46b92fba58ddd0040c8952552b;rport
From: <sip:+919876543210#remote.gateway.ip.addr:6060;transport=tcp>;tag=007d7ff6a00e45fe15ffbb8ea6137e87
To: <sip:0000000000#fs.ext.ip.addr>;tag=SmjU29t0HXt2g
Call-ID: 0bbd8929-ae0f-123b-08b9-02e5070a49dd
CSeq: 56984976 BYE
Supported: replaces
Max-Forwards: 70
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/TCP remote.gateway.ip.addr:17828;branch=z9hG4bKe8b79e46b92fba58ddd0040c8952552b;rport=6060
From: <sip:+919876543210#remote.gateway.ip.addr:6060;transport=tcp>;tag=007d7ff6a00e45fe15ffbb8ea6137e87
To: <sip:0000000000#fs.ext.ip.addr>;tag=SmjU29t0HXt2g
Call-ID: 0bbd8929-ae0f-123b-08b9-02e5070a49dd
CSeq: 56984976 BYE
User-Agent: FreeSWITCH-mod_sofia/1.10.8-dev+git~20220427T172338Z~7e2d6384bc~64bit
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
Supported: timer, path, replaces
Content-Length: 0
Findings from SIP traces
External IP is correctly deduced through STUN and the same is being sent in the SIP messages.
For call through gateway, while the 200 OK for the INVITE is not being acknowledged by Freeswitch, the BYE sent from the remote gateway is being acknowledged.
For call to registered user on softphone, Freeswitch responds with SIP ACK when 200 OK is received for the invite.
Configurations already tried
Uncommenting the line setting param "aggressive-nat-detection" to "true" in the SIP profile did not make any difference.
Uncommenting the line setting param "enable-timer" to "false" in the SIP profile did not make any difference.
Any help or pointers to resolve this issue will be greatly appreciated.
Me and my team managed to fix the issue a couple of weeks ago and everything has been working fine since then. Sharing the details below to help others who face similar problems in the future.
I noticed that ACK timeout was not the only issue my Freeswitch installation faced. There was also no SIP BYE being sent when Freeswitch hangs up the call resulting in the remote end retaining the call. The BYE issue was affecting both inbound and outbound calls. This indicated that Freeswitch was failing to start any new SIP transaction like ACK, BYE etc.
Since the SIP trace enabled by sofia global siptrace on was not showing the ACK being sent, I was initially under the impression that this was a Freeswitch bug. However when I noticed that the SIP trace also did not show BYE being sent even though the call was ending in Freeswitch, it made me think in other directions.
That’s when I discovered that we can enable sofia stack debugging to see error messages within the stack. The command to do so is:
sofia loglevel all 9
Diagnosis
log_snippet.txt
fs_cli now showed that Freeswitch attempted to send the ACK but failed to establish a TCP socket connection with a connection refused error. Since the TCP socket itself was not established, the SIP message was never sent.
This happened since the source port of the 200 OK message was different from the port mentioned in the Contact header. The port in the Contact header is the port the remote gateway got through NAT. It appears that the remote gateway closes the TCP socket after the INVITE transaction ends once it sends a 200 OK. When Freeswitch attempts the next SIP transaction (ACK, BYE etc) on the IP and port advertised in the Contact header, it gets rejected by the remote firewall.
Solution
Rewrite the Contact header. Refer NDLB-connectile-dysfunction
I added the below variable to the gateway xml.
<variable name="sip-force-contact" value="NDLB-connectile-dysfunction"/>
I also defined the same in the vars.xml so that the same is applied for incoming calls too.
<X-PRE-PROCESS cmd="set" data="sip-force-contact=NDLB-connectile-dysfunction"/>
Doing this will make Freeswitch rewrite the Contact header IP and port to the whatever source port the request comes from. In my case, the Contact header gets rewritten to 6060 and thus the newer SIP transactions work fine.
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.
I'm trying to make Huawei 9000 HD Video Terminal MCU work with asterisk.
Huawei's mcu do not transmit any h264 video and refuses to play the video asterisk sends to it.
Sniffing with wireshark I saw the entire sip negotiation ( relevant traces below ) and the MCU simply rejects the video by putting
m=video 0 RTP/AVP 99
in the 200 OK.
Another issue is that MCU repeatedly sends an INFO request with a proprietary XML body format
Content-Type: application/media_control_hw+xml
Which asterisk replies with 415 Unsupported Media Type. Is this INFO request essential to start video session ?
I could not find any support from Huawei. Apparently it do not have any usable forum.
Any ideas ? Please help.
Asterisk -> MCU ( INVITE )
INVITE sip:mcu#192.168.7.59 SIP/2.0
Via: SIP/2.0/UDP 192.168.7.227:5060;branch=z9hG4bK25a4a145;rport
Max-Forwards: 70
From: "danflu-iphonebria" ;tag=as359f0bce
To:
Contact:
Call-ID: 646e2b425316ccd349b90eba3cf276de#192.168.7.227:5060
CSeq: 102 INVITE
User-Agent: Asterisk PBX SVN-branch-1.8-r402000M
Date: Tue, 29 Oct 2013 19:23:41 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Content-Type: application/sdp
Content-Length: 348
v=0
o=root 1448364882 1448364882 IN IP4 192.168.7.227
s=Asterisk PBX SVN-branch-1.8-r402000M
c=IN IP4 192.168.7.227
b=CT:384
t=0 0
m=audio 9676 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=ptime:20
a=sendrecv
m=video 8192 RTP/AVP 99
a=rtpmap:99 H264/90000
a=sendrecv
###
MCU -> Asterisk ( 200 OK )
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.7.227:5060;branch=z9hG4bK25a4a145;rport=5060
Call-ID: 646e2b425316ccd349b90eba3cf276de#192.168.7.227:5060
From: "danflu-iphonebria";tag=as359f0bce
To: ;tag=4qda40eh
CSeq: 102 INVITE
Contact: "mcu"
Allow: INVITE,ACK,BYE,CANCEL,UPDATE,OPTIONS,INFO,NOTIFY,PRACK,REFER
User-Agent: Huawei ViewPoint9000/9030-Release_11.2.13.26T
Content-Length: 245
Content-Type: application/sdp
v=0
o=huawei 1 0 IN IP4 192.168.7.59
s=-
c=IN IP4 192.168.7.59
b=CT:384
t=0 0
m=audio 10002 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
*m=video 0 RTP/AVP 99 *
###
MCU -> Asterisk INFO request
INFO sip:danflu-iphonebria#192.168.7.227:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.7.59:5060;branch=z9hG4bKlc4dje4ajgjh4lpjgjfca2lfj
Call-ID: 646e2b425316ccd349b90eba3cf276de#192.168.7.227:5060
From: ;tag=4qda40eh
To: "danflu-iphonebria";tag=as359f0bce
CSeq: 2 INFO
Contact: "mcu"
Max-Forwards: 70
Content-Length: 455
Content-Type: application/media_control_hw+xml
<?xml version="1.0" encoding="utf-8" ?>
<media_control xmlns="http://www.huawei.com/media-control" version="1.0">
<cap equ_type="term">
<anti_packet_loss>
<protocol>h264
</anti_packet_loss>
<anti_packet_loss2.0>
<protocol>h264
<stream_type>video_amc
</anti_packet_loss2.0>
<cisco_tip_cap>
<stream_type>video_amc
</cisco_tip_cap>
<arq_cap>
<media_type>video
</arq_cap>
</cap>
</media_control>
Disable on asterisk any codec except this one.
Yes, sure, SINGLE!!! VIDEO!!! CODEC IN SDP is essential for setup. MCU just not offer other choices, asterisk say it can't accept MCU's choice.
P.S. this is not programming question, post in admin support or contact vendor.
I am new to MjSip and I use MjUa for creating a client. I want to connect to a asterisk server. it support G.711 but I can not config my app.
I use this config:
media=audio 4000 rtp/avp {audio 0 PCMU 8000 160, audio 8 PCMA 8000 160}
but i still get 488 error
please help me. how change "MjUa" config file?
here is all message log:
INVITE sip:57#192.168.0.254:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.0.57:5060;rport;branch=z9hG4bK2bfdff77
Max-Forwards: 70
To: "Alice" <sip:57#192.168.0.254:5060>
From: "aziz" <sip:157#192.168.0.254>;tag=350164683297
Call-ID: 728007708208#192.168.0.57
CSeq: 1 INVITE
Contact: <sip:157#192.168.0.57>
Expires: 3600
User-Agent: mjsip 1.7
Content-Length: 141
Content-Type: application/sdp
v=0
o=157 0 0 IN IP4 192.168.0.57
s=-
c=IN IP4 192.168.0.57
t=0 0
m=audio 4000 rtp/avp 0 8
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
-----End-of-message-----
1365314026097: 10:23:46.097 Sun 07 Apr 2013, 192.168.0.254:5060/udp (519 bytes) received
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 192.168.0.57:5060;branch=z9hG4bK2bfdff77;received=192.168.0.57;rport=5060
From: "aziz" <sip:157#192.168.0.254>;tag=350164683297
To: "Alice" <sip:57#192.168.0.254:5060>;tag=as3f160681
Call-ID: 728007708208#192.168.0.57
CSeq: 1 INVITE
Server: FPBX-2.8.1(1.8.11.0)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="6e640e9a"
Content-Length: 0
-----End-of-message-----
1365314026107: 10:23:46.107 Sun 07 Apr 2013, 192.168.0.254:5060/udp (326 bytes) sent
ACK sip:57#192.168.0.254:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.0.57:5060;rport;branch=z9hG4bK2bfdff77
Max-Forwards: 70
To: "Alice" <sip:57#192.168.0.254:5060>;tag=as3f160681
From: "aziz" <sip:157#192.168.0.254>;tag=350164683297
Call-ID: 728007708208#192.168.0.57
CSeq: 1 ACK
User-Agent: mjsip 1.7
Content-Length: 0
-----End-of-message-----
1365314026151: 10:23:46.151 Sun 07 Apr 2013, 192.168.0.254:5060/udp (706 bytes) sent
INVITE sip:57#192.168.0.254:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.0.57:5060;rport;branch=z9hG4bK644461b7
Max-Forwards: 70
To: "Alice" <sip:57#192.168.0.254:5060>
From: "aziz" <sip:157#192.168.0.254>;tag=350164683297
Call-ID: 728007708208#192.168.0.57
CSeq: 2 INVITE
Contact: <sip:157#192.168.0.57>
Expires: 3600
User-Agent: mjsip 1.7
Authorization: Digest username="157", realm="asterisk", nonce="6e640e9a", uri="sip:57#192.168.0.254:5060", algorithm=MD5, response="84ff5e12b8325a153e09ac2e316f5b1f"
Content-Length: 141
Content-Type: application/sdp
v=0
o=157 0 0 IN IP4 192.168.0.57
s=-
c=IN IP4 192.168.0.57
t=0 0
m=audio 4000 rtp/avp 0 8
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
-----End-of-message-----
1365314026152: 10:23:46.152 Sun 07 Apr 2013, 192.168.0.254:5060/udp (450 bytes) received
SIP/2.0 488 Not acceptable here
Via: SIP/2.0/UDP 192.168.0.57:5060;branch=z9hG4bK644461b7;received=192.168.0.57;rport=5060
From: "aziz" <sip:157#192.168.0.254>;tag=350164683297
To: "Alice" <sip:57#192.168.0.254:5060>;tag=as3f160681
Call-ID: 728007708208#192.168.0.57
CSeq: 2 INVITE
Server: FPBX-2.8.1(1.8.11.0)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Content-Length: 0
-----End-of-message-----
1365314026155: 10:23:46.155 Sun 07 Apr 2013, 192.168.0.254:5060/udp (326 bytes) sent
ACK sip:57#192.168.0.254:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.0.57:5060;rport;branch=z9hG4bK644461b7
Max-Forwards: 70
To: "Alice" <sip:57#192.168.0.254:5060>;tag=as3f160681
From: "aziz" <sip:157#192.168.0.254>;tag=350164683297
Call-ID: 728007708208#192.168.0.57
CSeq: 2 ACK
User-Agent: mjsip 1.7
Content-Length: 0
-----End-of-message-----
A little late, but often times this is related to codec incompatibilities.
For anyone encountering this issue, they should check whether both sides (server and client) have at least one codes they can negotiate.
From the log posted:
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
It appears that G711 is requested but unavailable on the server side. Hence the server rejects the RTP channel.
I had the same error using a Snom 300 phone to contact an Asterisk server. Turning RTP encryption off on the phone worked for me.
On V7 firmware, this is in: "V7: Identities - RTP Settings(Section): RTP Encryption". Apparently, on V7, RTP encryption is turned on by default: http://wiki.snom.com/wiki/index.php/Settings/user_srtp
I don't know if the root cause is that the Asterisk server is misconfigured (I don't run it), but at least this worked around the problem.
For me, it was my VOIP provider's server-side setting expecting only encrypted connections. I forgot about it after I reverted to plaintext connections in the client.
I encountered this error in Zoiper5 Desktop application. The issue was resolved probably by setting RTCP Feedback-> OFF, previously I used "Compatibility mode", hence it is the most probable cause of 488 error. Also, I have changed the order of codecs to: G.711 mulaw; a-law; GSM FR; G.722 whereas moving OPUS codec to the least preferable spot codecs' order.
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