On Tue, Dec 18, 2012 at 4:24 PM, Paul Kyzivat wrote:
> I don't think so. But maybe others will find a justification for doing so.
I don't think it is valid - although it's totally underspecified.
user=phone implies the user portion is a tel URI, and
tel:anonymous.invalid;phone-context=+1 isn't l
On Fri, Dec 21, 2012 at 7:33 PM, Vivek Singla wrote:
>
> I have a scenario where the Invite has the REcord-route , but the BYE to end
> this session, doesnt have a RR header.
>
> Is that ok?
>
> Our server is rejecting this BYE. I was wondering may be that could be the
> issue.
It is fine for a
On Thu, Mar 12, 2009 at 10:45 PM, Iñaki Baz Castillo wrote:
> PD: This is too much complex, really a pain. I suspect it is really unusable
> and nobody will implement it "properly".
Welcome to SIP. Enjoy your stay!
:)
~ Theo
___
Sip-implementors m
On Thu, Mar 12, 2009 at 10:47 PM, Iñaki Baz Castillo wrote:
> Thanks, where are these "rn" and "npdi" documented?
The same place as any parameters, in the IANA registry:
http://www.iana.org/assignments/tel-uri-parameters/tel-uri-parameters.xhtml
~ Theo
_
On Fri, Feb 27, 2009 at 9:50 AM, Iñaki Baz Castillo wrote:
> - In case the SIP URI explicitely defines a port then only those SRV
> records using that port must be selectable.
Wrong! If there is a port, you don't do an SRV lookup.
> - In case ";transport=XXX" parameter appears in the SIP URI on
Hi Ben,
On Fri, Feb 27, 2009 at 8:51 AM, BONNAERENS Ben
wrote:
>> On the same note, it's shocking how many devices bail out
>> after receiving a 503 and just give up. Please,
>> implementers: 503 does not mean "never try registering again".
>
> Let me refine this statement a bit:
> 503 also do
s be implemented at all? When?
Yes, they will at some point. Although the problem in RAI is that no
one seems to have any time to actually do stuff. So anyone who feels
strongly should get involved!
Out of interest - how many people on sip-implementors@ that are
actually maintaining SIP implementa
On Thu, Feb 26, 2009 at 3:26 PM, Iñaki Baz Castillo wrote:
> RFC 3263 (Locating SIP Servers) is really complex, NAPTR is really
> complex, and it's not needed in 99% of current SIP deployments, so
> vendors don't implement it. If a SIP provider whises to use NAPTR
> records then all its clients s
ers: 503 does not
mean "never try registering again".
>> Proper DNS support should be enforced somehow (who knows how?!?) before
>> anything else. At the end, DNS drives the IP world.
>
> IMHO RFC 3263 complexity doesn't help too much.
I don't see any real complex
On Thu, Feb 26, 2009 at 10:12 AM, Johansson Olle E wrote:
> Well, I have some architecture issues on what to do with the context
> in regards to Asterisk. We can map it directly to the dialplan, which is
> an interesting feature. Propably the easiest path to take.
bear in mind that a phone-contex
On Thu, Feb 26, 2009 at 9:38 AM, Johansson Olle E wrote:
> TO be picky - you say only host. Does this also imply that the domain
> part is indeed a host and should not be looked up for NAPTR/SRV records?
>
>>
>>
>>> And user=
>>
>> RFC4967 is the other defined one.
>
> Thanks. user=dialstring
> An
On Thu, Feb 26, 2009 at 8:48 AM, Johansson Olle E wrote:
> So looking at the BNF, it's
> user-param = "user=" ( "phone" / "ip" / other-user)
>
> What is user=ip ?
This is the default when there is no "user" parameter in the URI, and
it, means that the user part or the URI is an identifier at the
On Thu, Feb 26, 2009 at 8:32 AM, Johansson Olle E wrote:
> I've seen that - but that's not a reference to a Tel: uri.
Yes, it is - telephone-subscriber is straight out of rfc2806.
> In my opinion, this is
> very vague and implementations differ a lot. I've seen implementations
> that require on
On Thu, Feb 26, 2009 at 7:29 AM, Johansson Olle E wrote:
>> IMO, "user=phone" shows user part, @, indicate TEL-URL.
>
> Where is this documented?
rfc3261, 19.1.1:
The set of valid telephone-subscriber strings is a subset of
valid user strings. The user URI parameter exist
On Tue, Feb 10, 2009 at 8:07 PM, Iñaki Baz Castillo wrote:
> Well, the first example is invalid since according to BNF grammar:
>
> display-name = *(token LWS)/ quoted-string
>
> This is: the display name (The Operator) is incorrect since it's not a token
> (it contains a space) and it's not
On Mon, Feb 9, 2009 at 9:51 PM, Iñaki Baz Castillo wrote:
> It says that the request URI has invalid header parameters:
>
table 1 states that headers are not allowed in the R-URI:
dialog
reg./redir. C
On Thu, Jan 29, 2009 at 3:36 PM, Scott Lawrence
wrote:
> Why would I want the
> reliability of my inbound calls to be controlled by my system having to
> 'poll' (that's effectively what a registration is) rather than the
> provider just knowing where to send it?
NAT
~ Theo
nd it's still in draft, so caveat emptor.
~ Theo
1 - http://wiki.voip.co.uk/sip/matching_using_to_header
--
Theo Zourzouvillys
Chief Technical Officer
VoIP.co.uk - Commerce House, Telford Road, Bicester, OX26 4LD
Tel: +44 1908 764 196
___
S
to the
INVITE containing it.
~ Theo
--
Theo Zourzouvillys
Chief Technical Officer
VoIP.co.uk - Commerce House, Telford Road, Bicester, OX26 4LD
Tel: +44 1908 764 196
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.c
rent SDP in an unreliable provisional followed by a
200; instead, the unreliable provisional contains a _preview_ of what
is to come in the 200.
> But could I know in which section of RFC 3261 (or other) is it specified? I
> don't remember it now...
read draft-ietf-sipping-sip-offeranswer.
On Thu, Jul 31, 2008 at 1:52 PM, Eric Tamme <[EMAIL PROTECTED]> wrote:
> 1) Is it correct for the softswitch to translate the dialed number in
> the INVITE but not in the To: ? (This is not a redirect server, its just
> a switch)
That is correct. The To header is populated by the UAC, and
repres
one doesn't already exist)
> => all 1xx responses must contain a contact header?
>
> Yet table 2 states its presence is optional. I must be missing
> something.
Stephen,
It's not necessary for a 100, nor to a 1xx response to a reINVITE, so
it is really optional i
doesn't already have one.
Kind regards,
~ Theo
--
Theo Zourzouvillys
Chief Technical Officer
VoIP.co.uk
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
he
UAS would like to be contacted for subsequent requests in the dialog
(which includes the ACK for a 2xx response in the case of an INVITE).
So from this you can see a 1xx response to an INVITE send by a 3261 UA
needs to insert a Contact header.
Kind regards,
~ Theo
--
Theo Zourzouvillys
ovisional response
sent by User2 which will route directly to User2 without forking to
User3 or anyone else, so you should never see this happen.
Kind regards,
~ Theo
--
Theo Zourzouvillys
Chief Technical Officer
VoIP.co.uk
___
Sip-implementors mai
On Tue, Jun 24, 2008 at 11:33 PM, Iñaki Baz Castillo <[EMAIL PROTECTED]> wrote:
> a server or proxy MUST NOT add "received" parameter
> to "Via" if the real source IP is identical to the value of "sent-by":
>From where did you get the MUST NOT in the above statement?
~ Theo
___
On Jan 25, 2008 11:45 AM, Andrews Sam Titus <[EMAIL PROTECTED]> wrote:
>
> Thanks Theo for the quick response.
> Is there any other way apart from NOTIFY as mentioned in rfc3680 ?
Nothing afaik.
~ Theo
___
Sip-implementors mailing list
Sip-implemento
On Jan 25, 2008 11:23 AM, Andrews Sam Titus <[EMAIL PROTECTED]> wrote:
> How can a SIP server inform the endpoint that its registration has been
> removed/unregistered from the SIP server ?
Andrew,
You can use the SIP registration event package -- rfc3680
Although endpoint support is almost non
On Jan 23, 2008 6:53 AM, Karthikeyan Gopal , TLS-Chennai
<[EMAIL PROTECTED]> wrote:
>
> But as per RFC 3261 401 is to send Unauthorized response.
Sect 7.2, Responses (Page 28):
[snip]
The Status-Code is a 3-digit integer result code that indicates the
outcome of an attempt to understand an
On Jan 23, 2008 6:35 AM, Karthikeyan Gopal , TLS-Chennai
<[EMAIL PROTECTED]> wrote:
>
> Can we add Reason Header to mention 'Password Expired' message
> in 401 response?
this would be completely nonsensical - you would just send "SIP/2.0
401 Password Expired" in your response (or the equi
On Jan 15, 2008 8:20 PM, Scott Lawrence <[EMAIL PROTECTED]> wrote:
> The semantics of 'missed' are very context dependent. A simple
> definition is 'no one answered the call', but in many systems that's not
> likely. More likely is that it rolled over to voicemail, or to some
> other user. If I'
On Jan 15, 2008 6:11 PM, Scott Lawrence <[EMAIL PROTECTED]> wrote:
> Why both instead of just using one or the other?
Actually, we've recently been seeing this a fair bit with "number
unavailable" on mobiles here. One paticular mobile carrier has
recently got in to the habit of sending ringing i
On Jan 14, 2008 10:09 AM, Iñaki Baz Castillo <[EMAIL PROTECTED]> wrote:
> Hi, I've looking but found nothing. Is there any RFC o Draft about UAC's
> retrieving missed calls from server?
>
> For now, each UAC stores info about generated and received calls, but due to
> parallel scenarios or PBX log
On Jan 14, 2008 10:03 PM, Amit P. Ahuja <[EMAIL PROTECTED]> wrote:
> Could someone please point me to the RFC that describes the use of the
> rinstance parameter in the Contact header of the REGISTER method?
rinstance isn't defined in any RFC, it's simply an opaque URI
parameter used by a nu
34 matches
Mail list logo
