Return the actual SIP status code for rejected <dial/> requests

[loopingrage]

There is growing desire among the Rayo Community for lower level access to SIP status codes; specifically the error code produced by the far end when rejecting an outgoing INVITE.

It was probably naive and slightly idealistic to think that Rayo Clients could be completely encapsulated from the underlying protocol used by it's callers (e.g. SIP, Jingle, ISDN).

My proposal:

• Deprecate <busy/> and extend <reject/> to include the most common sub-reasons

<presence to='[email protected]/1' from='[email protected]/1'>
  <end xmlns='urn:xmpp:rayo:1'>    
    <reject>
      <user-busy/>
    </reject>
  </end>
</presence>

• Allow protocol-specific sub-elements to provide additional fidelity

<presence to='[email protected]/1' from='[email protected]/1'>
  <end xmlns='urn:xmpp:rayo:1' xmlns:sip='urn:xmpp:rayo:sip-ext:1'>    
    <reject>
      <user-busy/>
      <sip:status-code>486<sip:status-code/>
    </reject>
  </end>
</presence>

This issue is a request for comment so please don't be shy :-)

[mpermar]

Would it be worth to make generic the protocol specifics? Like instead of <sip:status-code>486<sip:status-code/> something like <meta key="protocol" value="sip"/> <meta key="status-code" value="486"/> so parsers would not need to be aware of the different protocols. Just wondering.

[benlangfeld]

How far do we want to go with this? Do we want to allow status codes as a child of any reason element? Every event (<ringing/>) and such? Do we have any SIP messages that are currently swallowed and do not result in any Rayo event? Do we want to expose these as SIP-specific events?

[loopingrage]

There certainly are some SIP messages that do not currently result in any Rayo event. SUBSCRIBE/NOTIFY are a perfect example. However, I suspect most of the missing messages can be mapped in some protocol-agnostic agnostic way.

Since we already surface headers, it's really things like status codes that are the issue here.

[loopingrage]

thoughts?

[mpermar]

I vote for an agnostic representation that keeps the parsers simple and let client applications to interpret the data they receive. Maybe with a couple of new tags, maybe using headers, ...

Also question is would this somehow pollute the protocol for applications that are not interested in the protocol specifics? This could be solved with a flag in the Rayo Server Prism's implentation that would set "protocol verbosity" to on and off. Again, not sure if this is necessary.

[benlangfeld]

So, in line with the "XMPP way", I would vote for separate elements, specified in extension specs. I already intend for there to be a rayo-sip spec, outlining best practices for mapping, and this can go there.

I would imagine that being able to turn the verbosity up or down was unnecessary. XMPP clients typically ignore what they do not understand.

[mpermar]

Well this topic also raises the question of Rayo being too tied to XMPP which was questioned by some people.

[benlangfeld]

If rayo is to be specified outside the bounds of XMPP, we need to
address several issues (namespaces etc) and write the spec as an IETF
RFC, rather than an XEP.

Enviado via iPad

Em 3 Feb 2012, às 09:01, mpermar
[email protected]
escreveu:

Well this topic also raises the question of Rayo being too tied to XMPP which was questioned by some people.

---

Reply to this email directly or view it on GitHub:
#16 (comment)

[benlangfeld]

Any thoughts on the RFC vs XEP issue?

[loopingrage]

I like it as XEP. I see no reason why we couldn't steer away from using urn:xmpp namespaces regardless just in case though.