On 4/29/14 10:42 AM, ankur bansal wrote:
sip.automata and automata represents same thing i guess
That is arguable. The situation is somewhat complex.
At the time RFC3840 was being written somebody saw a similarity between
the tags being defined for it and feature tags that had been previously
defined for unrelated purposes. And also that the definition of feature
tags had defined matching rules. So it was decided to reuse the existing
definitions and mechanisms for feature tags. (In retrospect I think this
was an error, but nevertheless that is what was done.)
The callerprefs mechanism (RFC3841) that operates in proxies is generic
- it operates the same for all feature tags, and it is important that
proxies be able to do it even for features unknown to them. As a result,
it must be possible for a proxy to distinguish header field parameters
that are feature tags (caller prefs or callee capabilities), from
parameters that serve some other purpose. For that reason the "+" prefix
was introduced to identify parameters that are being used as feature tags.
BUT, drafts of callerprefs had been in progress for years, and there was
a desire to preserve some backward compatibility for those who had
implemented to those drafts. (In retrospect this was probably also a
mistake.) So the set of sip feature tags that had been in the draft were
designated "base tags". These are *special*, and are grandfathered. They
are to be used without the leading "+sip." even though they are defined
in the "sip tree" of feature tags. The text also *allows* the base tags
to be used with a "+sip." or even "sip." prefix.
Any other feature tags that are used MUST use the "+" prefix and the
full name of the tag including the prefix for the tree it falls within.
Either its set as sip.automata=true/false OR automata(true by default)
The following would all be ok:
automata
automata=true
automata=false
+sip.automata
+sip.automata=true
+sip.automata=false
sip.automata
sip.automata=true
sip.automata=false
Thanks,
Paul
Feature parameter(not feature tag) can be added to Contact header by
UA(mostly some answering machine/voicemail server/IVR/announcement
server ) with value true or false
True : Call handled by answering
machine/voicemail server/IVR/announcement server
False : Call handled by human.
Mostly its seen when some server sends INVITE and add in Contact header .
Also this can be used in Register Contact header like sip.automata=false
to refuse to communicate with automation server .
Thanks & regards
Ankur Bansal
On Tue, Apr 29, 2014 at 8:05 PM, SIP Learner <rfc3...@foxmail.com
<mailto:rfc3...@foxmail.com>> wrote:
Thanks Paul!
At first I thought automaton as a typo too, but I found out that the
most recent RFC7088 also use automaton instead of automata, that's
why I asked the question.
------------------ Original ------------------
From: "Paul Kyzivat";<pkyzi...@alum.mit.edu
<mailto:pkyzi...@alum.mit.edu>>;
Date: Tue, Apr 29, 2014 08:35 PM
To: "sip-implementors"<sip-implementors@lists.cs.columbia.edu
<mailto:sip-implementors@lists.cs.columbia.edu>>;
Subject: Re: [Sip-implementors] A question about the automaton
feature tag
I presume "automaton" is simply an error - a misspelling.
You can look in the iana registry for all the defined feature tags.
On 4/29/14 3:27 AM, SIP Learner wrote:
> Hi, guys!
>
>
> I am reading RFC5359 for SIP services examples, some of the
message examples contain a Contact header parameter like the following:
>
>
> Contact: <sips:mu...@server.example.com
<mailto:sips%3amu...@server.example.com>>;automaton
> ;+sip.byeless;+sip.rendering="no"
>
>
>
> FRC5359 states that the automaton feature tag is defined in
RFC3840, but RFC3840 actually defined sip.automata instead of automaon.
>
>
> What is the difference between automaton and sip.automata anyway?
Are they equivalent or are they different?
>
>
> Thanks a lot!
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
<mailto:Sip-implementors@lists.cs.columbia.edu>
> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
<mailto:Sip-implementors@lists.cs.columbia.edu>
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
.
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
<mailto:Sip-implementors@lists.cs.columbia.edu>
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
