To:
<sip:8009499...@x.yyy.32.10:5060>;tag=ac86f72d2bfe10395b2e62e01c70bf66.0f65
In your call sample To has a tag.
if this is the first Invite it can't have a tag at the end, otherwise
Asterisk will look for an existing dialog in its database and will show
an error, if can't find any.
It looks like the other end is never closing the previous dialog?.. is
Asterisk sending a proper 200 OK after receiving a BYE?
NAT problem?
regards,
--
==================================
Miguel Oyarzo
DevOps Engineer
http://www.linkedin.com/in/mikeaustralia
Linux User: # 483188 - counter.li.org
Melbourne, Australia
On 9/17/2013 6:18 AM, Vik Killa wrote:
Asterisk is sending a 481 in response to an INVITE for reasons I do
not understand. Here is the INVITE:
INVITE sip:8009499...@x.yyy.32.3:5060;transport=udp SIP/2.0
Record-Route: <sip:X.YYY.32.10;lr=on;ftag=247898>
To:
<sip:8009499...@x.yyy.32.10:5060>;tag=ac86f72d2bfe10395b2e62e01c70bf66.0f65
From: "Scott Thompson" <sip:7166359...@x.yyy.32.10>;tag=247898
Via: SIP/2.0/UDP X.YYY.32.10;branch=z9hG4bK542e.5042d534.0
Via: SIP/2.0/UDP
X.YYY.33.178:5060;rport=5060;received=X.YYY.33.178;branch=z9hG4bK57b720cccb00f8498662f48e8
Call-ID: 94f80f866e877490729548a079abe371@192.168.101.5
<mailto:94f80f866e877490729548a079abe371@192.168.101.5>
CSeq: 2 INVITE
Contact: <sip:7166359...@x.yyy.33.178:5060>
Max-Forwards: 69
x-inin-crn: 2001471530;loc=Amherst;ms=STAMPEDE-MS
Supported: join, replaces
User-Agent: ININ-TsServer/3.13.11.12748
Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, REFER,
SUBSCRIBE
Accept: application/sdp
Accept-Encoding: identity
Content-Type: application/sdp
Content-Length: 252
Proxy-Authorization: Digest
username="909003660716",realm="X.YYY.32.10",nonce="5237559000011a22ed0fae66765d46ef9131e311fbb9d2fb",uri="sip:8009499...@x.yyy.32.10:5060",response="cb6306569b3047ac35064dcb5aee6db4"
X-Enswitch-RURI: sip:8009499...@x.yyy.32.10:5060
X-Enswitch-Source: X.YYY.33.178:5060
The only problem I see with this INVITE is the VIAs are not right
after the INVITE line... although in
https://www.ietf.org/rfc/rfc3261.txt, it explicitly states the the
order of the headers is not a requirement, it seems Asterisk does make
it one...
"The relative order of header fields with different field names is not
significant. However, it is RECOMMENDED that header fields which are
needed for proxy processing (Via, Route, Record-Route, Proxy-Require,
Max-Forwards, and Proxy-Authorization, for example) appear towards
the top of the message to facilitate rapid parsing. The relative
order of header field rows with the same field name is important."
--
_____________________________________________________________________
-- 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
--
_____________________________________________________________________
-- 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
