Hallo,
ich habe hier ein Lancom 1722 mit Firmwareversion 8.00.0221 und möchte es mit einem Sipgate Trunk verbinden. Eingehende Anrufe gehen auch wunderbar, jedoch wollen ausgehende Anrufe leider nicht
Habe in der SIP-Leitung Trunk ausgewählt und die Zugangsdaten die ich von Sipgate erhalten habe eingetragen:
Provider-Daten
SIP-Domäne: sipconnect.sipgate.de
Registrar: sipconnect.live.sipgate.de
Outbound-Proxy: sipconnect.live.sipgate.de
Port: 5060
Haken bei Vermitteln ist gesetzt
Anmelde-Daten
Haken bei Registrierung gesetzt
SIP-ID: 2xxxx29t0
Display-Name: (leer)
Authentifizier-Name: 2xxxx29t0
Passwort: geheim
Bei SIP-Mapping hab ich folgendes eingetragen:
Abgehende Rufe
Externe Nummer/Name: 498941xxx82#
Rufnummern-Länge: 2
Ankommende Rufe
Interne Ziel-Nummer: #
Unter Benutzer hab ich den Haken für Lokale Authentifizierung erzwingen gesetzt und einen SIP-Benutzer angelegt:
Interne Rufnummer: 12
Authentifizier.-Name: (leer)
Passwort: geheim
Das Telefon (Snom 360) kann sich auch am Lancom anmelden.
Wenn ich jetzt das Telefon mittels 498941xxx8212 anrufe geht das auch wunderbar.
Will ich gedoch von diesem Telefon raustelefonieren erhalte ich folgender Fehlermeldung (am Snom): Forbidden (check from field)
Ein sip # trace auf dem Lancom gibt folgendes aus:
[SIP-Packet] 2010/12/09 18:26:50,270 [PACKET] :
Sending datagram with length 1068 from 95.91.8.197:38265 to 217.10.68.150:5060
INVITE sip:01722xxxx02@sipconnect.sipgate.de SIP/2.0\r\n
Via: SIP/2.0/UDP 95.91.8.197:38265;branch=z9hG4bK-9b0641a8-6470570e\r\n
From: "Fabian St. <12>"<sip:498941xxx8212@sipconnect.sipgate.de;user=phone>;tag=638161530--1699423511\r\n
To: <sip:01722xxxx02@sipconnect.sipgate.de;user=phone>\r\n
Call-ID: 3067638481@00a05711b62f\r\n
CSeq: 1 INVITE\r\n
Max-Forwards: 70\r\n
User-Agent: snom360/8.2.29\r\n
Server: lancomRouter\r\n
Allow: REGISTER, INVITE, ACK, CANCEL, BYE, REFER, NOTIFY, OPTIONS\r\n
Contact: <sip:2xxxx29t0@95.91.8.197:38265>\r\n
X-Serialnumber: 0004132944B1\r\n
Content-Type: application/sdp\r\n
Content-Length: 467\r\n
\r\n
v=0\r\n
o=- 3067394632 3067394632 IN IP4 95.91.8.197\r\n
s=call\r\n
c=IN IP4 95.91.8.197\r\n
t=0 0\r\n
m=audio 9206 RTP/AVP 0 8 3 2 9 18 4 101\r\n
a=rtpmap:0 PCMU/8000\r\n
a=rtpmap:8 PCMA/8000\r\n
a=rtpmap:3 GSM/8000\r\n
a=rtpmap:2 G726-32/8000\r\n
a=rtpmap:9 G722/8000\r\n
a=rtpmap:18 G729/8000\r\n
a=rtpmap:4 G723/8000\r\n
a=rtpmap:101 telephone-event/8000\r\n
a=fmtp:18 annexb=no\r\n
a=fmtp:101 0-16\r\n
a=sendrecv\r\n
a=ptime:20\r\n
a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:ZZ0IDkApUZiy4OUIip6nKIsBBenghdDjnrI0nMpG\r\n
[SIP-Packet] 2010/12/09 18:26:50,340 [PACKET] :
Receiving datagram with length 495 from 217.10.68.150:5060 to 95.91.8.197:38265
SIP/2.0 407 Proxy Authentication Required\r\n
Via: SIP/2.0/UDP 95.91.8.197:38265;branch=z9hG4bK-9b0641a8-6470570e\r\n
From: "Fabian St. <12>"<sip:498941xxx8212@sipconnect.sipgate.de;user=phone>;tag=638161530--1699423511\r\n
To: <sip:01722xxxx02@sipconnect.sipgate.de;user=phone>;tag=efae1b206a1df22b5fbc395b5a747d13.c8c7\r\n
Call-ID: 3067638481@00a05711b62f\r\n
CSeq: 1 INVITE\r\n
Proxy-Authenticate: Digest realm="sipconnect.sipgate.de", nonce="4d0112861af653aeba6ef171cbe1ca06ec75b431"\r\n
Content-Length: 0\r\n
\r\n
Wer kann weiterhelfen?
Vielen Dank und viele Grüße,
Fabian
Sipgate Trunk mit Lancom 1722
Moderator: Lancom-Systems Moderatoren
Hallo Fabian,
gehört denn die Rufnummer +498941xxx8212 zu dem sipgate-Trunk?
Wenn nein, interne Nummer (12) entsprechend ändern.
Wenn ja, dann müsste man hier den kompletten SIP-Trace sehen, d. h. noch mindestens 2 Pakete. Bei Dir sind nur die ersten beiden zu sehen, die sehen in Ordnung aus. Entscheidend ist Paket 4.
Was so auf Anhieb auffällt ist die AES-Verschlüsselung die das snom anbietet. Möglicherweise hat sipgate damit ein Problem, das weiß ich jetzt aber nicht.
Viele Grüße,
Jirka
gehört denn die Rufnummer +498941xxx8212 zu dem sipgate-Trunk?
Wenn nein, interne Nummer (12) entsprechend ändern.
Wenn ja, dann müsste man hier den kompletten SIP-Trace sehen, d. h. noch mindestens 2 Pakete. Bei Dir sind nur die ersten beiden zu sehen, die sehen in Ordnung aus. Entscheidend ist Paket 4.
Was so auf Anhieb auffällt ist die AES-Verschlüsselung die das snom anbietet. Möglicherweise hat sipgate damit ein Problem, das weiß ich jetzt aber nicht.
Viele Grüße,
Jirka
Hallo Jirka
Viele Grüße
Fabian
die Rufnummer gehört natürlich zu dem Trunk. Im Webinterface bei Sipgate steht dazu folgendes: Rufnummernblock 089-41xxx821 - 0-9Jirka hat geschrieben:Hallo Fabian,
gehört denn die Rufnummer +498941xxx8212 zu dem sipgate-Trunk?
Anbei der restliche Trace:Jirka hat geschrieben: Wenn nein, interne Nummer (12) entsprechend ändern.
Wenn ja, dann müsste man hier den kompletten SIP-Trace sehen, d. h. noch mindestens 2 Pakete. Bei Dir sind nur die ersten beiden zu sehen, die sehen in Ordnung aus. Entscheidend ist Paket 4.
Code: Alles auswählen
[SIP-Packet] 2010/12/10 00:25:04,960 [PACKET] :
Sending datagram with length 528 from 95.91.8.197:42837 to 217.10.68.150:5060
ACK sip:01722xxxx02@sipconnect.sipgate.de SIP/2.0\r\n
Via: SIP/2.0/UDP 95.91.8.197:42837;branch=z9hG4bK-f1ab763e-1a7ad333\r\n
From: "Fabian St. <12>"<sip:498941xxx8212@sipconnect.sipgate.de;user=phone>;tag=305585233-1577704569\r\n
To: <sip:01722xxxx02@sipconnect.sipgate.de;user=phone>;tag=efae1b206a1df22b5fbc395b5a747d13.f872\r\n
Call-ID: 199742234@00a05711b62f\r\n
CSeq: 1 ACK\r\n
Max-Forwards: 70\r\n
User-Agent: snom360/8.4.18\r\n
Server: lancomRouter\r\n
Allow: REGISTER, INVITE, ACK, CANCEL, BYE, REFER, NOTIFY, OPTIONS\r\n
Content-Length: 0\r\n
\r\n
[SIP-Packet] 2010/12/10 00:25:04,970 [PACKET] :
Sending datagram with length 1267 from 95.91.8.197:42837 to 217.10.68.150:5060
INVITE sip:01722xxxx02@sipconnect.sipgate.de SIP/2.0\r\n
Via: SIP/2.0/UDP 95.91.8.197:42837;branch=z9hG4bK-814bd1a3-9f12132c\r\n
From: "Fabian St. <12>"<sip:498941xxx8212@sipconnect.sipgate.de;user=phone>;tag=305585233-1577704569\r\n
To: <sip:01722xxxx02@sipconnect.sipgate.de;user=phone>\r\n
Call-ID: 199742234@00a05711b62f\r\n
CSeq: 2 INVITE\r\n
Max-Forwards: 70\r\n
User-Agent: snom360/8.4.18\r\n
Server: lancomRouter\r\n
Allow: REGISTER, INVITE, ACK, CANCEL, BYE, REFER, NOTIFY, OPTIONS\r\n
Proxy-Authorization: Digest username="2772629t0",realm="sipconnect.sipgate.de",nonce="4d01667d786110b83a0df64a123e1f2fef65d3ad",uri="sip:01722xxxx02@sipconnect.sipgate.de",algorithm=MD5,response="19a792440e5a8fafc81c18a539370f9c"\r\n
Contact: <sip:2772629t0@95.91.8.197:42837>\r\n
Content-Type: application/sdp\r\n
Content-Length: 467\r\n
\r\n
v=0\r\n
o=- 4014045158 4014045158 IN IP4 95.91.8.197\r\n
s=call\r\n
c=IN IP4 95.91.8.197\r\n
t=0 0\r\n
m=audio 9920 RTP/AVP 0 8 3 2 9 18 4 101\r\n
a=rtpmap:0 PCMU/8000\r\n
a=rtpmap:8 PCMA/8000\r\n
a=rtpmap:3 GSM/8000\r\n
a=rtpmap:2 G726-32/8000\r\n
a=rtpmap:9 G722/8000\r\n
a=rtpmap:18 G729/8000\r\n
a=rtpmap:4 G723/8000\r\n
a=rtpmap:101 telephone-event/8000\r\n
a=fmtp:18 annexb=no\r\n
a=fmtp:101 0-16\r\n
a=sendrecv\r\n
a=ptime:20\r\n
a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:lFv5JX/vw66RsYR9e0sMzCc/EyteOe3WviQgDNw7\r\n
[SIP-Packet] 2010/12/10 00:25:05,050 [PACKET] :
Receiving datagram with length 384 from 217.10.68.150:5060 to 95.91.8.197:42837
SIP/2.0 403 Forbidden (check from field)\r\n
Via: SIP/2.0/UDP 95.91.8.197:42837;branch=z9hG4bK-814bd1a3-9f12132c\r\n
From: "Fabian St. <12>"<sip:498941xxx8212@sipconnect.sipgate.de;user=phone>;tag=305585233-1577704569\r\n
To: <sip:01722xxxx02@sipconnect.sipgate.de;user=phone>;tag=efae1b206a1df22b5fbc395b5a747d13.ee61\r\n
Call-ID: 199742234@00a05711b62f\r\n
CSeq: 2 INVITE\r\n
Content-Length: 0\r\n
\r\n
[SIP-Packet] 2010/12/10 00:25:05,050 [PACKET] :
Sending datagram with length 486 from 95.91.8.197:42837 to 217.10.68.150:5060
ACK sip:01722xxxx02@sipconnect.sipgate.de SIP/2.0\r\n
Via: SIP/2.0/UDP 95.91.8.197:42837;branch=z9hG4bK-814bd1a3-9f12132c\r\n
From: "Fabian St. <12>"<sip:498941xxx8212@sipconnect.sipgate.de;user=phone>;tag=305585233-1577704569\r\n
To: <sip:01722xxxx02@sipconnect.sipgate.de;user=phone>\r\n
Call-ID: 199742234@00a05711b62f\r\n
CSeq: 2 ACK\r\n
Max-Forwards: 70\r\n
User-Agent: snom360/8.4.18\r\n
Server: lancomRouter\r\n
Allow: REGISTER, INVITE, ACK, CANCEL, BYE, REFER, NOTIFY, OPTIONS\r\n
Content-Length: 0\r\n
\r\n
[SIP-Packet] 2010/12/10 00:25:05,070 [PACKET] :
Sending datagram with length 436 from 10.162.80.254:5060 to 10.162.80.32:2052
SIP/2.0 403 Forbidden (check from field) \r\n
Via: SIP/2.0/UDP 10.162.80.32:2052;branch=z9hG4bK-rd4gs9co8j7d;rport\r\n
From: "Fabian St. <12>"<sip:12@intern>;tag=ws0a7vdi1r\r\n
To: <sip:01722xxxx02@intern;user=phone>;tag=743148802-2019237218\r\n
Call-ID: 3c26704a0bd7-3ofeeslniuoi\r\n
CSeq: 2 INVITE\r\n
Max-Forwards: 70\r\n
Server: lancomRouter\r\n
Allow: REGISTER, INVITE, ACK, CANCEL, BYE, REFER, NOTIFY, OPTIONS\r\n
Content-Length: 0\r\n
\r\n
[SIP-Packet] 2010/12/10 00:25:05,090 [PACKET] :
Receiving datagram with length 383 from 10.162.80.32:2052 to 10.162.80.254:5060
ACK sip:01722xxxx02@intern;user=phone SIP/2.0\r\n
v: SIP/2.0/UDP 10.162.80.32:2052;branch=z9hG4bK-rd4gs9co8j7d;rport\r\n
f: "Fabian St. <12>" <sip:12@intern>;tag=ws0a7vdi1r\r\n
t: <sip:01722xxxx02@intern;user=phone>;tag=743148802-2019237218\r\n
i: 3c26704a0bd7-3ofeeslniuoi\r\n
CSeq: 2 ACK\r\n
Max-Forwards: 70\r\n
m: <sip:12@10.162.80.32:2052;line=0a4e491b>;reg-id=1\r\n
l: 0\r\n
\r\nFabian
Hallo Fabian,
das "Forbidden (check from field)" kommt so tatsächlich von sipgate. Warum weiß ich jetzt auch nicht genau. Hier wäre interessant zu wissen, ob vielleicht bei sipgate irgendwas noch nicht erlaubt ist. Ist das ein Test-Account?
Kannst Du im Snom mal die AES-Verschlüsselung abstellen?
Viele Grüße,
Jirka
das "Forbidden (check from field)" kommt so tatsächlich von sipgate. Warum weiß ich jetzt auch nicht genau. Hier wäre interessant zu wissen, ob vielleicht bei sipgate irgendwas noch nicht erlaubt ist. Ist das ein Test-Account?
Kannst Du im Snom mal die AES-Verschlüsselung abstellen?
Viele Grüße,
Jirka
Hallo Jirka,
ich versuche jetzt schon geraume Zeit mit den Sipgate Leuten dieses Problem zu lösen.
Zur Zeit sieht es so aus:
nicht ok: From: "Horst"<sip:49441361810742@sipconnect.sipgate.de;user=phone>
ok: From: <sip:1182504t0@sipconnect.sipgate.de>
P-Preferred-Identity: <sip:49441361810742@sipconnect.sipgate.de>
wie könnter der Router (1724) dazu überredet werden?
Gruss, Horst
ich versuche jetzt schon geraume Zeit mit den Sipgate Leuten dieses Problem zu lösen.
Zur Zeit sieht es so aus:
nicht ok: From: "Horst"<sip:49441361810742@sipconnect.sipgate.de;user=phone>
ok: From: <sip:1182504t0@sipconnect.sipgate.de>
P-Preferred-Identity: <sip:49441361810742@sipconnect.sipgate.de>
wie könnter der Router (1724) dazu überredet werden?
Gruss, Horst
Hallo Horst,
grundsätzlich gehst Du wie hier beschrieben vor: http://www.lancom-forum.de/ptopic,50101.html#50101
Du solltest jetzt den Benutzernamen (SIP-ID) auf den tatsächlichen Benutzernamen ändern. Der Rest funktioniert übers SIP-Mapping.
Viele Grüße,
Jirka
grundsätzlich gehst Du wie hier beschrieben vor: http://www.lancom-forum.de/ptopic,50101.html#50101
Du solltest jetzt den Benutzernamen (SIP-ID) auf den tatsächlichen Benutzernamen ändern. Der Rest funktioniert übers SIP-Mapping.
Viele Grüße,
Jirka
Hallo Jirka,
vielen Dank für die schnelle Antwort.
Ich habe das Problem leider nicht ausführlich genug beschrieben.
1. Registrieren funktioniert
2. Ankommende Gespräche kommen am richtigen Telefon an und funktionieren tadellos
3. Abgehende Gespräche sind unmöglich "Forbidden (check from field)"
hier ist meine Konfiguration und ein Trace - vielleicht sagt das ja mehr aus zusammen mit der Info von Sipgate, dass die ein "P-Preferred-Identity" benötigen (siehe oben)
LINE
Mode Trunk
Provider name SGTRUNK
SIP domain/realm sipconnect.sipgate.de
Outbound proxy sipconnect.live.sipgate.de
SIP-ID/user 'SIP_ID't0
MAPPING
Trunk/gateway name SGTRUNK
External number/name 4944136181074#
Length of called number 1
Internal dest. number 4#
[SIP-Packet] 2011/02/04 09:25:25,940 [PACKET] :
Receiving datagram with length 921 from 10.1.1.62:5060 to 10.1.1.1:5060
INVITE sip:04413990338@10.1.1.1 SIP/2.0
Via: SIP/2.0/UDP 10.1.1.62:5060;branch=z9hG4bK0729f799f260ead9
From: "Horst" <sip:42@10.1.1.1>;tag=52226ba26c89ec95
To: <sip:04413990338@10.1.1.1>
Contact: <sip:42@10.1.1.62:5060;transport=udp>
Supported: replaces, timer, path
X-Grandstream-PBX: true
P-Early-Media: Supported
Call-ID: f275f55a75e1744e@10.1.1.62
CSeq: 33356 INVITE
User-Agent: Grandstream GXP1200 1.2.5.3
Max-Forwards: 70
Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE,UPDATE,PRACK,MESSAGE
Content-Type: application/sdp
Content-Length: 340
v=0
o=42 8000 8000 IN IP4 10.1.1.62
s=SIP Call
c=IN IP4 10.1.1.62
t=0 0
m=audio 5086 RTP/AVP 0 8 4 18 2 97 9 3
a=sendrecv
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:4 G723/8000
a=rtpmap:18 G729/8000
a=rtpmap:2 G726-32/8000
a=rtpmap:97 iLBC/8000
a=fmtp:97 mode=20
a=rtpmap:9 G722/8000
a=rtpmap:3 GSM/8000
a=ptime:20
[SIP-Packet] 2011/02/04 09:25:25,940 [PACKET] :
Sending datagram with length 417 from 10.1.1.1:5060 to 10.1.1.62:5060
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.1.1.62:5060;branch=z9hG4bK0729f799f260ead9
From: "Horst"<sip:42@10.1.1.1>;tag=52226ba26c89ec95
To: <sip:04413990338@10.1.1.1>
Call-ID: f275f55a75e1744e@10.1.1.62
CSeq: 33356 INVITE
Max-Forwards: 70
User-Agent: LANCOM 1724 VoIP (Annex B) / 8.00.0162 / 16.06.2010
Server: Stargateol
Allow: REGISTER, INVITE, ACK, CANCEL, BYE, REFER, NOTIFY, OPTIONS
Content-Length: 0
[SIP-Packet] 2011/02/04 09:25:25,940 [PACKET] :
Sending datagram with length 494 from 10.1.1.1:5060 to 10.1.1.62:5060
SIP/2.0 407 login needed
Via: SIP/2.0/UDP 10.1.1.62:5060;branch=z9hG4bK0729f799f260ead9
From: "Horst"<sip:42@10.1.1.1>;tag=52226ba26c89ec95
To: <sip:04413990338@10.1.1.1>;tag=1257472925--236053809
Call-ID: f275f55a75e1744e@10.1.1.62
CSeq: 33356 INVITE
Max-Forwards: 70
Server: Stargateol
Allow: REGISTER, INVITE, ACK, CANCEL, BYE, REFER, NOTIFY, OPTIONS
Proxy-Authenticate: Digest realm="10.1.1.1",nonce="afcc80fbba5ec35db097e28e584bf147",opaque="",algorithm=MD5
Content-Length: 0
[SIP-Packet] 2011/02/04 09:25:25,970 [PACKET] :
Receiving datagram with length 525 from 10.1.1.62:5060 to 10.1.1.1:5060
ACK sip:04413990338@10.1.1.1 SIP/2.0
Via: SIP/2.0/UDP 10.1.1.62:5060;branch=z9hG4bK0729f799f260ead9
From: "Horst" <sip:42@10.1.1.1>;tag=52226ba26c89ec95
To: <sip:04413990338@10.1.1.1>;tag=1257472925--236053809
Contact: <sip:42@10.1.1.62:5060;transport=udp>
Supported: path
X-Grandstream-PBX: true
Call-ID: f275f55a75e1744e@10.1.1.62
CSeq: 33356 ACK
User-Agent: Grandstream GXP1200 1.2.5.3
Max-Forwards: 70
Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE,UPDATE,PRACK,MESSAGE
Content-Length: 0
[SIP-Packet] 2011/02/04 09:25:25,990 [PACKET] :
Receiving datagram with length 1116 from 10.1.1.62:5060 to 10.1.1.1:5060
INVITE sip:04413990338@10.1.1.1 SIP/2.0
Via: SIP/2.0/UDP 10.1.1.62:5060;branch=z9hG4bK2d0b5c7826926e2a
From: "Horst" <sip:42@10.1.1.1>;tag=52226ba26c89ec95
To: <sip:04413990338@10.1.1.1>
Contact: <sip:42@10.1.1.62:5060;transport=udp>
Supported: replaces, timer, path
X-Grandstream-PBX: true
P-Early-Media: Supported
Proxy-Authorization: Digest username="42", realm="10.1.1.1", algorithm=MD5, uri="sip:04413990338@10.1.1.1", nonce="afcc80fbba5ec35db097e28e584bf147", response="0b297cc7cd39f0c04225c49d8514bd6a"
Call-ID: f275f55a75e1744e@10.1.1.62
CSeq: 33357 INVITE
User-Agent: Grandstream GXP1200 1.2.5.3
Max-Forwards: 70
Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE,UPDATE,PRACK,MESSAGE
Content-Type: application/sdp
Content-Length: 340
v=0
o=42 8000 8001 IN IP4 10.1.1.62
s=SIP Call
c=IN IP4 10.1.1.62
t=0 0
m=audio 5086 RTP/AVP 0 8 4 18 2 97 9 3
a=sendrecv
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:4 G723/8000
a=rtpmap:18 G729/8000
a=rtpmap:2 G726-32/8000
a=rtpmap:97 iLBC/8000
a=fmtp:97 mode=20
a=rtpmap:9 G722/8000
a=rtpmap:3 GSM/8000
a=ptime:20
[SIP-Packet] 2011/02/04 09:25:25,990 [PACKET] :
Sending datagram with length 417 from 10.1.1.1:5060 to 10.1.1.62:5060
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.1.1.62:5060;branch=z9hG4bK2d0b5c7826926e2a
From: "Horst"<sip:42@10.1.1.1>;tag=52226ba26c89ec95
To: <sip:04413990338@10.1.1.1>
Call-ID: f275f55a75e1744e@10.1.1.62
CSeq: 33357 INVITE
Max-Forwards: 70
User-Agent: LANCOM 1724 VoIP (Annex B) / 8.00.0162 / 16.06.2010
Server: Stargateol
Allow: REGISTER, INVITE, ACK, CANCEL, BYE, REFER, NOTIFY, OPTIONS
Content-Length: 0
[SIP-Packet] 2011/02/04 09:25:26,030 [PACKET] :
Sending datagram with length 953 from 85.16.64.57:15527 to 217.10.68.150:5060 rtg-tag:1
INVITE sip:04413990338@sipconnect.sipgate.de SIP/2.0
Via: SIP/2.0/UDP 85.16.64.57:15527;branch=z9hG4bK-cda4fc0f-8c06242c
From: "Horst"<sip:49441361810742@sipconnect.sipgate.de;user=phone>;tag=1975038921--741119201
To: <sip:04413990338@sipconnect.sipgate.de>
Call-ID: 2373336801@00a05711fb6a
CSeq: 1 INVITE
Max-Forwards: 70
User-Agent: Grandstream GXP1200 1.2.5.3
Server: Stargateol
Allow: REGISTER, INVITE, ACK, CANCEL, BYE, REFER, NOTIFY, OPTIONS
Contact: <sip:'SIP_ID't0@85.16.64.57:15527>
X-Grandstream-PBX: true
Content-Type: application/sdp
Content-Length: 372
v=0
o=- 2869140560 2869140560 IN IP4 85.16.64.57
s=call
c=IN IP4 85.16.64.57
t=0 0
m=audio 8938 RTP/AVP 0 8 4 18 2 97 9 3
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:4 G723/8000
a=rtpmap:18 G729/8000
a=rtpmap:2 G726-32/8000
a=rtpmap:97 iLBC/8000
a=rtpmap:9 G722/8000
a=rtpmap:3 GSM/8000
a=fmtp:18 annexb=no
a=fmtp:97 mode=20
a=sendrecv
a=ptime:20
[SIP-Packet] 2011/02/04 09:25:26,080 [PACKET] :
Receiving datagram with length 472 from 217.10.68.150:5060 to 85.16.64.57:15527
SIP/2.0 407 Proxy Authentication Required
Via: SIP/2.0/UDP 85.16.64.57:15527;branch=z9hG4bK-cda4fc0f-8c06242c
From: "Horst"<sip:49441361810742@sipconnect.sipgate.de;user=phone>;tag=1975038921--741119201
To: <sip:04413990338@sipconnect.sipgate.de>;tag=efae1b206a1df22b5fbc395b5a747d13.ff29
Call-ID: 2373336801@00a05711fb6a
CSeq: 1 INVITE
Proxy-Authenticate: Digest realm="sipconnect.sipgate.de", nonce="4d4bb922807d2d798a6d79e4c30ee73ea54c1dc3"
Content-Length: 0
[SIP-Packet] 2011/02/04 09:25:26,080 [PACKET] :
Sending datagram with length 515 from 85.16.64.57:15527 to 217.10.68.150:5060
ACK sip:04413990338@sipconnect.sipgate.de SIP/2.0
Via: SIP/2.0/UDP 85.16.64.57:15527;branch=z9hG4bK-cda4fc0f-8c06242c
From: "Horst"<sip:49441361810742@sipconnect.sipgate.de;user=phone>;tag=1975038921--741119201
To: <sip:04413990338@sipconnect.sipgate.de>;tag=efae1b206a1df22b5fbc395b5a747d13.ff29
Call-ID: 2373336801@00a05711fb6a
CSeq: 1 ACK
Max-Forwards: 70
User-Agent: Grandstream GXP1200 1.2.5.3
Server: Stargateol
Allow: REGISTER, INVITE, ACK, CANCEL, BYE, REFER, NOTIFY, OPTIONS
Content-Length: 0
[SIP-Packet] 2011/02/04 09:25:26,090 [PACKET] :
Sending datagram with length 1159 from 85.16.64.57:15527 to 217.10.68.150:5060 rtg-tag:1
INVITE sip:04413990338@sipconnect.sipgate.de SIP/2.0
Via: SIP/2.0/UDP 85.16.64.57:15527;branch=z9hG4bK-f51bd94b-44afe16e
From: "Horst"<sip:49441361810742@sipconnect.sipgate.de;user=phone>;tag=1975038921--741119201
To: <sip:04413990338@sipconnect.sipgate.de>
Call-ID: 2373336801@00a05711fb6a
CSeq: 2 INVITE
Max-Forwards: 70
User-Agent: Grandstream GXP1200 1.2.5.3
Server: Stargateol
Allow: REGISTER, INVITE, ACK, CANCEL, BYE, REFER, NOTIFY, OPTIONS
Proxy-Authorization: Digest username="'SIP_ID't0",realm="sipconnect.sipgate.de",nonce="4d4bb922807d2d798a6d79e4c30ee73ea54c1dc3",uri="sip:04413990338@sipconnect.sipgate.de",algorithm=MD5,response="e6fb7b00d0693f71263c5248a2d8c554"
Contact: <sip:'SIP_ID't0@85.16.64.57:15527>
Content-Type: application/sdp
Content-Length: 372
v=0
o=- 1434570280 1434570280 IN IP4 85.16.64.57
s=call
c=IN IP4 85.16.64.57
t=0 0
m=audio 8938 RTP/AVP 0 8 4 18 2 97 9 3
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:4 G723/8000
a=rtpmap:18 G729/8000
a=rtpmap:2 G726-32/8000
a=rtpmap:97 iLBC/8000
a=rtpmap:9 G722/8000
a=rtpmap:3 GSM/8000
a=fmtp:18 annexb=no
a=fmtp:97 mode=20
a=sendrecv
a=ptime:20
[SIP-Packet] 2011/02/04 09:25:26,140 [PACKET] :
Receiving datagram with length 363 from 217.10.68.150:5060 to 85.16.64.57:15527
SIP/2.0 403 Forbidden (check from field)
Via: SIP/2.0/UDP 85.16.64.57:15527;branch=z9hG4bK-f51bd94b-44afe16e
From: "Horst"<sip:49441361810742@sipconnect.sipgate.de;user=phone>;tag=1975038921--741119201
To: <sip:04413990338@sipconnect.sipgate.de>;tag=efae1b206a1df22b5fbc395b5a747d13.8e07
Call-ID: 2373336801@00a05711fb6a
CSeq: 2 INVITE
Content-Length: 0
[SIP-Packet] 2011/02/04 09:25:26,140 [PACKET] :
Sending datagram with length 473 from 85.16.64.57:15527 to 217.10.68.150:5060
ACK sip:04413990338@sipconnect.sipgate.de SIP/2.0
Via: SIP/2.0/UDP 85.16.64.57:15527;branch=z9hG4bK-f51bd94b-44afe16e
From: "Horst"<sip:49441361810742@sipconnect.sipgate.de;user=phone>;tag=1975038921--741119201
To: <sip:04413990338@sipconnect.sipgate.de>
Call-ID: 2373336801@00a05711fb6a
CSeq: 2 ACK
Max-Forwards: 70
User-Agent: Grandstream GXP1200 1.2.5.3
Server: Stargateol
Allow: REGISTER, INVITE, ACK, CANCEL, BYE, REFER, NOTIFY, OPTIONS
Content-Length: 0
[SIP-Packet] 2011/02/04 09:25:26,160 [PACKET] :
Sending datagram with length 401 from 10.1.1.1:5060 to 10.1.1.62:5060
SIP/2.0 403 Forbidden (check from field)
Via: SIP/2.0/UDP 10.1.1.62:5060;branch=z9hG4bK2d0b5c7826926e2a
From: "Horst"<sip:42@10.1.1.1>;tag=52226ba26c89ec95
To: <sip:04413990338@10.1.1.1>;tag=1257472925--236053809
Call-ID: f275f55a75e1744e@10.1.1.62
CSeq: 33357 INVITE
Max-Forwards: 70
Server: Stargateol
Allow: REGISTER, INVITE, ACK, CANCEL, BYE, REFER, NOTIFY, OPTIONS
Content-Length: 0
[SIP-Packet] 2011/02/04 09:25:26,180 [PACKET] :
Receiving datagram with length 720 from 10.1.1.62:5060 to 10.1.1.1:5060
ACK sip:04413990338@10.1.1.1 SIP/2.0
Via: SIP/2.0/UDP 10.1.1.62:5060;branch=z9hG4bK2d0b5c7826926e2a
From: "Horst" <sip:42@10.1.1.1>;tag=52226ba26c89ec95
To: <sip:04413990338@10.1.1.1>;tag=1257472925--236053809
Contact: <sip:42@10.1.1.62:5060;transport=udp>
Supported: path
X-Grandstream-PBX: true
Proxy-Authorization: Digest username="42", realm="10.1.1.1", algorithm=MD5, uri="sip:04413990338@10.1.1.1", nonce="afcc80fbba5ec35db097e28e584bf147", response="0b297cc7cd39f0c04225c49d8514bd6a"
Call-ID: f275f55a75e1744e@10.1.1.62
CSeq: 33357 ACK
User-Agent: Grandstream GXP1200 1.2.5.3
Max-Forwards: 70
Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE,UPDATE,PRACK,MESSAGE
Content-Length: 0
vielen Dank für die schnelle Antwort.
Ich habe das Problem leider nicht ausführlich genug beschrieben.
1. Registrieren funktioniert
2. Ankommende Gespräche kommen am richtigen Telefon an und funktionieren tadellos
3. Abgehende Gespräche sind unmöglich "Forbidden (check from field)"
hier ist meine Konfiguration und ein Trace - vielleicht sagt das ja mehr aus zusammen mit der Info von Sipgate, dass die ein "P-Preferred-Identity" benötigen (siehe oben)
LINE
Mode Trunk
Provider name SGTRUNK
SIP domain/realm sipconnect.sipgate.de
Outbound proxy sipconnect.live.sipgate.de
SIP-ID/user 'SIP_ID't0
MAPPING
Trunk/gateway name SGTRUNK
External number/name 4944136181074#
Length of called number 1
Internal dest. number 4#
[SIP-Packet] 2011/02/04 09:25:25,940 [PACKET] :
Receiving datagram with length 921 from 10.1.1.62:5060 to 10.1.1.1:5060
INVITE sip:04413990338@10.1.1.1 SIP/2.0
Via: SIP/2.0/UDP 10.1.1.62:5060;branch=z9hG4bK0729f799f260ead9
From: "Horst" <sip:42@10.1.1.1>;tag=52226ba26c89ec95
To: <sip:04413990338@10.1.1.1>
Contact: <sip:42@10.1.1.62:5060;transport=udp>
Supported: replaces, timer, path
X-Grandstream-PBX: true
P-Early-Media: Supported
Call-ID: f275f55a75e1744e@10.1.1.62
CSeq: 33356 INVITE
User-Agent: Grandstream GXP1200 1.2.5.3
Max-Forwards: 70
Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE,UPDATE,PRACK,MESSAGE
Content-Type: application/sdp
Content-Length: 340
v=0
o=42 8000 8000 IN IP4 10.1.1.62
s=SIP Call
c=IN IP4 10.1.1.62
t=0 0
m=audio 5086 RTP/AVP 0 8 4 18 2 97 9 3
a=sendrecv
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:4 G723/8000
a=rtpmap:18 G729/8000
a=rtpmap:2 G726-32/8000
a=rtpmap:97 iLBC/8000
a=fmtp:97 mode=20
a=rtpmap:9 G722/8000
a=rtpmap:3 GSM/8000
a=ptime:20
[SIP-Packet] 2011/02/04 09:25:25,940 [PACKET] :
Sending datagram with length 417 from 10.1.1.1:5060 to 10.1.1.62:5060
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.1.1.62:5060;branch=z9hG4bK0729f799f260ead9
From: "Horst"<sip:42@10.1.1.1>;tag=52226ba26c89ec95
To: <sip:04413990338@10.1.1.1>
Call-ID: f275f55a75e1744e@10.1.1.62
CSeq: 33356 INVITE
Max-Forwards: 70
User-Agent: LANCOM 1724 VoIP (Annex B) / 8.00.0162 / 16.06.2010
Server: Stargateol
Allow: REGISTER, INVITE, ACK, CANCEL, BYE, REFER, NOTIFY, OPTIONS
Content-Length: 0
[SIP-Packet] 2011/02/04 09:25:25,940 [PACKET] :
Sending datagram with length 494 from 10.1.1.1:5060 to 10.1.1.62:5060
SIP/2.0 407 login needed
Via: SIP/2.0/UDP 10.1.1.62:5060;branch=z9hG4bK0729f799f260ead9
From: "Horst"<sip:42@10.1.1.1>;tag=52226ba26c89ec95
To: <sip:04413990338@10.1.1.1>;tag=1257472925--236053809
Call-ID: f275f55a75e1744e@10.1.1.62
CSeq: 33356 INVITE
Max-Forwards: 70
Server: Stargateol
Allow: REGISTER, INVITE, ACK, CANCEL, BYE, REFER, NOTIFY, OPTIONS
Proxy-Authenticate: Digest realm="10.1.1.1",nonce="afcc80fbba5ec35db097e28e584bf147",opaque="",algorithm=MD5
Content-Length: 0
[SIP-Packet] 2011/02/04 09:25:25,970 [PACKET] :
Receiving datagram with length 525 from 10.1.1.62:5060 to 10.1.1.1:5060
ACK sip:04413990338@10.1.1.1 SIP/2.0
Via: SIP/2.0/UDP 10.1.1.62:5060;branch=z9hG4bK0729f799f260ead9
From: "Horst" <sip:42@10.1.1.1>;tag=52226ba26c89ec95
To: <sip:04413990338@10.1.1.1>;tag=1257472925--236053809
Contact: <sip:42@10.1.1.62:5060;transport=udp>
Supported: path
X-Grandstream-PBX: true
Call-ID: f275f55a75e1744e@10.1.1.62
CSeq: 33356 ACK
User-Agent: Grandstream GXP1200 1.2.5.3
Max-Forwards: 70
Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE,UPDATE,PRACK,MESSAGE
Content-Length: 0
[SIP-Packet] 2011/02/04 09:25:25,990 [PACKET] :
Receiving datagram with length 1116 from 10.1.1.62:5060 to 10.1.1.1:5060
INVITE sip:04413990338@10.1.1.1 SIP/2.0
Via: SIP/2.0/UDP 10.1.1.62:5060;branch=z9hG4bK2d0b5c7826926e2a
From: "Horst" <sip:42@10.1.1.1>;tag=52226ba26c89ec95
To: <sip:04413990338@10.1.1.1>
Contact: <sip:42@10.1.1.62:5060;transport=udp>
Supported: replaces, timer, path
X-Grandstream-PBX: true
P-Early-Media: Supported
Proxy-Authorization: Digest username="42", realm="10.1.1.1", algorithm=MD5, uri="sip:04413990338@10.1.1.1", nonce="afcc80fbba5ec35db097e28e584bf147", response="0b297cc7cd39f0c04225c49d8514bd6a"
Call-ID: f275f55a75e1744e@10.1.1.62
CSeq: 33357 INVITE
User-Agent: Grandstream GXP1200 1.2.5.3
Max-Forwards: 70
Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE,UPDATE,PRACK,MESSAGE
Content-Type: application/sdp
Content-Length: 340
v=0
o=42 8000 8001 IN IP4 10.1.1.62
s=SIP Call
c=IN IP4 10.1.1.62
t=0 0
m=audio 5086 RTP/AVP 0 8 4 18 2 97 9 3
a=sendrecv
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:4 G723/8000
a=rtpmap:18 G729/8000
a=rtpmap:2 G726-32/8000
a=rtpmap:97 iLBC/8000
a=fmtp:97 mode=20
a=rtpmap:9 G722/8000
a=rtpmap:3 GSM/8000
a=ptime:20
[SIP-Packet] 2011/02/04 09:25:25,990 [PACKET] :
Sending datagram with length 417 from 10.1.1.1:5060 to 10.1.1.62:5060
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.1.1.62:5060;branch=z9hG4bK2d0b5c7826926e2a
From: "Horst"<sip:42@10.1.1.1>;tag=52226ba26c89ec95
To: <sip:04413990338@10.1.1.1>
Call-ID: f275f55a75e1744e@10.1.1.62
CSeq: 33357 INVITE
Max-Forwards: 70
User-Agent: LANCOM 1724 VoIP (Annex B) / 8.00.0162 / 16.06.2010
Server: Stargateol
Allow: REGISTER, INVITE, ACK, CANCEL, BYE, REFER, NOTIFY, OPTIONS
Content-Length: 0
[SIP-Packet] 2011/02/04 09:25:26,030 [PACKET] :
Sending datagram with length 953 from 85.16.64.57:15527 to 217.10.68.150:5060 rtg-tag:1
INVITE sip:04413990338@sipconnect.sipgate.de SIP/2.0
Via: SIP/2.0/UDP 85.16.64.57:15527;branch=z9hG4bK-cda4fc0f-8c06242c
From: "Horst"<sip:49441361810742@sipconnect.sipgate.de;user=phone>;tag=1975038921--741119201
To: <sip:04413990338@sipconnect.sipgate.de>
Call-ID: 2373336801@00a05711fb6a
CSeq: 1 INVITE
Max-Forwards: 70
User-Agent: Grandstream GXP1200 1.2.5.3
Server: Stargateol
Allow: REGISTER, INVITE, ACK, CANCEL, BYE, REFER, NOTIFY, OPTIONS
Contact: <sip:'SIP_ID't0@85.16.64.57:15527>
X-Grandstream-PBX: true
Content-Type: application/sdp
Content-Length: 372
v=0
o=- 2869140560 2869140560 IN IP4 85.16.64.57
s=call
c=IN IP4 85.16.64.57
t=0 0
m=audio 8938 RTP/AVP 0 8 4 18 2 97 9 3
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:4 G723/8000
a=rtpmap:18 G729/8000
a=rtpmap:2 G726-32/8000
a=rtpmap:97 iLBC/8000
a=rtpmap:9 G722/8000
a=rtpmap:3 GSM/8000
a=fmtp:18 annexb=no
a=fmtp:97 mode=20
a=sendrecv
a=ptime:20
[SIP-Packet] 2011/02/04 09:25:26,080 [PACKET] :
Receiving datagram with length 472 from 217.10.68.150:5060 to 85.16.64.57:15527
SIP/2.0 407 Proxy Authentication Required
Via: SIP/2.0/UDP 85.16.64.57:15527;branch=z9hG4bK-cda4fc0f-8c06242c
From: "Horst"<sip:49441361810742@sipconnect.sipgate.de;user=phone>;tag=1975038921--741119201
To: <sip:04413990338@sipconnect.sipgate.de>;tag=efae1b206a1df22b5fbc395b5a747d13.ff29
Call-ID: 2373336801@00a05711fb6a
CSeq: 1 INVITE
Proxy-Authenticate: Digest realm="sipconnect.sipgate.de", nonce="4d4bb922807d2d798a6d79e4c30ee73ea54c1dc3"
Content-Length: 0
[SIP-Packet] 2011/02/04 09:25:26,080 [PACKET] :
Sending datagram with length 515 from 85.16.64.57:15527 to 217.10.68.150:5060
ACK sip:04413990338@sipconnect.sipgate.de SIP/2.0
Via: SIP/2.0/UDP 85.16.64.57:15527;branch=z9hG4bK-cda4fc0f-8c06242c
From: "Horst"<sip:49441361810742@sipconnect.sipgate.de;user=phone>;tag=1975038921--741119201
To: <sip:04413990338@sipconnect.sipgate.de>;tag=efae1b206a1df22b5fbc395b5a747d13.ff29
Call-ID: 2373336801@00a05711fb6a
CSeq: 1 ACK
Max-Forwards: 70
User-Agent: Grandstream GXP1200 1.2.5.3
Server: Stargateol
Allow: REGISTER, INVITE, ACK, CANCEL, BYE, REFER, NOTIFY, OPTIONS
Content-Length: 0
[SIP-Packet] 2011/02/04 09:25:26,090 [PACKET] :
Sending datagram with length 1159 from 85.16.64.57:15527 to 217.10.68.150:5060 rtg-tag:1
INVITE sip:04413990338@sipconnect.sipgate.de SIP/2.0
Via: SIP/2.0/UDP 85.16.64.57:15527;branch=z9hG4bK-f51bd94b-44afe16e
From: "Horst"<sip:49441361810742@sipconnect.sipgate.de;user=phone>;tag=1975038921--741119201
To: <sip:04413990338@sipconnect.sipgate.de>
Call-ID: 2373336801@00a05711fb6a
CSeq: 2 INVITE
Max-Forwards: 70
User-Agent: Grandstream GXP1200 1.2.5.3
Server: Stargateol
Allow: REGISTER, INVITE, ACK, CANCEL, BYE, REFER, NOTIFY, OPTIONS
Proxy-Authorization: Digest username="'SIP_ID't0",realm="sipconnect.sipgate.de",nonce="4d4bb922807d2d798a6d79e4c30ee73ea54c1dc3",uri="sip:04413990338@sipconnect.sipgate.de",algorithm=MD5,response="e6fb7b00d0693f71263c5248a2d8c554"
Contact: <sip:'SIP_ID't0@85.16.64.57:15527>
Content-Type: application/sdp
Content-Length: 372
v=0
o=- 1434570280 1434570280 IN IP4 85.16.64.57
s=call
c=IN IP4 85.16.64.57
t=0 0
m=audio 8938 RTP/AVP 0 8 4 18 2 97 9 3
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:4 G723/8000
a=rtpmap:18 G729/8000
a=rtpmap:2 G726-32/8000
a=rtpmap:97 iLBC/8000
a=rtpmap:9 G722/8000
a=rtpmap:3 GSM/8000
a=fmtp:18 annexb=no
a=fmtp:97 mode=20
a=sendrecv
a=ptime:20
[SIP-Packet] 2011/02/04 09:25:26,140 [PACKET] :
Receiving datagram with length 363 from 217.10.68.150:5060 to 85.16.64.57:15527
SIP/2.0 403 Forbidden (check from field)
Via: SIP/2.0/UDP 85.16.64.57:15527;branch=z9hG4bK-f51bd94b-44afe16e
From: "Horst"<sip:49441361810742@sipconnect.sipgate.de;user=phone>;tag=1975038921--741119201
To: <sip:04413990338@sipconnect.sipgate.de>;tag=efae1b206a1df22b5fbc395b5a747d13.8e07
Call-ID: 2373336801@00a05711fb6a
CSeq: 2 INVITE
Content-Length: 0
[SIP-Packet] 2011/02/04 09:25:26,140 [PACKET] :
Sending datagram with length 473 from 85.16.64.57:15527 to 217.10.68.150:5060
ACK sip:04413990338@sipconnect.sipgate.de SIP/2.0
Via: SIP/2.0/UDP 85.16.64.57:15527;branch=z9hG4bK-f51bd94b-44afe16e
From: "Horst"<sip:49441361810742@sipconnect.sipgate.de;user=phone>;tag=1975038921--741119201
To: <sip:04413990338@sipconnect.sipgate.de>
Call-ID: 2373336801@00a05711fb6a
CSeq: 2 ACK
Max-Forwards: 70
User-Agent: Grandstream GXP1200 1.2.5.3
Server: Stargateol
Allow: REGISTER, INVITE, ACK, CANCEL, BYE, REFER, NOTIFY, OPTIONS
Content-Length: 0
[SIP-Packet] 2011/02/04 09:25:26,160 [PACKET] :
Sending datagram with length 401 from 10.1.1.1:5060 to 10.1.1.62:5060
SIP/2.0 403 Forbidden (check from field)
Via: SIP/2.0/UDP 10.1.1.62:5060;branch=z9hG4bK2d0b5c7826926e2a
From: "Horst"<sip:42@10.1.1.1>;tag=52226ba26c89ec95
To: <sip:04413990338@10.1.1.1>;tag=1257472925--236053809
Call-ID: f275f55a75e1744e@10.1.1.62
CSeq: 33357 INVITE
Max-Forwards: 70
Server: Stargateol
Allow: REGISTER, INVITE, ACK, CANCEL, BYE, REFER, NOTIFY, OPTIONS
Content-Length: 0
[SIP-Packet] 2011/02/04 09:25:26,180 [PACKET] :
Receiving datagram with length 720 from 10.1.1.62:5060 to 10.1.1.1:5060
ACK sip:04413990338@10.1.1.1 SIP/2.0
Via: SIP/2.0/UDP 10.1.1.62:5060;branch=z9hG4bK2d0b5c7826926e2a
From: "Horst" <sip:42@10.1.1.1>;tag=52226ba26c89ec95
To: <sip:04413990338@10.1.1.1>;tag=1257472925--236053809
Contact: <sip:42@10.1.1.62:5060;transport=udp>
Supported: path
X-Grandstream-PBX: true
Proxy-Authorization: Digest username="42", realm="10.1.1.1", algorithm=MD5, uri="sip:04413990338@10.1.1.1", nonce="afcc80fbba5ec35db097e28e584bf147", response="0b297cc7cd39f0c04225c49d8514bd6a"
Call-ID: f275f55a75e1744e@10.1.1.62
CSeq: 33357 ACK
User-Agent: Grandstream GXP1200 1.2.5.3
Max-Forwards: 70
Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE,UPDATE,PRACK,MESSAGE
Content-Length: 0
Hallo Horst,
also dann muss sipgate hierbei was geändert haben. Früher funktionierte das ohne Probleme. Ich habe leider im Augenblick keinen Trunk-Account, mit dem ich das nachstellen könnte.
Eigentlich würde ich hier eher den Fehler auf der sipgate-Seite suchen (wollen). Was sagt sipgate denn dazu? Ich meine früher funktionierte das, warum jetzt nicht mehr?
Und wenn man es so macht:
From: <sip:1182504t0@sipconnect.sipgate.de>
P-Preferred-Identity: <sip:49441361810742@sipconnect.sipgate.de>,
dann sieht man auf der Gegenseite, wenn sie denn auch ein sipgate-Kunde ist (also "sipgate-interner" Anruf) und P-Preferred nicht unterstützt, die blöde SIP-ID in der Form 1182504t0. Gerade dieses Problem aus dem sipgate basic/plus, seit Jahren immer wieder Grund zum Ärgernis, das hat im IPPF ganze Threads gefüllt und wurde unterm Strich mit P-Preferred nur lieblos gepatcht und funktioniert daher immer noch nicht richtig, sollte bei sipgate team/trunk kein Thema mehr sein... Ich verstehe echt nicht, was sipgate sich dabei denkt.
Viele Grüße,
Jirka
also dann muss sipgate hierbei was geändert haben. Früher funktionierte das ohne Probleme. Ich habe leider im Augenblick keinen Trunk-Account, mit dem ich das nachstellen könnte.
Eigentlich würde ich hier eher den Fehler auf der sipgate-Seite suchen (wollen). Was sagt sipgate denn dazu? Ich meine früher funktionierte das, warum jetzt nicht mehr?
Und wenn man es so macht:
From: <sip:1182504t0@sipconnect.sipgate.de>
P-Preferred-Identity: <sip:49441361810742@sipconnect.sipgate.de>,
dann sieht man auf der Gegenseite, wenn sie denn auch ein sipgate-Kunde ist (also "sipgate-interner" Anruf) und P-Preferred nicht unterstützt, die blöde SIP-ID in der Form 1182504t0. Gerade dieses Problem aus dem sipgate basic/plus, seit Jahren immer wieder Grund zum Ärgernis, das hat im IPPF ganze Threads gefüllt und wurde unterm Strich mit P-Preferred nur lieblos gepatcht und funktioniert daher immer noch nicht richtig, sollte bei sipgate team/trunk kein Thema mehr sein... Ich verstehe echt nicht, was sipgate sich dabei denkt.
Viele Grüße,
Jirka
Hallo Horst und Jirka,
ich habe das selbige Problem mit solch einem Account von Sipgate.
Ich nutze zur Zeit auch einen solchen Testaccount. Die Traceergebnisse sind die selben.
Die Auskunft von Sipgate ebenfalls die selbe, nicht die Rufnummer sondern die Sip-Id mit dem 't' drin muß übermittelt werden, daher der 403-Fehler....
Habt Ihr denn schon eine Lösung für dieses Problem finden können ?
Beste Grüße von
Dirk
ich habe das selbige Problem mit solch einem Account von Sipgate.
Ich nutze zur Zeit auch einen solchen Testaccount. Die Traceergebnisse sind die selben.
Die Auskunft von Sipgate ebenfalls die selbe, nicht die Rufnummer sondern die Sip-Id mit dem 't' drin muß übermittelt werden, daher der 403-Fehler....
Habt Ihr denn schon eine Lösung für dieses Problem finden können ?
Beste Grüße von
Dirk
Hi Dirk,
Lancom hat mir deutlich zu verstehen gegeben, dass dieser Bug nicht beseitigt wird und mit größter Wahrscheinlichkeit auch niemals beseitigt werden wird.
Wir behelfen uns hier mit einem zweiten Account, der als rufende Nummer die der Zentrale liefert. Die Durchwahl des Trunks funktioniert natürlich trotzdem.
Hier die Config:
# Setup/Voice-Call-Manager/Lines/SIP-Provider/Line
add "SIPGATE0" {17} 0 {2} "sipgate.de" {14} 1 {3} 5060 {4} "account2e0" {5} "" {15} "" {6} "passwort2" {16} "" {7} "" {8} "" {9} "" {12} 00000000 {13} 0 {18} 0 {19} 0 {20} 0 {21} 0 {22} 600 {23} 0 {24} 0 {25} 0 {10} 0 {11} ""
add "SGTRUNK" {17} 1 {2} "sipconnect.sipgate.de" {14} 1 {3} 5060 {4} "account1t0" {5} "" {15} "" {6} "passwort1" {16} "" {7} "sipconnect.live.sipgate.de" {8} "" {9} "" {12} 00000000 {13} 0 {18} 0 {19} 0 {20} 0 {21} 0 {22} 60 {23} 0 {24} 1 {25} 0 {10} 0 {11} ""
# Setup/Voice-Call-Manager/Lines/SIP-Provider/Mapping
add "SGTRUNK" "4944136181070" "898" {4} 0 {7} 0 {5} 0 {6} "Zentrale"
add "SGTRUNK" "4944136181071" "69" {4} 0 {7} 0 {5} 0 {6} "Helmut"
add "SGTRUNK" "4944136181072" "101" {4} 0 {7} 0 {5} 0 {6} "Sandra"
add "SGTRUNK" "4944136181073" "100" {4} 0 {7} 0 {5} 0 {6} "Nadica"
add "SGTRUNK" "4944136181074" "9062223560" {4} 0 {7} 0 {5} 0 {6} "Adam"
add "SGTRUNK" "4944136181075" "102" {4} 0 {7} 0 {5} 0 {6} "Goran"
add "SGTRUNK" "4944136181076" "90621838218" {4} 0 {7} 0 {5} 0 {6} "Nokia rot"
add "SGTRUNK" "4944136181074#" "4#" {4} 1 {7} 0 {5} 0 {6} ""
add "SGTRUNK" "4944136181075#" "5#" {4} 1 {7} 0 {5} 0 {6} ""
# Setup/Voice-Call-Manager/Call-Router/Call-Routing
add "0#" "" "" "" "" {7} "0#" {8} "SIPGATE0" {11} "" {12} "" {13} "" {14} "" {15} 0 {9} 0 {10} "extern"
Lancom hat mir deutlich zu verstehen gegeben, dass dieser Bug nicht beseitigt wird und mit größter Wahrscheinlichkeit auch niemals beseitigt werden wird.
Wir behelfen uns hier mit einem zweiten Account, der als rufende Nummer die der Zentrale liefert. Die Durchwahl des Trunks funktioniert natürlich trotzdem.
Hier die Config:
# Setup/Voice-Call-Manager/Lines/SIP-Provider/Line
add "SIPGATE0" {17} 0 {2} "sipgate.de" {14} 1 {3} 5060 {4} "account2e0" {5} "" {15} "" {6} "passwort2" {16} "" {7} "" {8} "" {9} "" {12} 00000000 {13} 0 {18} 0 {19} 0 {20} 0 {21} 0 {22} 600 {23} 0 {24} 0 {25} 0 {10} 0 {11} ""
add "SGTRUNK" {17} 1 {2} "sipconnect.sipgate.de" {14} 1 {3} 5060 {4} "account1t0" {5} "" {15} "" {6} "passwort1" {16} "" {7} "sipconnect.live.sipgate.de" {8} "" {9} "" {12} 00000000 {13} 0 {18} 0 {19} 0 {20} 0 {21} 0 {22} 60 {23} 0 {24} 1 {25} 0 {10} 0 {11} ""
# Setup/Voice-Call-Manager/Lines/SIP-Provider/Mapping
add "SGTRUNK" "4944136181070" "898" {4} 0 {7} 0 {5} 0 {6} "Zentrale"
add "SGTRUNK" "4944136181071" "69" {4} 0 {7} 0 {5} 0 {6} "Helmut"
add "SGTRUNK" "4944136181072" "101" {4} 0 {7} 0 {5} 0 {6} "Sandra"
add "SGTRUNK" "4944136181073" "100" {4} 0 {7} 0 {5} 0 {6} "Nadica"
add "SGTRUNK" "4944136181074" "9062223560" {4} 0 {7} 0 {5} 0 {6} "Adam"
add "SGTRUNK" "4944136181075" "102" {4} 0 {7} 0 {5} 0 {6} "Goran"
add "SGTRUNK" "4944136181076" "90621838218" {4} 0 {7} 0 {5} 0 {6} "Nokia rot"
add "SGTRUNK" "4944136181074#" "4#" {4} 1 {7} 0 {5} 0 {6} ""
add "SGTRUNK" "4944136181075#" "5#" {4} 1 {7} 0 {5} 0 {6} ""
# Setup/Voice-Call-Manager/Call-Router/Call-Routing
add "0#" "" "" "" "" {7} "0#" {8} "SIPGATE0" {11} "" {12} "" {13} "" {14} "" {15} 0 {9} 0 {10} "extern"
Hallo hsudholz,
vielen Dank für die Info.
Ich habe das jetzt auch angefangen so zu realisieren, aber dann wählt er doch beim Aufbau einer externen Verbindung immer über die "normale" Leitung "SIPGATE0" und dieses Konto raus ?! Oder?
Das Mapping, also von extern hereinrufen und an den richtigen Apparat leiten funktioniert.
Beste Grüße von Dirk.
vielen Dank für die Info.
Ich habe das jetzt auch angefangen so zu realisieren, aber dann wählt er doch beim Aufbau einer externen Verbindung immer über die "normale" Leitung "SIPGATE0" und dieses Konto raus ?! Oder?
Das Mapping, also von extern hereinrufen und an den richtigen Apparat leiten funktioniert.
Beste Grüße von Dirk.
Hallo zusammen,
also zumindest das Problem mit der Übertragung der Rufnummer lässt sich in gewisser Weise lösen. Sipgate bietet die Möglichkeit, unter Einstellungen -> Telefonie -> Absenderrufnummer setzen einzustellen, dass die Absenderrufnummer das Endgerät setzt. Dieses muss die Rufnummer dann als SIP-DisplayName übertragen. Bei IP-Telefonen kann man selbigen im Allgemeinen einstellen, wenn es sich nicht gerade um eine FRITZ!Box handelt. Er ist dann in der Form 49Vorwahl(ohneNull)Rufnummer anzugeben. Bei Gigasets ist das z. B. unter Einstellungen -> Telefonie -> Verbindungen -> VoIP-Verbindung (bearbeiten) -> Angezeigter Name möglich. Bei ISDN-Telefonen (oder analogen) ist es möglich den Display-Namen im LANCOM in der ISDN-Benutzer-Tabelle unter Anzeige-Name zu hinterlegen.
Viele Grüße,
Jirka
also zumindest das Problem mit der Übertragung der Rufnummer lässt sich in gewisser Weise lösen. Sipgate bietet die Möglichkeit, unter Einstellungen -> Telefonie -> Absenderrufnummer setzen einzustellen, dass die Absenderrufnummer das Endgerät setzt. Dieses muss die Rufnummer dann als SIP-DisplayName übertragen. Bei IP-Telefonen kann man selbigen im Allgemeinen einstellen, wenn es sich nicht gerade um eine FRITZ!Box handelt. Er ist dann in der Form 49Vorwahl(ohneNull)Rufnummer anzugeben. Bei Gigasets ist das z. B. unter Einstellungen -> Telefonie -> Verbindungen -> VoIP-Verbindung (bearbeiten) -> Angezeigter Name möglich. Bei ISDN-Telefonen (oder analogen) ist es möglich den Display-Namen im LANCOM in der ISDN-Benutzer-Tabelle unter Anzeige-Name zu hinterlegen.
Viele Grüße,
Jirka
Hallo alle,
ich betätige mich mal als Thread-Leichen-Fledderer, denn genau dieses Problem habe ich jetzt auch. Der Anlagenanschluss beim magenta T soll vollständig in einen SIPGATE Trunk übertragen werden. Daher habe ich zuerst einmal einen SIPtrunk test-registriert und aufgeschaltet. Einkommende Anrufe werden einwandfrei signalisiert und kommen auch zustande.
Ausgehende aber nicht. Genau das gleiche Problem: Als ausgehender Nutzer soll die SIP-ID gesetzt werden.
Und ich habe eine HALBE Lösung! Wenn ich im SIP-Mapping als externe Rufnummer die SIP-ID eintrage, dann funktionieren die ausgehenden Anrufe! Aber natürlich leider die eingehenden nicht mehr. Also habe ich einfach BEIDE Einträge erstellt, und nun geht es.
Nur kann das natürlich jederzeit kippen, denn ich kann ja nicht beeinflussen, welchen Eintrag das Mapping sich für ausgehende nun holt. Jetzt holt er sich wohl zufällig das richtige. Kann man das irgendwie beeinflussen? Das wäre auch fürs ISDN-Mapping interessant. Oder wird immer der zuerst erstellte genommen?
Auch wenn LANCOM den eigentlichen Grund in der Fehlerbehebung ablehnt - das kann ich verstehen - so wäre eine Priorität an dieser Stelle echt sinnvoll. Oder habe ich die nur übersehen?
Grüße,
Sebastian
ich betätige mich mal als Thread-Leichen-Fledderer, denn genau dieses Problem habe ich jetzt auch. Der Anlagenanschluss beim magenta T soll vollständig in einen SIPGATE Trunk übertragen werden. Daher habe ich zuerst einmal einen SIPtrunk test-registriert und aufgeschaltet. Einkommende Anrufe werden einwandfrei signalisiert und kommen auch zustande.
Ausgehende aber nicht. Genau das gleiche Problem: Als ausgehender Nutzer soll die SIP-ID gesetzt werden.
Und ich habe eine HALBE Lösung! Wenn ich im SIP-Mapping als externe Rufnummer die SIP-ID eintrage, dann funktionieren die ausgehenden Anrufe! Aber natürlich leider die eingehenden nicht mehr. Also habe ich einfach BEIDE Einträge erstellt, und nun geht es.
Nur kann das natürlich jederzeit kippen, denn ich kann ja nicht beeinflussen, welchen Eintrag das Mapping sich für ausgehende nun holt. Jetzt holt er sich wohl zufällig das richtige. Kann man das irgendwie beeinflussen? Das wäre auch fürs ISDN-Mapping interessant. Oder wird immer der zuerst erstellte genommen?
Auch wenn LANCOM den eigentlichen Grund in der Fehlerbehebung ablehnt - das kann ich verstehen - so wäre eine Priorität an dieser Stelle echt sinnvoll. Oder habe ich die nur übersehen?
Grüße,
Sebastian