Subject: [Stox] core: response code mappings

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 16 Aug 2013 20:28:11 -0600

The SIP Parameters Registry has a list of SIP response codes:

http://www.iana.org/assignments/sip-parameters/sip-parameters.xml#sip-parameters-7

A number of those are not specified in RFC 3261. Thus the question
arises: for which codes do we need to define mappings? We could define
mappings for all of them, but I wonder if that's advisable. Some of the
additional codes are specified in RFCs that update RFC 3261 (e.g., code
440 from RFC 5393), whereas other codes are specified in "non-core" RFCs
that don't update RFC 3261 (e.g., code 470 from RFC 5360). Would it
perhaps make sense to map the "core" codes and not the "non-core" codes?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: "Olle E. Johansson" <[email-masked]>
Date: Sat, 17 Aug 2013 09:28:16 +0200

> perhaps make sense to map the "core" codes and not the "non-core" codes?

I don't really have any good answer. Can just look into the Asterisk code and see
that we've implemented a selection... :-)

The important part is to have a generic mapping for 2xx, 3xx, 4xx, 5xx and 6xx codes,
so that if a gateway gets an unknown code, it knows how to map it to something. In SIP,
an unknown 4xx code is the same as 400 etc.

After years of struggling with translations between SIP and ISDN in the Asterisk core,
I know that this is a hard problem. Especially in the case where you have SIP -> xmpp -> SIP 
and want the same error code on the other side. You simply can't please everyone when
mapping between two protocols.

/O

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 18 Aug 2013 21:20:09 -0600

Hi Olle, that is helpful feedback.

> an unknown 4xx code is the same as 400 etc.

True. I think we can provide that information in the stox-core spec
(e.g., in XMPP <bad-request/> is like a default 400). That way, if an
entity encounters a response code that it doesn't understand, at least
it can map it appropriately.

> mapping between two protocols.

Agreed. Those round-trip mappings are especially difficult, but it would
be good to look at a few examples because I think we'll end up at
default things like SIP 400 codes in a lot of situations. I'll
investigate the matter soon and post some proposed text to this list.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Mon, 19 Aug 2013 21:13:59 +0200

> it can map it appropriately.

+1

--
Saúl Ibarra Corretgé
AG Projects

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 19 Aug 2013 16:02:43 -0400

> perhaps make sense to map the "core" codes and not the "non-core" codes?

I know this is almost a non-answer, but...

The codes that are defined in other RFCs are there to support features 
that are introduced in those RFCs. If there is a mapping of that feature 
to XMPP, then there should be a mapping of the code.

If there is no mapping of the feature, then mapping the code is less 
important, but still perhaps useful in some cases. E.g., it could 
conceivably show up in a Reason code based on signaling that was never 
gatewayed to xmpp. But maybe a default mapping would be sufficient in 
those cases.

	Thanks,
	Paul

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 19 Aug 2013 14:23:33 -0600

> to XMPP, then there should be a mapping of the code.

That makes sense.

> gatewayed to xmpp. But maybe a default mapping would be sufficient in

I suspect that the default mapping would be fine.

And in general, there might be more art than science here.

I have written some proposed text for this section, but it's fairly long
so my inclination is to submit a revised I-D and then folks can review
what I've written and post to the list with feedback.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Daniel-Constantin Mierla <[email-masked]>
Date: Mon, 19 Aug 2013 23:44:09 +0200

> what I've written and post to the list with feedback.
Looking at the latest draft, it seems to bring confusion on mapping from 
xmpp-to-sip on 400 code. I read this thread and kind of understood that 
any not-obvious-mapping similar-to-a-4xx case would be handled same as 
400 in SIP, but typically the 400 response is given for a malformed sip 
requests (like broken grammar).

After quick read, <conflict/> would map more suggestively to 403 
Forbidden. Maybe <policy-violation> and <undefined-condition/> could get 
other mappings as well.

Daniel

-- 
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 19 Aug 2013 16:07:09 -0600

> requests (like broken grammar).

So your suggestion is that we avoid mapping XMPP error conditions to SIP
400 unless the XMPP condition is caused by a malformed request?

> Forbidden. 

As I said, it's perhaps more art than science. But mapping <conflict/>
to 403 seems reasonable if we accept your suggestion about not mapping
to 400 unless we have a good reason to do so.

> Maybe <policy-violation> and <undefined-condition/> could get
> other mappings as well.

Well, depending on the policy being violated, <policy-violation/> might
map to 413, 414, 513, or even 406/606.

Given that <undefined-condition/> is something of a catch-all, it's not
clear to me what we'd map it to in a consistent way. That would probably
depend on the application-specific element contained in the error stanza.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Daniel-Constantin Mierla <[email-masked]>
Date: Tue, 20 Aug 2013 10:43:47 +0200

> 400 unless the XMPP condition is caused by a malformed request?
Yes, <bad-request/> qualifies for that. Otherwise, could create 
confusion for implementers of sip endpoints - from sip rfc:
21.4.1 400 Bad Request

    The request could not be understood due to malformed syntax.  The
    Reason-Phrase SHOULD identify the syntax problem in more detail, for
    example, "Missing Call-ID header field".

> map to 413, 414, 513, or even 406/606.

I would find more appropriate 500 than 400 for mapping, also because 
these situations are more server related. 500 is the most generic error 
code in sip from my point of view -- is used even for SIP message 
related situations, such as CSeq value in a request within a dialog is 
lower than previous received one.

The section in the draft seems to be a global mapping, it is no 
difference between types of errors in xmpp -- there can be same error 
tag for streams and stanzas. For example <conflict/> for streams says:

4.9.3.3. conflict

    The server either (1) is closing the existing stream for this entity
    because a new stream has been initiated that conflicts with the
    existing stream, or (2) is refusing a new stream for this entity
    because allowing the new stream would conflict with an existing
    stream (e.g., because the server allows only a certain number of
    connections from the same IP address or allows only one server-to-
    server stream for a given domain pair as a way of helping to ensure
    in-order processing as described under Section 10.1).

The second example above can be associated with 'No more channels' in a 
SIP media server/gateway -- 500 is used in this case (at least Asterisk 
did it :-) ).
> depend on the application-specific element contained in the error stanza.
Indeed, could be application/case-to-case specific mapping, but 
otherwise I think 500 should be the catch-all case in sip side.

Daniel

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 20 Aug 2013 10:55:02 +0200

20 aug 2013 kl. 10:43 skrev Daniel-Constantin Mierla <[email-masked]>:

> Yes, <bad-request/> qualifies for that. Otherwise, could create confusion for implementers of sip endpoints - from sip rfc:
> 21.4.1 400 Bad Request
> 
> 
> I would find more appropriate 500 than 400 for mapping, also because these situations are more server related. 500 is the most generic error code in sip from my point of view -- is used even for SIP message related situations, such as CSeq value in a request within a dialog is lower than previous received one.
> 
> The section in the draft seems to be a global mapping, it is no difference between types of errors in xmpp -- there can be same error tag for streams and stanzas. For example <conflict/> for streams says:
> 
> 4.9.3.3. conflict
> 
> 
> The second example above can be associated with 'No more channels' in a SIP media server/gateway -- 500 is used in this case (at least Asterisk did it :-) ).
>> 
> Indeed, could be application/case-to-case specific mapping, but otherwise I think 500 should be the catch-all case in sip side.

Not really.

5xx codes indicates mostly server errors, meaning that the request may succeed in another server.
6xx and 4xx errors indicate something wrong related to the request, no point in trying elsewhere. RFC 3261:
21.4 Request Failure 4xx

   4xx responses are definite failure responses from a particular
   server.  The client SHOULD NOT retry the same request without
   modification (for example, adding appropriate authorization).
   However, the same request to a different server might be successful.

21.5 Server Failure 5xx

   5xx responses are failure responses given when a server itself has
   erred.

I agree that when we have a specific error condition in XMPP we should map it properly to an error code in SIP, but we also need some generic mapping. Like for the Kamailio-specific 4xx  error codes that only Kamailio understands :-)

Section 8.1.3.2 of RFC 3261 clarifies:

8.1.3.2 Unrecognized Responses

   A UAC MUST treat any final response it does not recognize as being
   equivalent to the x00 response code of that class, and MUST be able
   to process the x00 response code for all classes.  For example, if a
   UAC receives an unrecognized response code of 431, it can safely
   assume that there was something wrong with its request and treat the
   response as if it had received a 400 (Bad Request) response code.  A
   UAC MUST treat any provisional response different than 100 that it
   does not recognize as 183 (Session Progress).  A UAC MUST be able to
   process 100 and 183 responses.

It doesn't mean we should use 400,500,600 as generic codes, but treat unknown
the same way as we treat the even ones. If we receive 679, we should act as if
we received 600. 

Does jabber separate "server errors" and "request errors"?

/O

---

From: Daniel-Constantin Mierla <[email-masked]>
Date: Tue, 20 Aug 2013 11:14:30 +0200

On 8/20/13 10:55 AM, Olle E. Johansson wrote:
>
> 20 aug 2013 kl. 10:43 skrev Daniel-Constantin Mierla 
> <[email-masked] <mailto:[email-masked]>>:
>
>>
>> these situations are more server related. 500 is the most generic 
>> error code in sip from my point of view -- is used even for SIP 
>> message related situations, such as CSeq value in a request within a 
>> dialog is lower than previous received one.
>>
>> The second example above can be associated with 'No more channels' in 
>> a SIP media server/gateway -- 500 is used in this case (at least 
>> Asterisk did it :-) ).
6xx are indeed global, but many of 4xx can succeed on retry or other 
place (e.g., calling to germany can get 404 on a pstn gateway with no 
route to this country but can succeed on other gateway with such route).

Anyhow, it is what I understand from the xmpp error tags I listed above 
(being currently mapped to 400). For example, number of streams 
(4.9.3.3. conflict) is a server related option, has nothing to do with 
the format of the request or processing the request per se -- it is not 
accepted because local server policy/available resources.

> I agree that when we have a specific error condition in XMPP we should 
> map it properly to an error code in SIP, but we also need some generic 
> mapping. Like for the Kamailio-specific 4xx  error codes that only 
> Kamailio understands :-)
>

I would interpret that in more like generic way:
- unknown >=300 is negative response, closing transaction/dialog
- unknown 4xx or 5xx means a retry could work (at same place or 
different one)
- unknown 6xx means giving up completely

So it might be better to define new 'generic' reply codes for each class 
and let the sip endpoint handle them as stated in rfc (and pasted above).

Daniel

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 20 Aug 2013 16:07:58 -0600

> and let the sip endpoint handle them as stated in rfc (and pasted above).

Well, this WG is not chartered to define anything new, so I think that's
a non-starter. :-)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Daniel-Constantin Mierla <[email-masked]>
Date: Wed, 21 Aug 2013 00:36:20 +0200

> Well, this WG is not chartered to define anything new, so I think that's
3-6xx classes are defined, with rules how to handle those codes unknown 
locally. Not sure is better to misuse an existing one versus just using 
a random unallocated one from the appropriate class. Anyhow, coming back 
to the initial opinion, I find 400 mapping to be confusing in some 
situations, as it is defined for malformed sip requests and it is not 
the case. Would be good to find more appropriate codes.

Daniel