[Asterisk-Dev] SIP codes/behaviors

[Mark Willis]

Kevin P. Fleming wrote:

> 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.

I agree. I even pointed out the paragraph in the RFC that says "zero or 
more 100's", but they don't care. It's "a Level3 requirement". Maybe if 
I go back and say others don't have to meet this requirement they will 
back down.


>> 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.

And again, but in this case they are translating back to a PSTN code and 
they route advance only on certain PSTN codes. I chose 603 because that 
mapped to a PSTN code they could handle. 503 caused them to drop the 
call and not try another route. I don't really care that 603 is the 
wrong code, I just need to enable the customer to re-route the call.

Marvellous, is interoperability. I'd prefer to follow the standard but 
in both cases I'm being prevented from doing so...

Mark