[Problem] Snom 320 basic SiP Konfiguration (an Vodafon VoIP)

[koyaanisqatsi]

Bis auf die Letzte Ausgabe im SIP Protokoll, da da schon wieder die lokale NAT IPv4 in Contact: auftaucht, siehts eigentlich gut aus.

Übrigens: 401 benutzt der SIP Server um zur Authorisierung aufzufordern, siehe: WWW-Authenticate:
Erst wenn der Klient ( das SNOM ) darauf richtig antwortet ( Authorization: ) wird/ist der registriert.

Warum das jetzt so rumzickt, kann ich nur vermuten.
Vielleicht ist dein eingetragener STUN Server ungeeignet?
Du kannst aber jeden Anderen nehmen den du findest und einigermassen vertrauen kannst.
Nur funktionieren muss er
...die Wahl des STUN Servers steht dir absolut frei.

Check das auch noch mal mit dem SNOM 320 aus.

Codecliste
Deine sieht sehr lang aus*, und wenn du nicht wirklich weisst was da benötigt wird, fang mal mit den Kompatibelsten an...
Codecliste höchste Kompatibilität: pcma, telephone-event
( pcma = europaüblich )
Wenn das dann nicht mehr abstürzt/rebootet, dann...
Codecliste mit HD Priorität: g722, pcma, telephone-event
...und HD testen, also wenn es grundsätzlich funktioniert.

 

[Oekel]

Ich verzeichne einen Teilerfolg
Beide Nummern konnten registriert werden

Hier schnell das DIFF zu den Standardeinstellungen....

This XML file does not appear to have any style information associated with it. The document tree is shown below.
<settings>
<phone-settings e="2">
<language perm="">Deutsch</language>
<setting_server perm="RW">http://provisioning.snom.com/snom821/snom821.php?mac={mac}</setting_server>
<ip_adr perm="RW">192.168.1.12</ip_adr>
<netmask perm="RW">255.255.255.0</netmask>
<dns_server1 perm="RW">192.168.1.11</dns_server1>
<dns_server2 perm="RW">88.134.228.225</dns_server2>
<gateway perm="RW">192.168.1.1</gateway>
<utc_offset perm="">3600</utc_offset>
<system_time perm="">1646310708</system_time>
<http_user perm="">administrator</http_user>
<http_pass perm=""/>
<dst perm="">3600 03.05.07 02:00:00 10.05.07 03:00:00</dst>
<timezone perm="">GER+1</timezone>
<active_line perm="">2</active_line>
<admin_mode_password perm=""/>
<tone_scheme perm="">GER</tone_scheme>
<update_host_f perm="RW"/>
<web_language perm="">Deutsch</web_language>
<firmware_version perm="">snom821-SIP 8.7.5.35</firmware_version>
<use_hidden_tags perm="">on</use_hidden_tags>
<uboot_version perm="">SPEAr300 SNOM 1.4</uboot_version>
<lastexit perm="">term 11 2022-03-03 10:34:53.798</lastexit>
<laststate perm="">29</laststate>
<lastmethod perm="">display</lastmethod>
<lastkey perm="">ENTER</lastkey>
<swupd_failed perm="RW"/>
<was_never_registered perm="">off</was_never_registered>
<dhcp_v6 perm="">autoconf</dhcp_v6>
<user_active idx="1" perm="">on</user_active>
<user_realname idx="1" perm="">hb1</user_realname>
<user_realname idx="2" perm="">hb2</user_realname>
<user_name idx="1" perm="">+49421xxxxxx0</user_name>
<user_name idx="2" perm="">+49421xxxxxx6</user_name>
<user_host idx="1" perm="">sip.kabelfon.vodafone.de</user_host>
<user_host idx="2" perm="">sip.kabelfon.vodafone.de</user_host>
<user_pname idx="1" perm="">2xxxxxx3</user_pname>
<user_pname idx="2" perm="">2xxxxxx3</user_pname>
<user_pass idx="1" perm=""/>
<user_pass idx="2" perm=""/>
<user_q idx="2" perm="">1.0</user_q>
<user_srtp idx="2" perm="">off</user_srtp>
<user_descr_contact idx="1" perm="">off</user_descr_contact>
<user_descr_contact idx="2" perm="">off</user_descr_contact>
<user_uid idx="1" perm="">94429c6c-ddd5-43ec-800c-000413487E2A</user_uid>
<user_uid idx="2" perm="">94429c6c-ddd5-43ec-800c-000413487E2A</user_uid>
<user_sipusername_as_line idx="2" perm="">on</user_sipusername_as_line>
<user_shared_line idx="2" perm="">on</user_shared_line>
<user_dp_exp idx="1" perm=""> </user_dp_exp>
<user_dp_exp idx="2" perm=""> 0049 0421</user_dp_exp>
<user_ringer idx="1" perm="">Ringer10</user_ringer>
<user_outbound idx="1" perm="">sip.kabelfon.vodafone.de</user_outbound>
<user_outbound idx="2" perm="">sip.kabelfon.vodafone.de</user_outbound>
<stun_server idx="1" perm="">stun.1und1.de:3478</stun_server>
<stun_server idx="2" perm="">stun.l.google.com:19302</stun_server>
<stun_binding_interval idx="2" perm="">120</stun_binding_interval>
<keepalive_interval idx="2" perm="">20</keepalive_interval>
<hide_identity idx="1" perm="">false</hide_identity>
<hide_identity idx="2" perm="">false</hide_identity>
<callrecord_dialed_local idx="0" perm="">"hb2" <[email protected]></callrecord_dialed_local>
<callrecord_dialed_remote idx="0" perm="">sip:[email protected];user=phone</callrecord_dialed_remote>
<callrecord_dialed_period idx="0" perm="">2022-03-03T12:41:01ZPT49S</callrecord_dialed_period>
<callrecord_dialed_spec_routing idx="0" perm="">0</callrecord_dialed_spec_routing>
<codec_priority_list idx="1" perm="">pcma,telephone-event</codec_priority_list>
<codec_priority_list idx="2" perm="">pcma,telephone-event</codec_priority_list>
<use_contact_in_refer_to_hdr idx="1" perm="">off</use_contact_in_refer_to_hdr>
<use_contact_in_refer_to_hdr idx="2" perm="">off</use_contact_in_refer_to_hdr>
</phone-settings>
<functionKeys e="2"> </functionKeys>
<tbook e="2"> </tbook>
</settings>

Folgendes Häkchen war der Fehler:
Identität --> SIP --> Langer SIP-Contact (RFC3840): false (default=true)
(finde ich allerdings oben im xml nicht wieder)

Ich denke das Topic kann somit (fast) geschlossen werden.
Doch die Sprachleitung ist nur in eine Richtung offen: ich höre das IP-Phone(mic) am Handy, aber das IP-Phone hört das Handy nicht.
Sicherlich ein standardproblem mit dem Rückkanal, daher gerne verweiß auf diverse Topics, zum durchprobieren
vergleiche Twinkle (Softphone): https://www.ip-phone-forum.de/threa...iguration-an-vodafon-voip.312606/post-2468272

 

[koyaanisqatsi]

Doch die Sprachleitung ist nur in eine Richtung offen: ich häre das IP-Phone(mic) am Handy, aber das IP-Phone hört das Handy nicht.

Im SIP Protokoll siehst du im INVITE das SDP der Codecaushandlung.
Da darf keine lokale NAT IP auftauchen.
Außerdem mögen Smartphones keine RTP Ports < 1023.
( Das sind sogenannte priviligierte Ports )

 

[sonyKatze]

„Langer SIP-Contact“ finde ich allerdings oben im xml nicht wieder

user_descr_contact

das [Snom] hört [die Gegenstelle (ein Mobiltelefon)] nicht

Mit Twinkle ist alles OK? Ein Ansatz wäre, SDP zu vergleichen, also ob wie von koyaanisqatsi angemerkt, eine private IP-Adresse im Header Connection (c=) steht oder eine Öffentliche. Übrigens: Viele Telefonie-Anbieter ignorieren die IP-Adresse dort in SDP und senden ihre RTP-Daten an jene IP-Adresse von der Du abschickst. Die Frage ist, wie Vodafone das handhabt. Neben SDP kann es einen ganz anderen Grund haben: Deine Firewall blockt diese eingehende RTP-Pakete.

ich habe im Thread etwas den Überblick verloren: Welchen Router verwendest Du nochmal genau?

Port 5061 testen soll da 5060 evtl. bereits anderweitig belegt

Das betrifft Dich nur den Quell-Port und nur dann, wenn Dein Router auch Telefonie macht (und auch dann nicht immer). Aber ein verwendet von Haus nicht statisch immer 5060 sondern wählt zufällig am Anfang einen dynamischen Quell-Port aus, wie man auch in Deinen SIP-Mitschnitten im Header Contact sieht (z. B. Port 37404).

 

[Oekel]

user_descr_contact

Mit Twinkle ist alles OK?

ich habe im Thread etwas den Überblick verloren: Welchen Router verwendest Du nochmal genau?

(Ja ich glabue mit Twinkle hatte ich in beide Richtungen reinrufen können)

Ich habe einen Vigor 2860 (das ist ein reiner Multi-WAN Router ohne VoIP Converter, WLAN oder sonstigen Schnickschnack)
Es gibt auf dem Markt aber noch einen 2860V (der hätte VoiP und beide bedienen sich der gleichen Firmware)

Leider geht Twinkle gerade nicht mehr (vermutlich weil das SNOM aktiv drin hängt)

 

[koyaanisqatsi]

Twinkle hat kein SIP Log?
...wäre nämlich genauso interessant
Vielleicht lehnt Vodafone Mehrfachregistrierungen ab?

 

[sonyKatze]

Vigor 2860

DrayTek hat eine Firewall, die nicht so einfach ist. Und die Vigors haben optional ein SIP-ALG – das unberechenbar ist (weil wir dessen Implementierung und Software-Bugs nicht kennen). Allerdings hast Du den Vorteil, dass Du das Internet (WAN) aber auch das Heimnetz (LAN) auf einen Ethernet-Port spiegeln kannst (siehe dessen Web-Oberfläche). Dadurch kannst Du mittels Wireshark live zuschauen, was genau passiert, also ob die RTP-Pakete von Vodafone überhaupt ankommen (und dann der DrayTek diese verwirft). Außerdem kannst Du schauen, weswegen Twinkle nun bockt. Bzw. was Twinkle anders macht(e).

Wenn Du Hilfe beim Lesen und Auswerten der Anzeige in Wireshark brauchst, einfach melden. Wir, jedenfalls ich, helfe gerne auch aus der Entfernung … Du kannst aber musst uns also nicht den Mitschnitt-Schnitt zukommen lassen.

sonstigen Schnickschnack

Mir wäre der schon zu viel Schnickschnack (DSL-Modem, Firewall, DNS-Forwarder, DHCP-Server, Software-mäßig bereits End-of-Life) … egal, was genau hast Du vor dem DrayTek, welches Cable-Modem?

 

[Oekel]

vor dem DrayTek, welches Cable-Modem?

Das TC4400-EU (Kaufdatum mitte 2021)

 

[sonyKatze]

Finde jetzt auf die Schnelle dessen Datenblatt nicht: Nutzt Du den rein als Bridge oder hat der DHCP aktiv?

 

[Oekel]

Nun noch mal zu Twinkle (läuft sauber, sobald ich die beiden Registrate am HardwarePhone deaktiviere)

+++ 4-3-2022 09:39:26.200559 INFO SIP ::send_sip_udp
Send to: udp:88.134.209.241:5060
REGISTER sip:sip.kabelfon.vodafone.de:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.10;rport;branch=z9hG4bKkvdkckoh
Max-Forwards: 70
To: "D.K." <sip:[email protected]:5060>
From: "D.K." <sip:[email protected]:5060>;tag=phbbi
Call-ID: [email protected]
CSeq: 114 REGISTER
Contact: <sip:[email protected]>;expires=3600
Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,PRACK,REFER,NOTIFY,SUBSCRIBE,INFO,MESSAGE
User-Agent: Twinkle/1.10.1
Content-Length: 0


---

+++ 4-3-2022 09:39:26.402382 INFO SIP :rocess_sip_msg
Received from: udp:88.134.209.241:5060
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 192.168.1.10:5060;received=192.168.1.10:5060;branch=z9hG4bKkvdkckoh;rport=39108
To: "D.K." <sip:[email protected]:5060>;tag=SDuimfc99-y2hw2hxd
From: "D.K." <sip:[email protected]:5060>;tag=phbbi
Call-ID: [email protected]
CSeq: 114 REGISTER
WWW-Authenticate: Digest realm="technik.kabel-deutschland.de", nonce="dec7+RepMB/qG9WeRfcFEw==",algorithm=MD5
Content-Length: 0


---

+++ 4-3-2022 09:39:26.404188 INFO SIP ::send_sip_udp
Send to: udp:88.134.209.241:5060
REGISTER sip:sip.kabelfon.vodafone.de:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.10;rport;branch=z9hG4bKlflidpeh
Max-Forwards: 70
To: "D.K." <sip:[email protected]:5060>
From: "D.K." <sip:[email protected]:5060>;tag=phbbi
Call-ID: [email protected]
CSeq: 115 REGISTER
Contact: <sip:[email protected]>;expires=3600
Authorization: Digest username="23xxxxxx3",realm="technik.kabel-deutschland.de",nonce="dec7+RepMB/qG9WeRfcFEw==",uri="sip:sip.kabelfon.vodafone.de:5060",response="9539096935d2a8036052ac54f374450c",algorithm=MD5
Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,PRACK,REFER,NOTIFY,SUBSCRIBE,INFO,MESSAGE
User-Agent: Twinkle/1.10.1
Content-Length: 0


---

+++ 4-3-2022 09:39:26.558437 INFO SIP :rocess_sip_msg
Received from: udp:88.134.209.241:5060
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.1.10:5060;received=192.168.1.10:5060;branch=z9hG4bKlflidpeh;rport=39108
To: "D.K." <sip:[email protected]:5060>;tag=SDuimfc99-gdsce0dy
From: "D.K." <sip:[email protected]:5060>;tag=phbbi
Call-ID: [email protected]
CSeq: 115 REGISTER
Contact: <sip:[email protected]:5060>;expires=3600;q=1
Content-Length: 0


---

+++ 4-3-2022 10:39:21.521524 INFO SIP ::send_sip_udp
Send to: udp:88.134.209.241:5060
REGISTER sip:sip.kabelfon.vodafone.de:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.10;rport;branch=z9hG4bKvcaffluo
Max-Forwards: 70
To: "D.K." <sip:[email protected]:5060>
From: "D.K." <sip:[email protected]:5060>;tag=enkhx
Call-ID: [email protected]
CSeq: 116 REGISTER
Contact: <sip:[email protected]>;expires=3600
Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,PRACK,REFER,NOTIFY,SUBSCRIBE,INFO,MESSAGE
User-Agent: Twinkle/1.10.1
Content-Length: 0


---

+++ 4-3-2022 10:39:21.828958 INFO SIP :rocess_sip_msg
Received from: udp:88.134.209.241:5060
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 192.168.1.10:5060;received=192.168.1.10:5060;branch=z9hG4bKvcaffluo;rport=39108
To: "D.K." <sip:[email protected]:5060>;tag=SDuimfc99-i1kwinll
From: "D.K." <sip:[email protected]:5060>;tag=enkhx
Call-ID: [email protected]
CSeq: 116 REGISTER
WWW-Authenticate: Digest realm="technik.kabel-deutschland.de", nonce="b3vK1jBgYSpm8Ac8AUEF0w==",algorithm=MD5
Content-Length: 0


---

+++ 4-3-2022 10:39:21.830629 INFO SIP ::send_sip_udp
Send to: udp:88.134.209.241:5060
REGISTER sip:sip.kabelfon.vodafone.de:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.10;rport;branch=z9hG4bKyriiwzmf
Max-Forwards: 70
To: "D.K." <sip:[email protected]:5060>
From: "D.K." <sip:[email protected]:5060>;tag=enkhx
Call-ID: [email protected]
CSeq: 117 REGISTER
Contact: <sip:[email protected]>;expires=3600
Authorization: Digest username="23xxxxxx3",realm="technik.kabel-deutschland.de",nonce="b3vK1jBgYSpm8Ac8AUEF0w==",uri="sip:sip.kabelfon.vodafone.de:5060",response="d5ab233211c7143673b47c669b34a884",algorithm=MD5
Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,PRACK,REFER,NOTIFY,SUBSCRIBE,INFO,MESSAGE
User-Agent: Twinkle/1.10.1
Content-Length: 0


---

+++ 4-3-2022 10:39:22.094992 INFO SIP :rocess_sip_msg
Received from: udp:88.134.209.241:5060
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.1.10:5060;received=192.168.1.10:5060;branch=z9hG4bKyriiwzmf;rport=39108
To: "D.K." <sip:[email protected]:5060>;tag=SDuimfc99-mljeji5m
From: "D.K." <sip:[email protected]:5060>;tag=enkhx
Call-ID: [email protected]
CSeq: 117 REGISTER
Contact: <sip:[email protected]:5060>;expires=3600;q=1
Content-Length: 0


---

+++ 4-3-2022 10:47:04.174350 INFO SIP ::send_sip_udp
Send to: udp:88.134.209.241:5060
REGISTER sip:sip.kabelfon.vodafone.de:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.10;rport;branch=z9hG4bKmpzswkon
Max-Forwards: 70
To: "D.K." <sip:[email protected]:5060>
From: "D.K." <sip:[email protected]:5060>;tag=dzpnx
Call-ID: [email protected]
CSeq: 118 REGISTER
Contact: <sip:[email protected]>;expires=3600
Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,PRACK,REFER,NOTIFY,SUBSCRIBE,INFO,MESSAGE
User-Agent: Twinkle/1.10.1
Content-Length: 0


---

+++ 4-3-2022 10:47:04.198156 INFO SIP :rocess_sip_msg
Received from: udp:88.134.209.241:5060
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.1.10:5060;received=192.168.1.10:5060;branch=z9hG4bKmpzswkon;rport=39108
To: "D.K." <sip:[email protected]:5060>;tag=aprqe8go9iqol67be-6ondob10000c7
From: "D.K." <sip:[email protected]:5060>;tag=dzpnx
Call-ID: [email protected]
CSeq: 118 REGISTER
Contact: <sip:[email protected]:39108>;q=1;expires=3600


---

+++ 4-3-2022 10:47:40.454349 INFO NORMAL t_alsa_io:pen
Opening ALSA device: default
play
capture
---

+++ 4-3-2022 10:47:40.454555 INFO NORMAL t_alsa_io:pen
Opening ALSA device: default
play
---

+++ 4-3-2022 10:47:40.490782 INFO NORMAL t_alsa_io:pen
Opening ALSA device: default
capture
---

+++ 4-3-2022 10:47:40.527780 INFO NORMAL t_alsa_io:pen
Opening ALSA device: default
play
capture
---

+++ 4-3-2022 10:47:40.527805 INFO NORMAL t_alsa_io:pen
Opening ALSA device: default
play
---

+++ 4-3-2022 10:47:40.557122 INFO NORMAL t_alsa_io:pen
Opening ALSA device: default
capture
---

+++ 4-3-2022 10:47:40.564867 INFO SIP ::send_sip_udp
Send to: udp:88.134.209.241:5060
INVITE sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.10;rport;branch=z9hG4bKvumpsyff
Max-Forwards: 70
To: <sip:[email protected]:5060>
From: "D.K." <sip:[email protected]:5060>;tag=rpnie
Call-ID: [email protected]
CSeq: 385 INVITE
Contact: <sip:[email protected]>
Content-Type: application/sdp
Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,PRACK,REFER,NOTIFY,SUBSCRIBE,INFO,MESSAGE
Supported: replaces,norefersub,100rel
User-Agent: Twinkle/1.10.1
Content-Length: 309

v=0
o=twinkle 1762992087 1105767515 IN IP4 192.168.1.10
s=-
c=IN IP4 192.168.1.10
t=0 0
m=audio 8000 RTP/AVP 98 97 8 0 3 101
a=rtpmap:98 speex/16000
a=rtpmap:97 speex/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20

---

+++ 4-3-2022 10:47:40.588142 INFO SIP :rocess_sip_msg
Received from: udp:88.134.209.241:5060
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.1.10:5060;received=192.168.1.10:5060;branch=z9hG4bKvumpsyff;rport=39108
To: <sip:[email protected]:5060>
From: "D.K." <sip:[email protected]:5060>;tag=rpnie
Call-ID: [email protected]
CSeq: 385 INVITE


---

+++ 4-3-2022 10:47:40.664178 INFO SIP :rocess_sip_msg
Received from: udp:88.134.209.241:5060
SIP/2.0 407 Proxy Authentication Required
Via: SIP/2.0/UDP 192.168.1.10:5060;received=192.168.1.10:5060;branch=z9hG4bKvumpsyff;rport=39108
To: <sip:[email protected]:5060>;tag=SDs2gnb99-oo1moltj
From: "D.K." <sip:[email protected]:5060>;tag=rpnie
Call-ID: [email protected]
CSeq: 385 INVITE
Proxy-Authenticate: Digest realm="technik.kabel-deutschland.de", nonce="K0nPCcbsDS3lXI9va2kccg==",algorithm=MD5
Content-Length: 0


---

+++ 4-3-2022 10:47:40.664324 INFO SIP ::send_sip_udp
Send to: udp:88.134.209.241:5060
ACK sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.10;rport;branch=z9hG4bKvumpsyff
Max-Forwards: 70
To: <sip:[email protected]:5060>;tag=SDs2gnb99-oo1moltj
From: "D.K." <sip:[email protected]:5060>;tag=rpnie
Call-ID: [email protected]
CSeq: 385 ACK
User-Agent: Twinkle/1.10.1
Content-Length: 0


---

+++ 4-3-2022 10:47:40.664618 INFO SIP ::send_sip_udp
Send to: udp:88.134.209.241:5060
INVITE sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.10;rport;branch=z9hG4bKqabpondf
Max-Forwards: 70
Proxy-Authorization: Digest username="23xxxxxx3",realm="technik.kabel-deutschland.de",nonce="K0nPCcbsDS3lXI9va2kccg==",uri="sip:[email protected]:5060",response="90e53c4c6828b0cb686fba84b30ef813",algorithm=MD5
To: <sip:[email protected]:5060>
From: "D.K." <sip:[email protected]:5060>;tag=rpnie
Call-ID: [email protected]
CSeq: 386 INVITE
Contact: <sip:[email protected]>
Content-Type: application/sdp
Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,PRACK,REFER,NOTIFY,SUBSCRIBE,INFO,MESSAGE
Supported: replaces,norefersub,100rel
User-Agent: Twinkle/1.10.1
Content-Length: 309

v=0
o=twinkle 1762992087 1105767515 IN IP4 192.168.1.10
s=-
c=IN IP4 192.168.1.10
t=0 0
m=audio 8000 RTP/AVP 98 97 8 0 3 101
a=rtpmap:98 speex/16000
a=rtpmap:97 speex/8000
a=rtpmap:8 PCMA/8000
a=rtpm

<cut off>

---

+++ 4-3-2022 10:47:40.694135 INFO SIP :rocess_sip_msg
Received from: udp:88.134.209.241:5060
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.1.10:5060;received=192.168.1.10:5060;branch=z9hG4bKqabpondf;rport=39108
To: <sip:[email protected]:5060>
From: "D.K." <sip:[email protected]:5060>;tag=rpnie
Call-ID: [email protected]
CSeq: 386 INVITE


---

+++ 4-3-2022 10:47:45.190269 INFO SIP :rocess_sip_msg
Received from: udp:88.134.209.241:5060
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP 192.168.1.10:5060;received=192.168.1.10:5060;branch=z9hG4bKqabpondf;rport=39108
To: <sip:[email protected]:5060>;tag=SDs2gnb99-lpap3iza-CC-5
From: "D.K." <sip:[email protected]:5060>;tag=rpnie
Call-ID: [email protected]
CSeq: 386 INVITE
Contact: <sip:[email protected]:5060;transport=udp>
P-Early-Media: inactive,gated
Content-Length: 263
Content-Type: application/sdp

v=0
o=- 2779574179 1105767516 IN IP4 88.134.209.249
s=-
c=IN IP4 88.134.209.249
t=0 0
m=audio 40898 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=msi:[email protected]
a=sendrecv
a=ptime:20

---

+++ 4-3-2022 10:47:45.190456 INFO NORMAL t_dialog:rocess_1xx_2xx_invite_resp
Starting early media.
---

+++ 4-3-2022 10:47:45.190507 INFO NORMAL t_audio_session::t_audio_session
Receive RTP from: 0.0.0.0:8000
Send RTP to: 88.134.209.249:40898
---

+++ 4-3-2022 10:47:45.190688 INFO NORMAL t_alsa_io:pen
Opening ALSA device: default
play
capture
---

+++ 4-3-2022 10:47:45.190700 INFO NORMAL t_alsa_io:pen
Opening ALSA device: default
play
---

+++ 4-3-2022 10:47:45.196159 INFO NORMAL t_alsa_io:pen
Opening ALSA device: default
capture
---

+++ 4-3-2022 10:47:45.201357 INFO NORMAL t_audio_session::run
Line 1: starting RTP session.
---

+++ 4-3-2022 10:47:45.201460 INFO NORMAL t_audio_session::run
Line 1: RTP session started.
---

+++ 4-3-2022 10:47:46.051582 INFO NORMAL t_audio_tx::run
Audio tx line 1: play SSRC 3235219731
---

+++ 4-3-2022 10:47:46.161722 INFO SIP :rocess_sip_msg
Received from: udp:88.134.209.241:5060
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 192.168.1.10:5060;received=192.168.1.10:5060;branch=z9hG4bKqabpondf;rport=39108
To: <sip:[email protected]:5060>;tag=SDs2gnb99-lpap3iza-CC-5
From: "D.K." <sip:[email protected]:5060>;tag=rpnie
Call-ID: [email protected]
CSeq: 386 INVITE
Contact: <sip:[email protected]:5060;transport=udp>
P-Early-Media: sendrecv,gated
Content-Length: 0


---

+++ 4-3-2022 10:47:57.989168 INFO SIP :rocess_sip_msg
Received from: udp:88.134.209.241:5060
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.1.10:5060;received=192.168.1.10:5060;branch=z9hG4bKqabpondf;rport=39108
To: <sip:[email protected]:5060>;tag=SDs2gnb99-lpap3iza-CC-5
From: "D.K." <sip:[email protected]:5060>;tag=rpnie
Call-ID: [email protected]
CSeq: 386 INVITE
Allow: ACK,BYE,CANCEL,INVITE,PRACK,REGISTER,UPDATE
Contact: <sip:[email protected]:5060;transport=udp>
Session-Expires: 1790;refresher=uas
Content-Length: 263
Content-Type: application/sdp

v=0
o=- 2779574179 1105767517 IN IP4 88.134.209.249
s=-
c=IN IP4 88.134.209.249
t=0 0
m=audio 40898 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=msi:[email protected]
a=sendrecv
a=ptime:20

---

+++ 4-3-2022 10:47:57.990862 INFO SIP ::send_sip_udp
Send to: udp:88.134.209.241:5060
ACK sip:[email protected]:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 192.168.1.10;rport;branch=z9hG4bKflfrcyqh
Max-Forwards: 70
Proxy-Authorization: Digest username="23xxxxxx3",realm="technik.kabel-deutschland.de",nonce="K0nPCcbsDS3lXI9va2kccg==",uri="sip:[email protected]:5060",response="90e53c4c6828b0cb686fba84b30ef813",algorithm=MD5
To: <sip:[email protected]:5060>;tag=SDs2gnb99-lpap3iza-CC-5
From: "D.K." <sip:[email protected]:5060>;tag=rpnie
Call-ID: [email protected]
CSeq: 386 ACK
User-Agent: Twinkle/1.10.1
Content-Length: 0


---

+++ 4-3-2022 10:48:13.897964 INFO SIP :rocess_sip_msg
Received from: udp:88.134.209.241:5060
BYE sip:[email protected]:39108 SIP/2.0
Via: SIP/2.0/UDP 88.134.209.241:5060;branch=z9hG4bKc5ki04104otl1o797l00sd0000g00.1
Call-ID: [email protected]
From: <sip:[email protected]:5060>;tag=SDs2gnb99-lpap3iza-CC-5
To: <sip:[email protected]:5060>;tag=rpnie
CSeq: 1 BYE
Max-Forwards: 50
Content-Length: 0


---

+++ 4-3-2022 10:48:13.898281 INFO SIP ::send_sip_udp
Send to: udp:88.134.209.241:5060
SIP/2.0 200 OK
Via: SIP/2.0/UDP 88.134.209.241:5060;branch=z9hG4bKc5ki04104otl1o797l00sd0000g00.1
To: <sip:[email protected]:5060>;tag=rpnie
From: <sip:[email protected]:5060>;tag=SDs2gnb99-lpap3iza-CC-5
Call-ID: [email protected]
CSeq: 1 BYE
Server: Twinkle/1.10.1
Content-Length: 0


---

+++ 4-3-2022 10:48:13.918390 INFO NORMAL t_audio_session::~t_audio_session
Line 1: stopping RTP session.
---

+++ 4-3-2022 10:48:13.939499 INFO NORMAL t_audio_session::~t_audio_session
Line 1: RTP session stopped.
---

Es sind doch einige Zeilen, hoffe ich erkennt die richtige
Beim Verbindungsaufbau schreibt Twinkle übrigens: Ringing "g711a". Denke das ist der genutzte Codec und ich höre auf jeden Fall beidseitig den Gegenüber.


[Edit Novize: Beiträge zusammengefasst - siehe Forumsregeln]

[Edit Novize: Überflüssiges Fullquote des Beitrags direkt darüber gelöscht - siehe Forumsregeln]

@sonyKatze:

Es ist ein reines Modem, ich glaube nicht, dass er ein Webinterface hat, wo ich irgendetwas einstellen könnte. Ist bridge nicht immer nur bei einem Router nötig?

 

[sonyKatze]

Bridge ist ein Modus bei einem Router.
Wenn es kein Router ist, verhält es sich (immer) wie eine Bridge.
Verkürzt ausgedrückt. Aber ist egal: Mit ging es darum, ob dieses Gerät noch mehr macht (DHCP oder gar Firewall), nicht dass wir mit zwei Geräten zu kämpfen haben. Ist damit geklärt; wir haben nur den Vigor.

Beim Verbindungsaufbau schreibt Twinkle …

Das sind die richtigen Einträge. Spannend ist das INVITE und dort die Zeile bzw. die IP-Adresse nach „c=IN IP4“. Twinkle schickt eine private IP-Adresse. Folglich kann das nicht die Ursache/Unterschied sein. Spannend ist das OK auf das INVITE und dort die Zeile „m=audio 40898 RTP/AVP 8 101“. Vodafone hat aus den ganzen Audio-Codecs tatsächlich sich für G.711 A-law (PCMA) entschieden.

Problem ist, Twinkle bietet erst gar nicht G.722 an. Das bedeutet, das Snom und Twinkle könnten sich hier anders verhalten. Kannst Du mal im Snom (dessen SIP-Log bzw. über das Vigor Port-Mirroring) schauen, ob Vodafone sich für G.722 (= 9) oder auch wieder G.711 (= 8) entscheidet?

 

[Oekel]

Problem ist, Twinkle bietet erst gar nicht G.722 an. Das bedeutet, das Snom und Twinkle könnten sich hier anders verhalten. Kannst Du mal im Snom (dessen SIP-Log bzw. über das Vigor Port-Mirroring) schauen, ob Vodafone sich für G.722 (= 9) oder auch wieder G.711 (= 8) entscheidet?

Das ist nun wieder aus dem SNIM 320, welches ich sicherheitshalber auch noch mal testen wollte (gleiches Verhalten sobald abgenommen wurde, jedoch kann ich nur Handy-->Snom und nicht Snom-->Handy: not allowed.

Received from udp:88.134.209.241:5060 at Mar 4 11:45:03 (962 bytes):

INVITE sip:[email protected]:39748;line=qwkraizh SIP/2.0
Via: SIP/2.0/UDP 88.134.209.241:5060;branch=z9hG4bKvdro1a304890gra08kf0.1
Call-ID: SD4hj6301-f101cbeaaa209fd2d96d87000eceae1b-ao94go2010
From: <sip:[email protected];user=phone>;tag=SD4hj6301-1jp28lia-CC-3
To: <sip:[email protected];user=phone>
CSeq: 1 INVITE
Allow: ACK,BYE,CANCEL,INVITE,PRACK,REGISTER,UPDATE
Contact: <sip:[email protected]:5060;transport=udp>
Max-Forwards: 48
Supported: timer
Session-Expires: 1800;refresher=uac
Min-SE: 1790
P-Early-Media: supported
Session-ID: e9961708689cfd657eb3063bf9da9150;remote=00000000000000000000000000000000
Content-Length: 221
Content-Type: application/sdp

v=0
o=- 967618466 1594735 IN IP4 88.134.209.249
s=-
c=IN IP4 88.134.209.249
t=0 0
m=audio 13888 RTP/AVP 9 8 101
a=rtpmap:9 G722/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=sendrecv
a=ptime:20

Stecke jetzt wieder das 821 ein und poste den gleichen INVITE noch mal hier:

INVITE sip:[email protected]:37376 SIP/2.0
Via: SIP/2.0/UDP 88.134.209.241:5060;branch=z9hG4bKfh7o740098g024ud74a0.1
Call-ID: SDh6jt801-733d28abc651b79dbe4bcae57ee306d1-ao94go2010
From: <sip:[email protected];user=phone>;tag=SDh6jt801-2jrx1zrv-CC-3
To: <sip:[email protected];user=phone>
CSeq: 1 INVITE
Allow: ACK,BYE,CANCEL,INVITE,PRACK,REGISTER,UPDATE
Contact: <sip:[email protected]:5060;transport=udp>
Max-Forwards: 49
Supported: timer
Session-Expires: 1800;refresher=uac
Min-SE: 1790
P-Early-Media: supported
Session-ID: c538ebe8655be5e550be49072a6ccca1;remote=00000000000000000000000000000000
Content-Length: 222
Content-Type: application/sdp

v=0
o=- 2300366770 1595480 IN IP4 88.134.209.249
s=-
c=IN IP4 88.134.209.249
t=0 0
m=audio 15852 RTP/AVP 9 8 101
a=rtpmap:9 G722/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=sendrecv
a=ptime:20

Wenn ich vom SNOM aus raus wähle sieht es allerdings etwas anders aus:

Content-Type: application/sdp
Content-Length: 232

v=0
o=root 417915052 417915052 IN IP4 77.22.210.39
s=call
c=IN IP4 77.22.210.39
t=0 0
m=audio 54832 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=rtcp:53297
a=sendrecv

musste natürlich g722 wieder in die Liste mit aufnehmen:

Content-Length: 258

v=0
o=root 1607488580 1607488580 IN IP4 77.22.210.39
s=call
c=IN IP4 77.22.210.39
t=0 0
m=audio 51216 RTP/AVP 9 8 101
a=rtpmap:9 G722/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=rtcp:49681
a=sendrecv

aber es bleibt beim Alten (während eines Gesprächs)
Nebenbaustelle: Sehe ich eigentlich im Protokoll für welchen Codec sich beide Seiten entschieden haben?

 

[sonyKatze]

Sehe ich eigentlich im Protokoll für welchen Codec sich beide Seiten entschieden haben?

Jein. Wenn im OK nur ein Codec – also eine Zahl nach RTP/AVP + 101 – in der Zeile m auftaucht, dann ja. Weil nur ein Audio-Codec zur Wahl steht. Wenn mehrere Audio-Codecs im OK stünden, dann wird normalerweise der erste genommen. Aber alle wären möglich, sogar während dem Gespräch ein Tausch ohne re-INVITE.

Richtig sehen könntest Du es durch Port-Mirroring, also das Mitschneiden des LAN-Verkehrs.

Snom 821

Bleiben wir bei dem Snom 821, dass einen Anruf in beide Richtungen aufbauen kann (das Snom 320 sehen wir uns dann später an; auf den ersten Blick sehe ich nicht, warum das so ist).

Laut Deinen SIP-Messages verwendet das Snom 821 öffentliche IP-Adressen. Also ein Unterschied zu Twinkle. Könnte jetzt sein, dass Vodafone deswegen direkt an diese IP-Adresse+Port schickt; aber der Vigor um-mapp-ed, also extern einen anderen Port nimmt†. Die Frage ist, warum das Snom überhaupt öffentliche IP-Adressen in SDP verwendet: Hast Du immer noch STUN aktiv?

† Das könntest Du überprüfen, indem Du im Vigor das WAN mitschneidest. Oder das Snom 821 kurzeitig als Exposed-Host deklarierst. Ich meine, DrayTek nennt das DMZ. Müsste jetzt meinen Vigor auspacken. Vorher unbedingt die Web-Oberfläche der Snoms durch ein Passwort absichern.

 

[Oekel]

DrayTek hat eine Firewall, die nicht so einfach ist. Und die Vigors haben optional ein SIP-ALG – das unberechenbar ist (weil wir dessen Implementierung und Software-Bugs nicht kennen).

Solved!
ALG deaktiviert und ich höre, was ich hören will.
Werde dennoch noch mal einen Call mit DrayTec machen, denn deren Leute haben mir in zig Fällen ihr System wunderbar erklären können.

 

[sonyKatze]

Klappt jetzt auch das Snom 320, also alles gelöst?

Wenn das SIP-ALG in der Firewall aus ist, kann die dauerhafte Erreichbarkeit ein Problem sein, denn DrayTek behält das Mapping für einen UDP-Port in der Firewall nur drei Minuten. Das heißt, nachdem das Snom registriert ist, zum Test mindestens drei Minuten warten. Dann Dich selbst (z. B. über Mobilfunk) anrufen. Klingelt das Snom, dürfte alles OK sein. Wenn nicht, würde ich in der Web-Oberfläche des Snom das Keep-Alive auf irgendwas kleiner 180 setzen.

Alternativ könntest Du den UDP-Timeout im DrayTek höher setzen. Im OK auf das REGISTER im Header Contact steht Dein Wert: 3600 Sekunden. Aber das ist vergleichsweise lang und könnte andere Probleme mit dem Internet-Zugang an sich bereiten (Ports gehen dem Vigor aus). Daher würde ich das an Deiner Stelle eher in den Endgeräten einstellen.

 

[Oekel]

Klappt jetzt auch das Snom 320, also alles gelöst?

Bitte vergib mir, dass ich den Test mit dem 320er hinten anstelle. (Aber er kommt garantiert, da ich mit Asterisk ALLE HW-Phones brauche und überall das direkte Registrat als Fallback einbinden möchte)