On 01/02/2012 11:21 AM, sean darcy wrote:
On 01/01/2012 11:34 PM, sean darcy wrote:
I'm trying to setup a simple tcp sip connection based on the toronto
osaka example in the Asterisk book.
On the remote box (osaka) (1.8.9.0-rc1):
[toronto]
type=friend
transport=tcp
secret=welcome
context=toronto_incoming
host=dynamic
disallow=all
allow=ulaw
sip show peer toronto
* Name : toronto
Secret : <Set>
MD5Secret : <Not set>
Remote Secret: <Not set>
Context : toronto_incoming
........
Useragent : Asterisk PBX 10.1.0-rc1
Reg. Contact : sip:osaka@<toronto>:5060;transport=TCP
On the home box (toronto) (10.1.0-rc1):
register => tcp://toronto:welcome@officePBX/osaka
[osaka]
type=friend
transport=tcp
secret=welcome
context=incoming
host=dynamic
disallow=all
allow=ulaw
But make a call from the remote Dial(SIP/toronto) , and the home cli
shows:
Call from '' (<remote>:5060) to extension 'osaka' rejected because
extension not found in context 'default'.
which makes no sense to me at all. Doesn't the string after the "/" in
register refer to the user/device on the box doing the register? Doesn't
it tell the device on the remote host which local device to connect to?
i.e., toronto@remote > osaka@home ?? And where's context "default"
coming from?
Is the book just out of date? Or is tcp not ready?
sean
Looks like tcp is messed up. Or is my setup somehow flawed? Does anyone
have tcp working?
Turning on sip debug on toronto gave the below INVITE. Notice From:
"Anonymous" <sip:Anonymous@anonymous.invalid>
Why isn't this toronto <sip:toronto@<osaka>> ? As it is, Anonymous
becomes the peer/user, which is not found. Then osaka is viewed as the
extension - not the peer - and context default is searched for osaka.
<--- SIP read from TCP:<osaka>:5060 --->
INVITE sip:osaka@<toronto>:5060;transport=TCP SIP/2.0
Via: SIP/2.0/TCP <osaka>:5060;branch=z9hG4bK41111f7e;rport
Max-Forwards: 70
From: "Anonymous" <sip:Anonymous@anonymous.invalid>;tag=as697266a6
To: <sip:osaka@<toronto>:5060;transport=TCP>
Contact: <sip:Anonymous@184.75.103.142:5060;transport=TCP>
Call-ID: 6f7df020162fa79f7e58b2015ab0f410@<osaka>:5060
CSeq: 102 INVITE
User-Agent: Asterisk PBX 1.8.9.0-rc1
Date: Mon, 02 Jan 2012 15:58:22 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
INFO, PUBLISH
Supported: replaces, timer
Content-Type: application/sdp
Content-Length: 244
v=0
o=root 1399746571 1399746571 IN IP4 <osaka>
s=Asterisk PBX 1.8.9.0-rc1
c=IN IP4 <osaka>
t=0 0
m=audio 11112 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv
<------------->
--- (14 headers 11 lines) ---
== Using UDPTL TOS bits 184
== Using UDPTL CoS mark 5
Sending to <osaka>:5060 (NAT)
Using INVITE request as basis request -
6f7df020162fa79f7e58b2015ab0f410@<osaka>:5060
No matching peer for 'Anonymous' from '<osaka>:5060'
== Using SIP RTP TOS bits 184
== Using SIP RTP CoS mark 5
Found RTP audio format 0
Found RTP audio format 101
Found audio description format PCMU for ID 0
Found audio description format telephone-event for ID 101
Capabilities: us - (gsm|ulaw|alaw|speex|g722), peer -
audio=(ulaw)/video=(nothing)/text=(nothing), combined - (ulaw)
Non-codec capabilities (dtmf): us - 0x1 (telephone-event|), peer - 0x1
(telephone-event|), combined - 0x1 (telephone-event|)
Peer audio RTP is at port <osaka>:11112
Looking for osaka in default (domain <toronto>)
<--- Reliably Transmitting (NAT) to <osaka>:5060 --->
SIP/2.0 404 Not Found
Via: SIP/2.0/TCP
<osaka>:5060;branch=z9hG4bK41111f7e;received=<osaka>;rport=5060
From: "Anonymous" <sip:Anonymous@anonymous.invalid>;tag=as697266a6
To: <sip:osaka@<toronto>:5060;transport=TCP>;tag=as3e025900
Call-ID: 6f7df020162fa79f7e58b2015ab0f410@184.75.103.142:5060
CSeq: 102 INVITE
Server: Asterisk PBX 10.1.0-rc1
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
INFO, PUBLISH
Supported: replaces, timer
Content-Length: 0
<------------>
[Jan 2 10:58:22] NOTICE[6432]: chan_sip.c:23063 handle_request_invite:
Call from '' (<osaka>:5060) to extension 'osaka' rejected because
extension not found in context 'default'.
Scheduling destruction of SIP dialog
'6f7df020162fa79f7e58b2015ab0f410@<osaka>:5060' in 32000 ms (Method:
INVITE)
As I think about it, isn't this a problem with 10.1.0 on toronto.
The INVITE is correct:
INVITE sip:osaka@<toronto>:5060;transport=TCP SIP/2.0
so why isn't 10.1.0 looking for peer "osaka"?
Is it simply a mistake that it's taking the user from the FROM header
rather than the INVITE?
sean
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
http://www.asterisk.org/hello
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
