[Standards-JIG] Jingle - Mapping to user behaviour

Joe Beda jbeda at google.com
Thu Dec 15 15:20:54 UTC 2005

This is a good point Vinod and I think I touched on it in the last message
before I read this :)

The media/p2p channels have STUN packets intermixed with RTP/UDP.  This
means that each side has a good idea of connectivity.  Technically there is
no reason to put anything in the signalling channel to indicate that
connectivity has been achieved.  The lower level implementation should be
able to tell you this info.  We've talked of changing the spec to include
some indication of which candidate is being used anyway for logging/auditing

On top of this, for Jingle-audio, we are going to suggest/require that no
ringing be done before good media connectivity is established and hence an
Accept shouldn't come before that.

Right now the Talk client starts ringing immediatly when a session is
created.  Most calls establish media connectivity (perhaps through our
relay) before the call is picked up.  However, fixing this issue is
important not only for edge cases but for those situations/services where
there is no relay and connectivity *cannot* be established.


On 12/15/05, Vinod Panicker <vinod.p at gmail.com> wrote:
> Hi,
> In the Jingle spec, the Acceptance and the Decline is basically for
> the suitability of the media transfer channel.  In reality, the
> contact might have accepted the incoming call request even before the
> media channel is ready, or vice-versa.
> How is Jingle mapping the behaviour of the contact (Accept/Decline) in
> the protocol spec?
> Shouldn't there be separate commands for "establishing that the media
> transfer channel is ready/not available" and "contact accepts/rejects
> the incoming call request" ?
> Regards,
> Vinod.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20051215/c2c1784f/attachment.html>

More information about the Standards mailing list