[Standards-JIG] Jingle xeps
stpeter at jabber.org
Tue Oct 31 20:04:09 UTC 2006
Sorry, finally catching up on email here...
Matthew O'Gorman wrote:
> 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?
IMHO that is there to handle call forking. But I think it's a good idea
for us to avoid forking -- look how messy SIP can be because of it.
> should the states of the call be in the signalling, ringing busy or
> not in service etc. Why are they shoved in xep-167?
I don't know that they're "shoved". :-) But really those events are
voice-specific, no? E.g., how does "ringing" apply to a whiteboarding
session? I suppose we could come up with more generic info messages, though.
> xep-167 (jingle-audio)
> When would a call be ringing vs queued?
Ask the SIP folks, we're trying to map to their semantics. They have 180
(Ringing) vs. 182 (Queued). In practice I don't think we would use
something like 182 because that means the message is being queued at the
server. So I suppose we can pull that out.
> 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
Agreed, we need to define that more fully. I'm no expert on early media,
so I need to read up on it some more. Suggestions are welcome. :-)
> busy should be in xep-166
See above on generic info messages.
> xep-180 (jingle-video)
> Shouldn't the codecs in the example be video codecs right?
> and rest obviously still needs to be fleshed out.
Yes, but it's not as high a priority right now. But there are people
starting to implement against it so their feedback will be valuable.
> 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.
The spec currently says:
The value of the 'code' attribute SHOULD be one the following
characters: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, #, and * -- however,
the characters A, B, C, and D MAY be sent as well.
> 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.
OK, I'll move that.
> 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
Yes, I'll fix that.
> xep-176 (jingle-ice)
> stun server advertised by server? Should your network's stun server be
> advertised via your xmpp server?
I've fleshed that out some more. There are multiple ways to discover
STUN servers, including DNS SRV records (probably should be preferred).
> in xep-176 it refers to termination of the call which is out of its
> scope i would think.
Yes, I've removed that.
> 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.
Feel free to write that up. :-)
> 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.
Agreed, I don't think we need that spec anymore. Any objections to
making it Deferred or Retracted? I'll ping the (other) author about that.
Jabber Software Foundation
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards