> > > I've tested it with my SIP parser which is 100% strict
> > > according to RFC 3261 grammar and RFC 3966 (TEL). Such
> > > SIP URI is valid according to BNF.
> >
> > Does your parser allow invalid characters within the
> > local-number-digits or does it not allow
> > "anonymous;phone-context
El Miércoles, 13 de Enero de 2010, Paul Kyzivat escribió:
> This says that if the user field contains an e164 telephone-subscriber
> than user=phone SHOULD be present. It doesn't state the converse: that
> if the user part *doesn't* contain a telephone-subscriber then there
> should not be a use
El Miércoles, 13 de Enero de 2010, Neel Neelakantan escribió:
> True, for example a TEL URI allows "#" symbol while it's not allowed in a
> SIP URI userinfo part.
>
>
> [Neel]
> The # should be escaped in the userinfo part.
The following SIP URI can be "converted" into a TEL URI:
sip:%2312
I'm going to get a bit nit-picky here. The text from 3261 says:
The set of valid telephone-subscriber strings is a subset of
valid user strings. The user URI parameter exists to
distinguish telephone numbers from user names that happen to
look like telephon
See below.
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Iñaki Baz
Castillo
Sent: Wednesday, January 13, 2010 2:54 PM
To: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors]
On Wed, Jan 13, 2010 at 3:17 PM, Neel Neelakantan
wrote:
> See below.
>
> -Original Message-
> From: sip-implementors-boun...@lists.cs.columbia.edu
> [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of M.
> Ranganathan
> Sent: Wednesday, January 13, 2010 1:37 PM
> To: si
El Miércoles, 13 de Enero de 2010, Brett Tate escribió:
> > > In case it matters, "anonymous" does violate the character
> > > set for the digits portion of telephone-subscriber. Thus
> > > although maybe not desirable, a strict parser may reject
> > > the INVITE with a 400 response.
> >
> > It's
See below.
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of M.
Ranganathan
Sent: Wednesday, January 13, 2010 1:37 PM
To: sip-implementors
Subject: [Sip-implementors] What do you do with a REFER th
I am talking to an automaton which transfers a call as soon as it
sends an ACK for the call. Problem is the REFER may arrive before the
ACK does. What should be done with the REFER :
1. Drop silently.
2. Send error ( 5xx with retry-after ? )
3. Accept the REFER and hope the ACK shows up soon ( an
> > In case it matters, "anonymous" does violate the character
> > set for the digits portion of telephone-subscriber. Thus
> > although maybe not desirable, a strict parser may reject
> > the INVITE with a 400 response.
>
> It's just a semantic subject. No strict SIP parser should
> reject s
El Miércoles, 13 de Enero de 2010, Brett Tate escribió:
> > > Of course, "anonymous" is not a valid TEL number so the above
> > > SIP URI (which comes from a TEL URI due to the presence of
> > > "user=phone") makes no sense (IMHO).
> >
> > It makes no sense. But the decision that it makes no sense
> > Of course, "anonymous" is not a valid TEL number so the above
> > SIP URI (which comes from a TEL URI due to the presence of
> > "user=phone") makes no sense (IMHO).
>
> It makes no sense. But the decision that it makes no sense is up
> to a server for the domain of the URI.
In case it mat
Iñaki Baz Castillo wrote:
> El Miércoles, 13 de Enero de 2010, ROHIT CHAUDHARY escribió:
>> Hi experts,
>>
>> A sip-uri with user part as "anonymous" is allowed. But if the user
>> parameter is phone, ie, the user part is to be treated as
>> telephone-subscriber of tel-url (RFC 3966), then shou
El Miércoles, 13 de Enero de 2010, Pandurangan R S escribió:
> > A UA cannot send a BYE for a call until it has received an ACK for
> > the initial INVITE. This was allowed in RFC 2543 but leads to a
> > potential race condition.
>
> Probably that should read
>
> A UA cannot send a BYE
Thanks.
Regards,
Sunil
-Original Message-
From: Pandurangan R S [mailto:pandurangan@gmail.com]
Sent: Wednesday, January 13, 2010 4:30 PM
To: Sunil Bhagat (WT01 - Telecom Equipment)
Cc: i...@aliax.net; sip-implementors@lists.cs.columbia.edu;
rohit.aggar...@aricent.com; vivek.tal...@r
> A UA cannot send a BYE for a call until it has received an ACK for
> the initial INVITE. This was allowed in RFC 2543 but leads to a
> potential race condition.
Probably that should read
A UA cannot send a BYE for a call until it has received an ACK for
the initial INVITE or *server
Thanks for the reply.
But the in the RFC (28.1 Major Functional Changes) it is mentioned that:
A UA cannot send a BYE for a call until it has received an ACK for
the initial INVITE. This was allowed in RFC 2543 but leads to a
potential race condition.
Please let me know the correct
El Miércoles, 13 de Enero de 2010, sunil.bha...@wipro.com escribió:
> Hi,
>
> I have one doubt in this.
> If ACK is not properly sent by the UAC, how will the call be terminated?
> Will the UAC send a CANCEL
How can now the UAC that its ACK didn't arrive to the UAS? just by inspecting
the arri
UAS shall send a BYE on 200 OK retransmission timeout. This way, call will be
cleared at both the sides.
Regards
Rohit Aggarwal
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of
sunil.bha...@wip
BYE will be sent by UAS if correct ACK is not received before time out.
Regards,
Vivek
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of
sunil.bha...@wipro.com
Sent: Wednesday, January 13, 2010 3:3
Hi,
I have one doubt in this.
If ACK is not properly sent by the UAC, how will the call be terminated?
Will the UAC send a CANCEL or will the other end send a BYE to terminate the
call?
Regards,
Sunil
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-
El Miércoles, 13 de Enero de 2010, ROHIT CHAUDHARY escribió:
> Hi experts,
>
> A sip-uri with user part as "anonymous" is allowed. But if the user
> parameter is phone, ie, the user part is to be treated as
> telephone-subscriber of tel-url (RFC 3966), then should it be allowed,
> something lik
22 matches
Mail list logo
