[Standards-JIG] Jingle xeps

[Peter Saint-Andre]

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

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?

Er, yes.

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

Fixed.

> shouldn't rfc2833 ability be visible via discovery along with the
> preferred xmpp dtmf signalling?

Added.

> 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
> transport?

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.

Peter

-- 
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.shtml

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20061031/5a7b6950/smime.bin