What's the redundant data in TCP packet? - linux

I am reading "Unix Network Programming" and tcpdump the packet generate by the example. The example is just send out a packet contain string "liha".
I read the TCP/IP RFC and found normal IP header is 20B. and normal TCP header except data is 24B.
So, there are 8B before string "liha" in the captured packet. Are "0121 3d2a 0120 b43e" useless?
11:00:51.690949 IP localhost.40163 > localhost.9877: Flags [P.], seq 94:99, ack 95, win 513, options [nop,nop,TS val 18955562 ecr 18920510], length 5
0x0000: 4500 0039 ddc6 4000 4006 5ef6 7f00 0001 E..9..#.#.^.....
0x0010: 7f00 0001 9ce3 2695 8465 e35c 8466 58ca ......&..e.\.fX.
0x0020: 8018 0201 fe2d 0000 0101 080a 0121 3d2a .....-.......!=*
0x0030: 0120 b43e 6c69 6861 0a ...>liha.


Those are the TCP options. And your analyzer already parsed them for you:
options [nop,nop,TS val 18955562 ecr 18920510],
They are generally important and used by communication sides to negotiate which extra enhancements can be used for the TCP connection.

Related

ISO - not getting appropriate response

I have used JPOS library for creating ISO message but I am not getting any response, The call which I have initiated is SIGN-ON. The code which i have implemented and request is mentioned below.
length 42
0x0000: 4500 005e 4448 4000 4006 8842 0a14 5140 E..^DH#.#..B..Q#
0x0010: 0a5f 085d 952e 30c8 5cdb c683 49e6 692d ._.]..0....I.i-
0x0020: 8018 01f6 6e60 0000 0101 080a 0775 0600 ....n`.......u..
0x0030: 889f a492 3038 3030 8220 0100 0000 0000 ....0800........
0x0040: 0400 0000 0000 0000 3132 3234 3139 3035 ........12241905
0x0050: 3136 3132 3033 3437 3030 3130 3033 16120347001003
channel.setHost("xx.xx.xx.xx", xxxxx);
channel.connect();
ISOMsg isoMsg = new ISOMsg();
isoMsg.setPackager(packager);
isoMsg.setMTI("0800");
isoMsg.set(7, "1224190516");
isoMsg.set(11, "120347");
isoMsg.set(24, "001");
isoMsg.set(70, "003");
byte[] send_PackedRequestData = isoMsg.pack();
channel.send(send_PackedRequestData);```

For once, you have to set the packager to the channel and send the isoMsg object not the bytes:
channel.setPackager(packager);
...
channel.send(isoMsg);
Additionally I don't see you calling channel.receive();
And if you did there are many possible reasons why you wouldn't receive a response, among others:
Unmatched channel/packager between client and server
Server not responding for some internal error

Is there a way to check the Socket Priority with Wireshark or Tcpdump?

I am doing some changes in the SO_PRIORITY of the socket that sends UDP packets, using the command setsockopt, is there a way to see that changes with Wireshark or Tcpdump.
I read that can be DSF (Differentiated Services Field), but I am not sure because when I make the changes I see that this field is 00.
I am running a Linux Mint 19.3

It is part of the 802.1Q header. For ex:
> 802.1Q Virtual LAN, PRI: 5, DEI: 0, ID: 4
101. .... .... .... = Priority: Voice, < 10ms latency and jitter (5)
...0 .... .... .... = DEI: Ineligible
.... 0000 0000 0100 = ID: 4
Type: IPv6 (0x86dd)

Decode raw Scapy data to human readable

I'm trying to switch to using Scapy instead of Wireshark, but am having trouble decoding the data I'm getting. In Wireshark I can easily see the last layer for filtered packets labeled as "Distributed Interactive Simulation", but in Scapy the last layer is "Raw". I'm trying to get the data from this layer in the same human readable format. So far I've gotten:
# Capture with Scapy
from scapy.all import sniff
capture = sniff(filter="dst 10.6.255.255 and port 3000", count=5)
packet = capture[0]
raw = pkt.lastlayer()
print(raw)
<Raw load='\x068\x14\x05L\x88nK\x00x\x00\x00\x00\x94\x08\x88\x00\x00\xff\xff\xff\xff\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x00\x9f\x00\x00\x02 \x00\x01sj\x9b\xf4\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x04p\x00\x08\x00\x00\x00\x00\x00\x00d\xe9Y<\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x04\x8c\x00\x00\x113\x00\x00\x00\x01\x00\x02\x0c\x00\x00\x00\x01\x02\x00\x00\x00\x041187\x00\x00\x00\x00\x00' |>
Could someone show me how to make this human readable?

First, you have an error in your script. raw = pkt.lastlayer() should be raw = packet.lastlayer().
Try adding print(packet.show()) to your script for a more readable format which will give you something similar to this:
###[ Ethernet ]###
dst = 94:c6:91:1c:68:c3
src = 94:c6:91:1c:68:1d
type = 0x800
###[ IP ]###
version = 4
ihl = 5
tos = 0x0
len = 84
id = 49689
flags = DF
frag = 0
ttl = 64
proto = icmp
chksum = 0x1938
src = 192.168.111.4
dst = 192.168.111.2
\options \
###[ ICMP ]###
type = echo-request
code = 0
chksum = 0xb468
id = 0x6d3
seq = 0xab
###[ Raw ]###
load = '\x0e\x85\x96[\x00\x00\x00\x00\xd2e\x06\x00\x00\x00\x00\x00\x10\x11\x12\x13\x14\x15\x16\x17\x18\x19\x1a\x1b\x1c\x1d\x1e\x1f !"#$%&\'()*+,-./01234567'
None
You can also use hexdump command to show the raw load in a more readable format.
from scapy.utils import hexdump
raw = packet.lastlayer()
hexdump(raw)
Which will output something like this:
0000 D091965B0000000080FD0E0000000000 ...[............
0010 101112131415161718191A1B1C1D1E1F ................
0020 202122232425262728292A2B2C2D2E2F !"#$%&'()*+,-./
0030 3031323334353637 01234567
0000 063814054CC2886E4B0078000000C294 .8..L..nK.x.....
0010 08C2880000C3BFC3BFC3BFC3BF000000 ................
0020 00000000000000000000000000000100 ................
0030 0000C29F000002200001736AC29BC3B4 ....... ..sj....
0040 00000000000000000000000470000800 ............p...
0050 000000000064C3A9593C000000000000 .....d..Y<......
0060 0000000004C28C000011330000000100 ..........3.....
0070 020C0000000102000000043131383700 ...........1187.
0080 00000000 ....

readable_payload = bytes(packet[TCP].payload).decode('UTF8','replace')

Sounds is bad with asterisk

I am having an odd problem.
I have made sip users and extensions.
Calling between them works like a charm.
The quality of sound seems to be really of… it sounds horrible.
It’s like I can almost not hear the person on the other side.
What would be the problem to a case like this?
I think (correct me if I am wrong) I did something wrong with my settings.
My settings are as followed;
sip.conf
; SIP Configuration for Asterisk
context => phones ; Default context for incoming calls. Defaults to 'default'
allowguest => yes ; Allow or reject guest calls (default is yes)
allowoverlap => yes ; Disable overlap dialing support. (Default is yes)
tcpenable => yes ; Enable server for incoming TCP connections (default is no)
tcpbindaddr => 0.0.0.0:15060 ; IP address for TCP server to bind to (0.0.0.0 binds to all interfaces)
udpbindaddr => 0.0.0.0:15060 ; IP address to bind UDP listen socket to (0.0.0.0 binds to all)
transport => udp ; Set the default transports. The order determines the primary default transport.
nat => force_rport,comedia
localnet => 172.31.27.202/255.255.0.0 ; NAT SUPPORT
externaddr =>54.178.185.181 ; NAT SUPPORT
media_address => 54.178.185.181 ; NAT SUPPORT
directmedia => no
srvlookup => yes ; Enable DNS SRV lookups on outbound calls
language => ja ; Default language setting for all users/peers
rtcachefriends => yes ; realtime database settings
rtautoclear => yes ; realtime database settings
;------------------------------ quality settings --------------------------
tos_sip => cs3 ; Sets TOS for SIP packets.
tos_audio => ef ; Sets TOS for RTP audio packets.
cos_sip => 3 ; Sets 802.1p priority for SIP packets.
cos_audio => 5 ; Sets 802.1p priority for RTP audio packets.
;------------------------------ JITTER BUFFER CONFIGURATION --------------------------
jbenable => no ; Enables the use of a jitterbuffer on the receiving side of a
; SIP channel. Defaults to "no". An enabled jitterbuffer will
; be used only if the sending side can create and the receiving
; side can not accept jitter. The SIP channel can accept jitter,
; thus a jitterbuffer on the receive SIP side will be used only
; if it is forced and enabled.
; (和訳)SIPチャネルの受信側でジッタバッファを使用できるようにします。
; デフォルトは「いいえ」です。有効なジッタバッファは、送信側が作成でき、
; 受信側がジッタを受け入れることができない場合にのみ使用されます。
; SIPチャネルはジッタを受け入れることができます。
; したがって、受信SIP側のジッタバッファは、
; 強制的に有効化されている場合にのみ使用されます。
jbforce => no ; Forces the use of a jitterbuffer on the receive side of a SIP
; channel. Defaults to "no".
; (和訳)SIPチャネルの受信側でジッタバッファを強制的に使用します。
; デフォルトは「いいえ」です。
jbmaxsize => 200 ; Max length of the jitterbuffer in milliseconds.
; (和訳)ジッタバッファの最大長（ミリ秒単位）。
jbresyncthreshold => 1000 ; Jump in the frame timestamps over which the jitterbuffer is
; resynchronized. Useful to improve the quality of the voice, with
; big jumps in/broken timestamps, usually sent from exotic devices
; and programs. Defaults to 1000.
; (和訳)ジッタバッファが再同期されるフレームタイムスタンプ内をジャンプします。
; 通常はエキゾチックなデバイスやプログラムから送信される、
; 壊れたタイムスタンプの大きなジャンプで、音声の品質を向上させるのに便利です。
; デフォルトは1000です。
jbimpl => fixed ; Jitterbuffer implementation, used on the receiving side of a SIP
; channel. Two implementations are currently available - "fixed"
; (with size always equals to jbmaxsize) and "adaptive" (with
; variable size, actually the new jb of IAX2). Defaults to fixed.
; (和訳)SIPチャネルの受信側で使用されるJitterbuffer実装。
; 現在のところ、 "fixed"（サイズは常にjbmaxsizeに等しい）と
; "adaptive"（可変サイズで、実際はIAX2の新しいjb）という
; 2つの実装が利用可能です。デフォルトは固定です。
jbtargetextra => 40 ; This option only affects the jb when 'jbimpl = adaptive' is set.
; The option represents the number of milliseconds by which the new jitter buffer
; will pad its size. the default is 40, so without modification, the new
; jitter buffer will set its size to the jitter value plus 40 milliseconds.
; increasing this value may help if your network normally has low jitter,
; but occasionally has spikes.
; (和訳)このオプションは、 'jbimpl = adaptive'が設定されている場合に
; のみjbに影響します。このオプションは、新しいジッタバッファがその
; サイズを埋めるまでのミリ秒数を表します。デフォルトは40ですので、
; 変更なしでは、新しいジッタバッファはジッタ値に40ミリ秒を加えたサイズに設定されます。
; この値を大きくすると、ネットワークのジッタが通常は低くなりますが、
; 時にはスパイクが発生することがあります。
jblog => yes ; Enables jitterbuffer frame logging. Defaults to "no".
; (和訳)ジッタバッファフレームロギングをイネーブルにします。
; デフォルトは「いいえ」です。
;--------------------------- RTP timers ----------------------------------------------------
; These timers are currently used for both audio and video streams. The RTP timeouts
; are only applied to the audio channel.
; The settings are settable in the global section as well as per device.
; (和訳)これらのタイマーは、現在、オーディオストリームとビデオストリームの両方に使用されています。
; RTPタイムアウトはオーディオチャネルにのみ適用されます。
; 設定は、デバイスごとにグローバルセクションでも設定できます。
;
rtptimeout => 5 ; Terminate call if 60 seconds of no RTP or RTCP activity
; on the audio channel
; when we're not on hold. This is to be able to hangup
; a call in the case of a phone disappearing from the net,
; like a powerloss or grandma tripping over a cable.
; (和訳)保留されていないときに、オーディオチャネルでRTPまたはRTCPの
; アクティビティがない場合は、60秒間コールを終了します。
; これは、電力損失やおばあちゃんがケーブルを乗り越えるように、
; ネットから消えていく電話の場合に電話を切ることができるようにするためです。
;rtpholdtimeout => 300 ; Terminate call if 300 seconds of no RTP or RTCP activity
; on the audio channel
; when we're on hold (must be > rtptimeout)
; (和訳)保留中の場合、オーディオチャネルでRTPまたはRTCPのアクティビティがない状態で
; 300秒が経過すると、コールを終了します。 （rtptimeoutより大きくなければいけません）
;rtpkeepalive => <secs> ; Send keepalives in the RTP stream to keep NAT open
; (default is off - zero)
; (和訳)キープアライブをRTPストリームに送信して、NATを開いたままにします
; （デフォルトはオフ)
;--------------------------------codec---------------------------------------------------
;音声コーデックのGSM固定 作業者：渋谷 2018/06/26
disallow => all
allow => ulaw,alaw,gsm
;-----------------------------------------------------------------------------------
;セッション設定 作業者：あすか柴田 2018/07/23
session-expires => 1800
session-refresher => uac
[ACCOUNT-COMMON](!)
type=friend
nat=force_rport,comedia
secret=123456
canreinvite=no
dtmfmode=auto
callgroup=1
pickupgroup=1
context=phones
[1000](ACCOUNT-COMMON)
[1001](ACCOUNT-COMMON)
[1002](ACCOUNT-COMMON)
[1003](ACCOUNT-COMMON)
[1004](ACCOUNT-COMMON)
[1005](ACCOUNT-COMMON)
[1006](ACCOUNT-COMMON)
[1007](ACCOUNT-COMMON)
[1008](ACCOUNT-COMMON)
[1009](ACCOUNT-COMMON)
[1010](ACCOUNT-COMMON)
[1011](ACCOUNT-COMMON)
[1012](ACCOUNT-COMMON)
[1013](ACCOUNT-COMMON)
[1014](ACCOUNT-COMMON)
[1015](ACCOUNT-COMMON)
[1016](ACCOUNT-COMMON)
[1017](ACCOUNT-COMMON)
[1018](ACCOUNT-COMMON)
[1019](ACCOUNT-COMMON)
[1020](ACCOUNT-COMMON)
My extensions.conf
[phones]
exten => _X0XX,1,NoOp(First Line)
same => n,dumpchan()
same => n,NoOp(Second Line)
same => n,Dial(SIP/${CALLERID(dnid)}/${CALLERID(dnid)})
same => n,NoOp(dialstatus=${DIALSTATUS},causecode=${HANGUPCAUSE})
same => n,Hangup
The debug log from the client when I call
SIP Debugging enabled
<--- SIP read from UDP:111.108.30.208:62566 --->
<------------->
Really destroying SIP dialog 'e02d510346cd4db58cc2869ea3e85542' Method: REGISTER
<--- SIP read from UDP:111.108.30.208:62383 --->
<------------->
Really destroying SIP dialog '31f2d3b15ce749c38149a4443ceecc7b' Method: REGISTER
<--- SIP read from UDP:111.108.30.208:62566 --->
INVITE sip:1000#54.178.185.181:15060 SIP/2.0
Via: SIP/2.0/UDP 111.108.30.208:62566;rport;branch=z9hG4bKPj12729c1e32264a09a7651de39104bfa2
Max-Forwards: 70
From: sip:1000#192.168.80.123;tag=967faa9ed6f74b0189abfce3da60ba01
To: sip:1000#54.178.185.181
Contact: <sip:1000#111.108.30.208:62566;ob>
Call-ID: 188d3fbfedf0444e9e528ab83ea38416
CSeq: 30964 INVITE
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
Supported: replaces, 100rel, timer, norefersub
Session-Expires: 1800
Min-SE: 90
User-Agent: PJSUA v2.4 win32-6.2/i386/msvc-15.0
Content-Type: application/sdp
Content-Length: 482
v=0
o=- 3741526335 3741526335 IN IP4 192.168.100.231
s=pjmedia
b=AS:84
t=0 0
a=X-nat:0
m=audio 4000 RTP/AVP 98 97 99 104 3 0 8 9 96
c=IN IP4 192.168.100.231
b=TIAS:64000
a=rtcp:4001 IN IP4 192.168.100.231
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:9 G722/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
<------------->
--- (15 headers 22 lines) ---
Sending to 111.108.30.208:62566 (NAT)
Sending to 111.108.30.208:62566 (NAT)
Using INVITE request as basis request - 188d3fbfedf0444e9e528ab83ea38416
Found peer '1000' for '1000' from 111.108.30.208:62566
<--- Reliably Transmitting (NAT) to 111.108.30.208:62566 --->
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 111.108.30.208:62566;branch=z9hG4bKPj12729c1e32264a09a7651de39104bfa2;received=111.108.30.208;rport=62566
From: sip:1000#192.168.80.123;tag=967faa9ed6f74b0189abfce3da60ba01
To: sip:1000#54.178.185.181;tag=as77fea572
Call-ID: 188d3fbfedf0444e9e528ab83ea38416
CSeq: 30964 INVITE
Server: Asterisk PBX 13.22.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="35993b20"
Content-Length: 0
<------------>
Scheduling destruction of SIP dialog '188d3fbfedf0444e9e528ab83ea38416' in 6400 ms (Method: INVITE)
<--- SIP read from UDP:111.108.30.208:62566 --->
ACK sip:1000#54.178.185.181:15060 SIP/2.0
Via: SIP/2.0/UDP 111.108.30.208:62566;rport;branch=z9hG4bKPj12729c1e32264a09a7651de39104bfa2
Max-Forwards: 70
From: sip:1000#192.168.80.123;tag=967faa9ed6f74b0189abfce3da60ba01
To: sip:1000#54.178.185.181;tag=as77fea572
Call-ID: 188d3fbfedf0444e9e528ab83ea38416
CSeq: 30964 ACK
Content-Length: 0
<------------->
--- (8 headers 0 lines) ---
<--- SIP read from TCP:111.108.30.208:63852 --->
INVITE sip:1000#54.178.185.181:15060 SIP/2.0
Via: SIP/2.0/TCP 192.168.100.231:62150;rport;branch=z9hG4bKPjcf39eb0d9b62487f9d334f67373ce98d;alias
Max-Forwards: 70
From: sip:1000#192.168.80.123;tag=967faa9ed6f74b0189abfce3da60ba01
To: sip:1000#54.178.185.181
Contact: <sip:1000#111.108.30.208:62566;ob>
Call-ID: 188d3fbfedf0444e9e528ab83ea38416
CSeq: 30965 INVITE
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
Supported: replaces, 100rel, timer, norefersub
Session-Expires: 1800
Min-SE: 90
User-Agent: PJSUA v2.4 win32-6.2/i386/msvc-15.0
Authorization: Digest username="1000", realm="asterisk", nonce="35993b20", uri="sip:1000#54.178.185.181:15060", response="e5095bf9a92eeee6668d831f904e7cb1", algorithm=MD5
Content-Type: application/sdp
Content-Length: 482
v=0
o=- 3741526335 3741526335 IN IP4 192.168.100.231
s=pjmedia
b=AS:84
t=0 0
a=X-nat:0
m=audio 4000 RTP/AVP 98 97 99 104 3 0 8 9 96
c=IN IP4 192.168.100.231
b=TIAS:64000
a=rtcp:4001 IN IP4 192.168.100.231
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:9 G722/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
<------------->
--- (16 headers 22 lines) ---
Sending to 111.108.30.208:63852 (NAT)
Using INVITE request as basis request - 188d3fbfedf0444e9e528ab83ea38416
Found peer '1000' for '1000' from 111.108.30.208:63852
== Using SIP RTP TOS bits 184
== Using SIP RTP CoS mark 5
Found RTP audio format 98
Found RTP audio format 97
Found RTP audio format 99
Found RTP audio format 104
Found RTP audio format 3
Found RTP audio format 0
Found RTP audio format 8
Found RTP audio format 9
Found RTP audio format 96
Found audio description format speex for ID 98
Found audio description format speex for ID 97
Found audio description format speex for ID 99
Found audio description format iLBC for ID 104
Found audio description format GSM for ID 3
Found audio description format PCMU for ID 0
Found audio description format PCMA for ID 8
Found audio description format G722 for ID 9
Found audio description format telephone-event for ID 96
Capabilities: us - (ulaw|alaw|gsm), peer - audio=(ulaw|gsm|alaw|g722|speex|speex16|speex32|ilbc)/video=(nothing)/text=(nothing), combined - (ulaw|alaw|gsm)
Non-codec capabilities (dtmf): us - 0x1 (telephone-event|), peer - 0x1 (telephone-event|), combined - 0x1 (telephone-event|)
> 0x7fd8300072c0 -- Strict RTP learning after remote address set to: 192.168.100.231:4000
Peer audio RTP is at port 192.168.100.231:4000
Looking for 1000 in phones (domain 54.178.185.181)
sip_route_dump: route/path hop: <sip:1000#111.108.30.208:62566;ob>
<--- Transmitting (NAT) to 111.108.30.208:63852 --->
SIP/2.0 100 Trying
Via: SIP/2.0/TCP 192.168.100.231:62150;branch=z9hG4bKPjcf39eb0d9b62487f9d334f67373ce98d;alias;received=111.108.30.208;rport=63852
From: sip:1000#192.168.80.123;tag=967faa9ed6f74b0189abfce3da60ba01
To: sip:1000#54.178.185.181
Call-ID: 188d3fbfedf0444e9e528ab83ea38416
CSeq: 30965 INVITE
Server: Asterisk PBX 13.22.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Session-Expires: 1800;refresher=uac
Contact: <sip:1000#54.178.185.181:15060;transport=tcp>
Content-Length: 0
<------------>
-- Executing [1000#phones:1] NoOp("SIP/1000-00000004", "First Line") in new stack
-- Executing [1000#phones:2] DumpChan("SIP/1000-00000004", "") in new stack
Dumping Info For Channel: SIP/1000-00000004:
================================================================================
Info:
Name= SIP/1000-00000004
Type= SIP
UniqueID= 1532505135.6
LinkedID= 1532505135.6
CallerIDNum= 1000
CallerIDName= (N/A)
ConnectedLineIDNum= (N/A)
ConnectedLineIDName=(N/A)
DNIDDigits= 1000
RDNIS= (N/A)
Parkinglot= default
Language= ja
State= Ring (4)
Rings= 0
NativeFormat= (ulaw)
WriteFormat= ulaw
ReadFormat= ulaw
RawWriteFormat= ulaw
RawReadFormat= ulaw
WriteTranscode= No
ReadTranscode= No
1stFileDescriptor= 29
Framesin= 0
Framesout= 0
TimetoHangup= 0
ElapsedTime= 0h0m0s
BridgeID= (Not bridged)
Context= phones
Extension= 1000
Priority= 2
CallGroup= 1
PickupGroup= 1
Application= DumpChan
Data= (Empty)
Blocking_in= (Not Blocking)
Variables:
SIPCALLID=188d3fbfedf0444e9e528ab83ea38416
SIPDOMAIN=54.178.185.181
SIPURI=sip:1000#111.108.30.208:62566
================================================================================
-- Executing [1000#phones:3] NoOp("SIP/1000-00000004", "Second Line") in new stack
-- Executing [1000#phones:4] Dial("SIP/1000-00000004", "SIP/1000/1000") in new stack
== Using SIP RTP TOS bits 184
== Using SIP RTP CoS mark 5
Audio is at 25572
Adding codec ulaw to SDP
Adding codec alaw to SDP
Adding codec gsm to SDP
Adding non-codec 0x1 (telephone-event) to SDP
Reliably Transmitting (NAT) to 111.108.30.208:62566:
INVITE sip:1000#111.108.30.208 SIP/2.0
Via: SIP/2.0/UDP 54.178.185.181:15060;branch=z9hG4bK770f26db;rport
Max-Forwards: 70
From: <sip:1000#54.178.185.181:15060>;tag=as14588959
To: <sip:1000#111.108.30.208>
Contact: <sip:1000#54.178.185.181:15060>
Call-ID: 3538e60b5e8c2c1b66ef00297fd218e0#54.178.185.181:15060
CSeq: 102 INVITE
User-Agent: Asterisk PBX 13.22.0
Date: Wed, 25 Jul 2018 07:52:15 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Content-Type: application/sdp
Content-Length: 303
v=0
o=root 1946525208 1946525208 IN IP4 54.178.185.181
s=Asterisk PBX 13.22.0
c=IN IP4 54.178.185.181
t=0 0
m=audio 25572 RTP/AVP 0 8 3 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv
---
-- Called SIP/1000/1000
<--- SIP read from UDP:111.108.30.208:62566 --->
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 54.178.185.181:15060;rport=15060;received=54.178.185.181;branch=z9hG4bK770f26db
Call-ID: 3538e60b5e8c2c1b66ef00297fd218e0#54.178.185.181:15060
From: <sip:1000#54.178.185.181>;tag=as14588959
To: <sip:1000#111.108.30.208>
CSeq: 102 INVITE
Content-Length: 0
<------------->
--- (7 headers 0 lines) ---
[Jul 25 16:52:15] NOTICE[1088]: chan_sip.c:15753 sip_reregister: -- Re-registration for 53065174#okj.sip.0038.net
REGISTER 12 headers, 0 lines
Reliably Transmitting (NAT) to 61.213.230.145:5060:
REGISTER sip:okj.sip.0038.net SIP/2.0
Via: SIP/2.0/UDP 54.178.185.181:15060;branch=z9hG4bK0b40ee91;rport
Max-Forwards: 70
From: <sip:53065174#okj.sip.0038.net>;tag=as7641fec7
To: <sip:53065174#okj.sip.0038.net>
Call-ID: 1fa69de43da6b2d9011b348e26cb4c7b#127.0.0.1
CSeq: 134 REGISTER
Supported: replaces, timer
User-Agent: Asterisk PBX 13.22.0
Authorization: Digest username="53065174", realm="okj.sip.0038.net", algorithm=MD5, uri="sip:okj.sip.0038.net", nonce="0ad266c5", response="d17a1a4a0db40775e77eeb0fcbc6581a"
Expires: 120
Contact: <sip:s#54.178.185.181:15060>
Content-Length: 0
---
<--- SIP read from UDP:61.213.230.145:5060 --->
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 54.178.185.181:15060;branch=z9hG4bK0b40ee91;rport
From: <sip:53065174#okj.sip.0038.net>;tag=as7641fec7
To: <sip:53065174#okj.sip.0038.net>;tag=as32fa296b
Call-ID: 1fa69de43da6b2d9011b348e26cb4c7b#127.0.0.1
CSeq: 134 REGISTER
WWW-Authenticate: Digest algorithm=MD5, realm="okj.sip.0038.net", nonce="2820b83b"
Content-Length: 0
<------------->
--- (8 headers 0 lines) ---
Responding to challenge, registration to domain/host name okj.sip.0038.net
REGISTER 12 headers, 0 lines
Reliably Transmitting (NAT) to 61.213.230.145:5060:
REGISTER sip:okj.sip.0038.net SIP/2.0
Via: SIP/2.0/UDP 54.178.185.181:15060;branch=z9hG4bK34214824;rport
Max-Forwards: 70
From: <sip:53065174#okj.sip.0038.net>;tag=as7641fec7
To: <sip:53065174#okj.sip.0038.net>
Call-ID: 1fa69de43da6b2d9011b348e26cb4c7b#127.0.0.1
CSeq: 135 REGISTER
Supported: replaces, timer
User-Agent: Asterisk PBX 13.22.0
Authorization: Digest username="53065174", realm="okj.sip.0038.net", algorithm=MD5, uri="sip:okj.sip.0038.net", nonce="2820b83b", response="4af3e85f4d165cb5ac9a9fa697a98438"
Expires: 120
Contact: <sip:s#54.178.185.181:15060>
Content-Length: 0
---
<--- SIP read from UDP:61.213.230.145:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 54.178.185.181:15060;branch=z9hG4bK34214824;rport
From: <sip:53065174#okj.sip.0038.net>;tag=as7641fec7
To: <sip:53065174#okj.sip.0038.net>;tag=as32fa296b
Call-ID: 1fa69de43da6b2d9011b348e26cb4c7b#127.0.0.1
CSeq: 135 REGISTER
Expires: 120
Contact: <sip:s#54.178.185.181:15060>;expires=120
Date: Wed, 25 Jul 2018 07:52:15 GMT
Content-Length: 0
<------------->
There doesn’t seem to be any errors in the log files
What am I missing here?
How is it possible that this problem comes up.
I personally thought it has something to do with the codex,
but after hours of searching, I don’t really know it anymore.
Thank you for your input
It’s highly appreciated.
Wesley

Try add to sip.conf to ACCOUNT-COMMON section next options.
disallow=all
allow=alaw
allow=ulaw
First INVITE contain "speex" codec initiate to.

IPv6 encapsuling on Azure ILPIP

Use of IPv6 tunnels (like tunnelbroker.net) is possible on Azure VM, via ILPIP (Instance Level Public IP)?
I tried to use it, but I don't get replies for ping packets to IPv6 gateway.
Internet Protocol Version 4, Src: 100.90.204.79, Dst: 216.66.84.46
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes
Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
0000 00.. = Differentiated Services Codepoint: Default (0)
.... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
Total Length: 124
Identification: 0x33d7 (13271)
Flags: 0x02 (Don't Fragment)
0... .... = Reserved bit: Not set
.1.. .... = Don't fragment: Set
..0. .... = More fragments: Not set
Fragment offset: 0
Time to live: 255
Protocol: IPv6 (41)
Header checksum: 0xea66 [validation disabled]
[Good: False]
[Bad: False]
Source: 100.90.204.79
Destination: 216.66.84.46
[Source GeoIP: Unknown]
[Destination GeoIP: Unknown]
Internet Protocol Version 6, Src: 2001:470:1f14:105a::2, Dst: 2001:470:1f14:105a::1
0110 .... = Version: 6
.... 0000 0000 .... .... .... .... .... = Traffic class: 0x00 (DSCP: CS0, ECN: Not-ECT)
.... 0000 00.. .... .... .... .... .... = Differentiated Services Codepoint: Default (0)
.... .... ..00 .... .... .... .... .... = Explicit Congestion Notification: Not ECN-Capable Transport (0)
.... .... .... 1001 0111 0111 0110 1010 = Flowlabel: 0x0009776a
Payload length: 64
Next header: ICMPv6 (58)
Hop limit: 64
Source: 2001:470:1f14:105a::2
Destination: 2001:470:1f14:105a::1
[Source GeoIP: Unknown]
[Destination GeoIP: Unknown]
Internet Control Message Protocol v6
Type: Echo (ping) request (128)
Code: 0
Checksum: 0xd3f8 [correct]
Identifier: 0x5016
Sequence: 1
[No response seen]
[Expert Info (Warn/Sequence): No response seen to ICMPv6 request in frame 212]
[No response seen to ICMPv6 request in frame 212]
[Severity level: Warn]
[Group: Sequence]
Data (56 bytes)
Data: 8bb5ed56000000006ed40d00000000001011121314151617...
[Length: 56]
I suspect that Azure is rejecting IPv4 protocol 41, am I correct?

The following is documented:
Microsoft has played a leading role in helping customers to smoothly transition from IPv4 to IPv6 for the past several years. To date, Microsoft has built IPv6 support into many of its products and solutions like Windows 8 and Windows Server 2012 R2. Microsoft is committed to expanding the worldwide capabilities of the Internet through IPv6 and enabling a variety of valuable and exciting scenarios, including peer-to-peer and mobile applications. The foundational work to enable IPv6 in the Azure environment is well underway. However, we are unable to share a date when IPv6 support will be generally available at this time.

Resources