[Standards-JIG] Jingle xeps

Jean-Louis Seguineau jean-louis.seguineau at laposte.net
Tue Oct 31 21:20:33 UTC 2006


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

In my opinion the SIP 182 refers to cases where a UA is queuing incoming
calls without issuing a busy indication. For the other party is only
indicates there is a possibility for the call to be accepted...

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

I was under the impression a previous post to the list defined XEP-0177 as
being RTP over UDP. In this case what would be raw RTP?

-----Original Message-----
Date: Tue, 31 Oct 2006 13:04:09 -0700
From: Peter Saint-Andre <stpeter at jabber.org>
Subject: Re: [Standards-JIG] Jingle xeps
To: Jabber protocol discussion list <standards-jig at jabber.org>
Message-ID: <4547AC39.8050304 at jabber.org>
Content-Type: text/plain; charset="iso-8859-1"

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






More information about the Standards mailing list