Hi All,
Can anyone guide from where to get the End-point Interop Test cases for
Ring Central's Cloud based Telephony system.
Thanks,
Arun
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/
Hi All,
I am curious, if a secure session (SIPS) establishment starts and there
are two proxies b/w UAC and UAS path which done support SIPS, what will
happen to session establishment?
Will the communication downgrade to SIP (non-secure) or the session
establishment will terminate?
Than
forked leg.
Rama, does this answer your question?
Thanks,
Arun.
On Wed, 30 Mar 2016 19:58:42 +0530, Olle E. Johansson
wrote:
On 30 Mar 2016, at 16:08, Paul Kyzivat wrote:
On 3/30/16 2:58 AM, Arun Arora wrote:
On Sun, 20 Mar 2016 23:32:44 +0530, Paul Kyzivat
wrote:
On 3/20/1
On Sun, 20 Mar 2016 23:32:44 +0530, Paul Kyzivat
wrote:
On 3/20/16 12:26 PM, Neelakantan, Neel wrote:
Please review RFC 3261. This is addressed in it.
The provisional response must be forwarded by proxy to the UAC.
The answer ( 200 OK) can be from any of the UAS and there is no way of
P
On 13/11/15, 9:04 PM, "Dale R. Worley" wrote:
>Arun Arora writes:
>> Is their any specific length of To/ From header defined by the
>> standard (I guess not, but still would like to know other's views)
>
>As far as I can tell, your question is, "Is
Hi Paul,
It sounds interesting :)
Can you give an example…? I didn’t exactly catch the reference of the range as
API arg.
Thanks,
Arun
On 13/11/15, 8:25 PM, "Paul Kyzivat"
wrote:
>On 11/13/15 6:58 AM, Arun Arora wrote:
>> Hi all,
>>
>> Is their any spe
...@lists.cs.columbia.edu
>[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Arun Arora
>Sent: November-13-15 7:35 AM
>To: Brett Tate ; sip-implementors@lists.cs.columbia.edu
>Subject: Re: [Sip-implementors] Max length of To/ From headers
>
>Hmm.. That’s true, ‘No
Hmm.. That’s true, ‘No max should be there’ to support inter-op.
However, for API design, I guess their is no way other than asking API-User to
Provide the length of Strings for To and From.
I am designing the API to receive the To/ From header in form or 'name-addr' or
'addr-spec' in order to
Hi all,
Is their any specific length of To/ From header defined by the standard (I
guess not, but still would like to know other’s views)
In case no specific length is defined, is their any common-practice for max
length?
The question is related to the SIP session start API I am working on for
ceive such a thing.
>
> SIP-URL = "sip:" [ userinfo "@" ] hostport
>url-parameters [ headers ]
>
>
>
>> -Original Message-
>> From: Arun Arora [mailto:arun.arora@gmail.com]
>> Sent: Tuesday, November 10, 2015 6:1
colon
>
>
>
>> -Original Message-
>> From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-
>> implementors-boun...@lists.cs.columbia.edu] On Behalf Of Arun Arora
>> Sent: Tuesday, November 10, 2015 5:52 AM
>> To: sip-implementors@lists.cs.columb
I am working on a SIP parser while reading RFC3261. I wonder is it OK to put
WHITESPACE between SIP and COLON in a SIP URI, for e.g.
“BOB"
Is this syntactically correct.
Thanks,
Arun
___
Sip-implementors mailing list
Sip-implementors@lists.cs.colum
Tate" wrote:
> See RFC 3261 section 9.2.
>
> ** **
>
> ** **
>
> *From:* Arun Arora [mailto:arun.arora@gmail.com]
> *Sent:* Tuesday, September 17, 2013 7:51 AM
> *To:* Brett Tate
> *Cc:* sip-implementors
> *Subject:* RE: [Sip-implementors] About
So what I understand is if there is a use-case where CANCEL can be sent for
other than non-INVITE method, that case should be clearly outlined... may
be a sip extension rfc which specifically standardizes such scenario.
Otherwise if not explicitely mentioned CANCEL should be ignored in case of
non-
Hi all,
Is it possible to send a CANCEL request for non-INVITE requests as well? In
section 9 its written CANCEL is best suited for INVITE. However the
standard does not restrict CANCEL only for INVITE. Moreover, In 9.1 its
written cancel SHOULD NOT be sent for requests other than INVITE. But to
m
No, it can't be done this way. By adding a=sendrerv we are clearly
distinguishing b/w RFC 2543 and RFC 3261. So, For an "a=sendrecv" there
has to be an "a" attribute in the answer.
Arun
--- On Fri, 4/7/08, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
From: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Su
16 matches
Mail list logo
