[Standards-JIG] Jingle xeps

Matthew O'Gorman mogorman at astjab.org
Thu Oct 12 07:40:27 UTC 2006

xep-166 (jingle)
responder field, I noticed this was added on the final accept.  I
understand that initiator might be helpful in debugging who started
the call and make logging easier, but responder?  isn't that just
added fluff that is not needed, i mean if we do a redirect it is a
whole redirect when would you have a case where that information would
be different?
should the states of the call be in the signalling, ringing busy or
not in service etc.  Why are they shoved in xep-167?

xep-167 (jingle-audio)
When would a call be ringing vs queued?  Also on this note I still
don't see a best practices for early media.  I understand that in the
p2p jabber network you would probably not want it all the time, but in
terminating with legacy voip, and pstn equipment it is often
busy should be in xep-166

xep-180 (jingle-video)
Shouldn't the codecs in the example be video codecs right?
and rest obviously still needs to be fleshed out.

xep-181 (jingle-dtmf)
Xep-181 should allow for 0,1,2,3,4,5,6,7,8,9,*,#,a,b,c,d for dtmf
interoperability text currently doesn't explicitly say that.
Shouldn't we also ack the xmpp packet for button down and up? set then
ack result? If that is already case text is not 100% clear to me then.
shouldn't rfc2833 ability be visible via discovery along with the
preferred xmpp dtmf signalling?
I also think it should be specified as well that the dtmf audio should
never ever be represented inband in the call as part of the spec and
not best practices, as dtmf inband is truly a nightmare.

xep-177(jingle raw udp)
no transport accept like with 176? Currently in xep-176 as soon as you
confirm that it is a valid link via stun you accept the transport,
should we do the same, as soon as we receive udp audio accept the

xep-176 (jingle-ice)
stun server advertised by server? Should your network's stun server be
advertised via your xmpp server?
in xep-176 it refers to termination of the call which is out of its
scope i would think.

Also there is still no xep for raw rtp.  the ice spec is implemented
via stun and rtp but there are several possible instances where
stunning would not be needed, closed lan, or gatewaying via sip etc.

And finally i think the xep-179 (jingle-iax) is not needed currently.
There are several ways currently to seek out and negotiate iax2
traffic, dundi enum, iax2 switches.   but that is just a personal
opinion, I don't see how it could hurt anyone though.

I implemented xep-183 this weekend i was wondering if anyone was
interested in an interop? ^_^

More information about the Standards mailing list