Summary: | ASTERISK-05911: Asterisk does not handle call from a Cisco IAD correctly | ||
Reporter: | yamez (yamez) | Labels: | |
Date Opened: | 2005-12-27 13:31:29.000-0600 | Date Closed: | 2011-06-07 14:03:22 |
Priority: | Major | Regression? | No |
Status: | Closed/Complete | Components: | Channels/chan_sip/Interoperability |
Versions: | Frequency of Occurrence | ||
Related Issues: | |||
Environment: | Attachments: | ||
Description: | When my Cisco IAD sends a call to my Asterisk gateway the gateway treats it as if I don't have a peer statement in sip.conf, when I do. Here are the first two packets, notice the "Found no matching peer or user for '192.168.7.250:50437'" on the second packet. sip.conf: [bna-vonx-iad] type=friend context=trusted-out host=192.168.7.250 canreinvite=no <-- SIP read from 192.168.7.250:52141: INVITE sip:6155555917@192.168.53.68:5060 SIP/2.0 Via: SIP/2.0/UDP 192.168.7.250:5060;branch=z9hG4bK1A60 From: "James Sizemore" <sip:6155552115@192.168.7.250>;tag=19D8A640-5E9 To: <sip:6155555917@192.168.53.68> Date: Wed, 06 Mar 2002 00:27:08 GMT Call-ID: BA75B677-2FCF11D6-806AB8FC-77734AF8@192.168.7.250 Supported: 100rel,timer Min-SE: 1800 Cisco-Guid: 3128236623-802099670-2154346748-2004044536 User-Agent: Cisco-SIPGateway/IOS-12.x Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTER CSeq: 101 INVITE Max-Forwards: 6 Remote-Party-ID: "James Sizemore" <sip:6155552115@192.168.7.250>;party=calling;screen=yes;privacy=off Timestamp: 1015374428 Contact: <sip:6155552115@192.168.7.250:5060> Expires: 180 Allow-Events: telephone-event Content-Type: application/sdp Content-Length: 191 v=0 o=CiscoSystemsSIP-GW-UserAgent 6047 8216 IN IP4 192.168.7.250 s=SIP Call c=IN IP4 192.168.7.250 t=0 0 m=audio 16434 RTP/AVP 0 c=IN IP4 192.168.7.250 a=rtpmap:0 PCMU/8000 a=ptime:20 20 headers, 9 lines Using latest request as basis request Sending to 192.168.7.250 : 5060 (non-NAT) Found no matching peer or user for '192.168.7.250:50437' Found RTP audio format 0 Peer audio RTP is at port 192.168.7.250:16434 Found description format PCMU Capabilities: us - 0x78e (gsm|ulaw|alaw|lpc10|g729|speex|ilbc), peer - audio=0x4 (ulaw)/video=0x0 (nothing), combined - 0x4 (ulaw) Non-codec capabilities: us - 0x1 (g723), peer - 0x0 (nothing), combined - 0x0 (nothing) Looking for 6155555917 in default list_route: hop: <sip:6155552115@192.168.7.250:5060> Transmitting (no NAT): SIP/2.0 100 Trying Via: SIP/2.0/UDP 192.168.7.250:5060;branch=z9hG4bK1A60 From: "James Sizemore" <sip:6155552115@192.168.7.250>;tag=19D8A640-5E9 To: <sip:6155555917@192.168.53.68>;tag=as43478a8a Call-ID: BA75B677-2FCF11D6-806AB8FC-77734AF8@192.168.7.250 CSeq: 101 INVITE User-Agent: Memphis ISDN-NET PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER Contact: <sip:6155555917@192.168.53.68> Content-Length: 0 ****** ADDITIONAL INFORMATION ****** I think I found what is munging up the peer lookup: This call from another Asterisk box starts: <-- SIP read from 192.168.69.254:5060: The peer lookup that fail reads: <-- SIP read from 192.168.7.250:52141: Asterisk seem to be thrown off by the fact that the return port is not 5060, and fails the peer lookup. This is the only diffrence I see from a working call packet. | ||
Comments: | By: Tilghman Lesher (tilghman) 2005-12-27 15:24:40.000-0600 Could you upload a file containing the SIP REGISTER for the same host? Also, in the future, please attach SIP debugs as separate files, instead of pasting them into bugnotes or descriptions. By: yamez (yamez) 2005-12-28 09:06:49.000-0600 The peer statement is listed befow. neither side registers with the other. [bna-vonx-iad] type=friend context=trusted-out host=192.168.7.250 canreinvite=no The problem is that Asterisk assumes the host is 192.168.7.250:5060 not 192.168.7.250:* By: yamez (yamez) 2005-12-29 15:07:23.000-0600 What We need here is "insecure=port ; Allow matching of user by IP address without matching port number" for users as well as peers. As this is a incoming call with out registration. And I do trust the ip. By: yamez (yamez) 2006-01-02 06:17:53.000-0600 This does the trick. I still think this should be the default action I should not need the "insecure=port,invite" [bna-vonx-iad] type=peers host=192.168.7.250 insecure=port,invite context=trusted-out By: Tilghman Lesher (tilghman) 2006-01-02 08:49:17.000-0600 Closed by request of reporter. |