 |
|
 |
|
| Autor |
Nachricht |
SunSeb
Anmeldungsdatum: 09.12.2004
Beiträge: 148
Wohnort: Bonn
|
Verfasst am:
So 19 Jul, 2009 17:33 |
  |
|
Liebes Forum,
ich habe ein wenig mit einem Cisco 7975 an einem LC1823 herumgespielt. Beide lassen sich momentan leider nicht zu einer Zusammenarbeit überreden. Das Problem sind meiner Meinung nach die Ports bei den SIP-Messsages.
LC1823 mit 10.1.1.1 und das Cisco mit 10.1.1.120
| Code:
|
[SIP-Packet] 2009/07/19 17:14:51,030 [PACKET] :
Receiving datagram with length 557 from 10.1.1.120:49608 to 10.1.1.1:5060
REGISTER sip:dmbeuel SIP/2.0\r\n
Via: SIP/2.0/UDP 10.1.1.120:5060;branch=z9hG4bK7735112a\r\n
From: <sip:207@dmbeuel>;tag=002584a384cd000bbb55c5c9-ed383744\r\n
To: <sip:207@dmbeuel>\r\n
Call-ID: 002584a3-84cd0002-178bac68-a2233198@10.1.1.120\r\n
Max-Forwards: 70\r\n
Date: Sun, 19 Jul 2009 15:14:51 GMT\r\n
CSeq: 105 REGISTER\r\n
User-Agent: Cisco-CP7975G/8.5.2\r\n
Contact: <sip:207@10.1.1.120:5060;transport=udp>;+sip.instance="<urn:uuid:00000000-00
model.ccm.cisco.com="437"\r\n
Supported: (null),X-cisco-xsi-7.0.1\r\n
Content-Length: 0\r\n
Expires: 120\r\n
\r\n
|
Hier versucht das Cisco eine Registrierung am LC. Der Source Port 49608 statt 5060 ist etwas untypisch, aber wohl RFC-konform.
| Code:
|
[SIP-Packet] 2009/07/19 17:14:51,030 [PACKET] :
Sending datagram with length 444 from 10.1.1.1:5060 to 10.1.1.120:5060
SIP/2.0 200 OK\r\n
Via: SIP/2.0/UDP 10.1.1.120:5060;branch=z9hG4bK7735112a\r\n
From: <sip:207@dmbeuel>;tag=002584a384cd000bbb55c5c9-ed383744\r\n
To: <sip:207@dmbeuel>;tag=1559812550-1356972128\r\n
Call-ID: 002584a3-84cd0002-178bac68-a2233198@10.1.1.120\r\n
CSeq: 105 REGISTER\r\n
Max-Forwards: 70\r\n
Server: Luna\r\n
Allow: REGISTER, INVITE, ACK, CANCEL, BYE, REFER, NOTIFY, OPTIONS\r\n
Contact: <sip:207@10.1.1.120:5060;transport=udp>;expires=120\r\n
Content-Length: 0\r\n
\r\n
|
Das LC1823 antwortet mit einem OK und schickt dies "richtigerweise" an den Port 5060 und nicht 49608. Im Contact-Feld ist dieser Port auch noch mal explizit erwähnt. Die Anmeldung funktioniert.
| Code:
|
[SIP-Packet] 2009/07/19 17:15:04,380 [PACKET] :
Sending datagram with length 868 from 10.1.1.1:5060 to 10.1.1.120:49608
INVITE sip:207@dmbeuel;transport=udp SIP/2.0\r\n
Via: SIP/2.0/UDP 10.1.1.1:5060;branch=z9hG4bK-f252c621-47261fe0\r\n
From: "Beuel-XL"<sip:203@dmbeuel;user=phone>;tag=-269731268--1737646855\r\n
To: <sip:207@dmbeuel;transport=udp;user=phone>\r\n
Call-ID: 3096267233@00a057123022\r\n
CSeq: 1 INVITE\r\n
Max-Forwards: 70\r\n
Server: Luna\r\n
Allow: REGISTER, INVITE, ACK, CANCEL, BYE, REFER, NOTIFY, OPTIONS\r\n
Contact: <sip:203@10.1.1.1:5060>\r\n
Content-Type: application/sdp\r\n
Content-Length: 399\r\n
\r\n
v=0\r\n
o=- 2986223568 2986223568 IN IP4 10.1.1.1\r\n
s=call\r\n
c=IN IP4 10.1.1.1\r\n
t=0 0\r\n
m=audio 19668 RTP/AVP 0 8 106 18 2 104 103 101 102\r\n
a=rtpmap:0 PCMU/8000\r\n
a=rtpmap:8 PCMA/8000\r\n
a=rtpmap:106 G726-40/8000\r\n
a=rtpmap:18 G729/8000\r\n
a=rtpmap:2 G726-32/8000\r\n
a=rtpmap:104 G726-24/8000\r\n
a=rtpmap:103 G726-16/8000\r\n
a=rtpmap:101 telephone-event/8000\r\n
a=rtpmap:102 tone/8000\r\n
a=fmtp:18 annexb=no\r\n
a=sendrecv\r\n
|
Hier geht nun ein Anruf für das Cisco ein. Das INVITE wird jetzt aber nicht an den Port 5060 gesendet, sondern an 49608. Hier hört das Telefon aber nicht zu und klingelt nicht.
Meine Frage ist nun: Müsste beim INVITE und dem folgenden SIP-Handshake nicht der Port 5060 benutzt werden? Ist hier nicht das Contact-Feld maßgebend. Warum verhält sich das "OK" anders als das "INVITE"? Ein Asterisk (natürlich nicht maßgebend) verhält sich zumindest so...
Ich würde mich über einen kleinen Kommentar freuen - vielleicht gibt es Ideen,
SEBastian |
|
|
   |
|
Guest
|
Verfasst am:
|
 |
|
|
|
|
backslash
Moderator
Anmeldungsdatum: 08.11.2004
Beiträge: 4568
Wohnort: Aachen
|
Verfasst am:
Mo 20 Jul, 2009 20:55 |
  |
|
Hi SunSeb,
ich persönlich würde sagen, daß die Antwort, die das LANCOM an den Port 5060 schickt falsch ist. Sie müßte statdessen (wie das INVITE) auch an den Port 49608 geschickt werden. Grund hierfür ist, daß zwischen dem Telefon und dem LANCOM ein NAT sitzen könnte, das Pakete an den port 5060 einfach verwerfen würde...
Das Telefon seinerseits müßte auf dem Port 49608 auf das INVITE warten - aus dem selben Grund: Ein NAT würde Paket auf den Port 5060 verwerfen, nicht aber auf den durch das Telefon "von innen" geöffneten Port 49608...
Kannst du an dem Cisco-Telefon einstellen, auf welchen Port es lauschen soll?
Gruß
Backslash |
|
|
   |
|
|
|
|
| |
|
|