[Asterisk-Dev] SIP codes/behaviors

[Sherwood McGowan]

Yes, my company has a working Asterisk to Level 3 implementation.  

->-----Original Message-----
->From: asterisk-dev-bounces at lists.digium.com 
->[mailto:asterisk-dev-bounces at lists.digium.com] On Behalf Of 
->Arick Davis
->Sent: Tuesday, August 23, 2005 1:36 PM
->To: 'Asterisk Developers Mailing List'
->Subject: RE: [Asterisk-Dev] SIP codes/behaviors
->
->I've been pulling my hair out trying to complete Level3 3(i) 
->testing. For
->Level3 DID inbound? Apparently Asterisk 
->(CVS-v1-0-08/19/05-17:35:46) is not sending the level3 
->requirement of a 487 Term. Req. at the end of a call.
->
->Does anyone have inbound DID working on Asterisk with Level3? 
->I would appreciate any help and or advice on how to pass 
->these acceptance tests.
->
->Arick Davis
->International Telcom Ltd.
->
->
->-----Original Message-----
->From: asterisk-dev-bounces at lists.digium.com
->[mailto:asterisk-dev-bounces at lists.digium.com] On Behalf Of 
->Kevin P. Fleming
->Sent: Monday, August 22, 2005 3:02 PM
->To: Asterisk Developers Mailing List
->Subject: Re: [Asterisk-Dev] SIP codes/behaviors
->
->Mark Willis wrote:
->> I have two SIP issues. In one case we're dealing with Level3, who 
->> always require a 100 Trying in response to an INVITE. 
->Problem is this 
->> is for an unprovisioned number. So I want to send a 100 
->then a 404. I 
->> can't find a way to do this, since asterisk just sends the 404. If 
->> there was an NotFound application I could just call that 
->and asterisk 
->> would send the 100 followed by a 404 in the NotFound app.
->
->This is completely unreasonable on their part; there is no 
->legitimate reason to require a '100 Trying' response to an 
->INVITE before sending a final response. We have other users 
->successfully interoperating with
->Level3 with Asterisk CVS HEAD that don't have this issue.
->
->> In the second case, we're terminating calls. If we run out of lines 
->> the customer wants a SIP 603, rather than the 503 asterisk sends on 
->> Congestion().
->
->Quoting from RFC3261:
->
->21.6.2 603 Decline
->
->    The callee's machine was successfully contacted but the user
->    explicitly does not wish to or cannot participate.  The 
->response MAY
->    indicate a better time to call in the Retry-After header 
->field.  This
->    status response is returned only if the client knows that no other
->    end point will answer the request.
->
->A 603 response would be inappropriate here, since the callee 
->was not contacted and did not decline the call. There could 
->also be other paths that would answer the request (since you 
->are only out of channels), so again 603 would be inappropriate.
->_______________________________________________
->Asterisk-Dev mailing list
->Asterisk-Dev at lists.digium.com
->http://lists.digium.com/mailman/listinfo/asterisk-dev
->To UNSUBSCRIBE or update options visit:
->   http://lists.digium.com/mailman/listinfo/asterisk-dev
->
->
->_______________________________________________
->Asterisk-Dev mailing list
->Asterisk-Dev at lists.digium.com
->http://lists.digium.com/mailman/listinfo/asterisk-dev
->To UNSUBSCRIBE or update options visit:
->   http://lists.digium.com/mailman/listinfo/asterisk-dev
->