Hi Folks,
Is there any RFC that specifies the formats for Aggregation of
Notifications ? A server receives multiple notifications to be passed to
the receiver of the notifications. How should the server aggregate all
those notifications into one single outgoing SIP method ?
Regards
Abhishek
Hi Folks,
Is there any RFC that specifies the formats for Aggregation of
Notifications ? A server receives multiple notifications to be passed to
the receiver of the notifications. How should the server aggregate all
those notifications into one single outgoing SIP method ?
Regards
Abhishek
-Type: application/chat-info+xml
Content-Length: ...
:
Regards
Abhishek
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
me. It has been
awesome discussion with you.
Regards
Abhishek
On Sun, Apr 14, 2019 at 2:36 PM Paul Kyzivat wrote:
> On 4/13/19 9:31 PM, abhishek jain wrote:
> > Thanks Paul for your great suggestions. Since, I don't want to add
> > traffic to network, so I don't want
:; purpose=info
Content-Type: application/chat-info+xml
Content-Length: ...
content-ID:
:
Regards
Abhishek
On Sat, Apr 13, 2019 at 4:36 PM Paul Kyzivat wrote:
> On 4/13/19 4:43 PM, abhishek jain wrote:
> > Thanks Paul for your quick response on a Saturday. I really appreciate.
MESSAGE
2. Client may apply some of them, so client should respond back with the
config that have been applied.
Would you suggest to include a proprietary SIP header containing the
information to be conveyed to server ? What could be the max data a header
may contain ?
Regards
Abhishek
On Sat, Apr 13
gt;
>
>
> :
>
>
>
>
> *Client to Server:*
>
> SIP/2.0 200 OK
>
> :
>
> Content-Type: application/chat-info+xml
>
> Content-Length: ...
>
>
>
>
> :
>
>
>
> Regards
>
> Abhishek
>
your stack. It
looks to be messy state-machine-implementation.
Thanks
Abhishek
On Fri, Nov 30, 2018 at 8:15 AM Dale R. Worley wrote:
>
> Abhishek writes:
> > A --> Switch --> B
> > All 3 nodes connected with SIP connectivity.
>
> > A sending INVITE to B but
which switch sends to A. Then A sends 200OK which Switch does not
forward to A. B sends 200OK multiple times as per standard and Switch
disconnects session at both the ends with SIP cause code 500.
Seeking reason for such behaviour.
Best Regards,
Abhishek Phadke
+91 9819
Hello Paul,
Thank you very much for response.
We could see with some of the peer nodes that Call is continuing even if ACK
message does not carry SDP.
Best Regards,
Abhishek Phadke
> On 23-May-2018, at 22:38, Paul Kyzivat wrote:
>
> Abhishek,
>
>> On 5/23/18 7:15
;
>
> Would like to understand way forward for resolution of this issue.
>
Thank you in advance.
Best Regards,
Abhishek
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Hi,
I was trying to figure out the RFC where I can find the reference to create
the below "application/resource-lists". Although I looked into RFC 5366,
but I do NOT see that the RFC mentions anywhere about creating the "body"
(highlighted in yellow) in the . Please let me know what are its
implic
Thank you Paul for your quick response.
Appreciate it.
Regards
Abhishek
On Fri, Oct 6, 2017 at 3:18 PM, Paul Kyzivat wrote:
> On 10/6/17 1:04 PM, Abhishek Jain wrote:
>
>> Hi,
>>
>> 1. Under what senarios or conditions, Network would initiate
>> deregistratio
Hi,
1. Under what senarios or conditions, Network would initiate deregistration
to a UE ?
Regards
Abhishek
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Hi,
does anybody know what is sip version 3.C ?
Regards
Abhishek
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
hi Sourav,
As far i mine understanding , Refer with replaces is not a mandatory.
Regards
Abhishek
On Tue, Oct 28, 2014 at 5:25 PM, Vikas Dhiman
wrote:
> Hi Sourav,
>
> Are you talking about Replace-to or Refer-To?
>
> In Refer-To replaces is not a mandatory parameter.
>
Response didn't contain a SDP.
If above 2 conditions are met, in that case UAS
a. Stop re-transmitting 1xx ( which are not acknowledged)
b. Must wait for PRACK as associated with Non-INVITE-Transaction-Timer.
--
Thanks
Abh
of
>>>reliable provisional response/reliable response containing the answer.
So, in your case you should NOT send the UPDATE, until the previous answer has
been received in the reliable message.
Regards
Abhishek
--
Message: 4
Date: Thu, 27 Feb 2014 13:10:04 +0
10 seconds.
Though UAS has sent 183 with SDP, but since it was NOT reliable, this
was NOT the final response, even though you might be receiving the Allow
header listing UPDATE, in my views UAS is complying to RFC 3311 (5.2
Receiving an UPDATE).
Regards
Abhishek
Message: 4 Date: Wed, 26 Feb 2014 07:1
Does that mean we cannot send both the attributes in one-offer.
I think in such case end point should pick last a: line. My guess. Please
let me know with little explanation.
Thanks,
-Abhishek
On Wed, Mar 7, 2012 at 4:05 PM, Worley, Dale R (Dale) wrote:
> No: their meanings are incompati
Hi All,
Can we send both attributes (sendrecv & sendonly) in single Request.
a=rtpmap:0 PCMU/8000/1
a=rtpmap:8 PCMA/8000/1
*a=sendrecv*
a=ptime:20
*a=sendonly*
*
*
*
*
**
Regards,
-Abhishek
___
Sip-implementors mailing list
Sip-implemen
Hi All,
Can we send both attributes (sendrecv & sendonly) in single Request.
a=rtpmap:0 PCMU/8000/1
a=rtpmap:8 PCMA/8000/1
*a=sendrecv*
a=ptime:20
*a=sendonly*
*
*
*
*
**
Regards,
-Abhishek
___
Sip-implementors mailing list
Sip-implemen
).
Abhishek.
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Vineet
Menon
Sent: Tuesday, March 06, 2012 12:50 PM
To: Sip-implementors@lists.cs.columbia.edu; opalvoip-devel
Subject: [Sip-implementors
? In this case the dialog has not
been established yet.
INVITE with Route>
180 with Record Route <---
UPDATE>
Regards
Abhishe
It should be udp by default.
Regards
Abhishek
On Fri, May 20, 2011 at 2:08 PM, Gauri Kshirsagar wrote:
> Hi,
>
> This is a query regarding selection of transport while sending a
> SIP request. If the target uri is of the form
>
> sip:bob@198.152.136.165:5061 what transp
Thanks Frank,
But what is so special about the invite and re-invite. Why not any other
method in the protocol has this fecility?
Abhishek.
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Frank
Method inside a dialog, so if a 100
Trying is issued for say UPDATE then why it is not the same case as of the
Re-INVITE's arriving inside the same dialog.
Thanks
Abhishek.
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
Hi Gaurav
Please find below some 3GPP references for emergency call:-
3GPP TS 24.229
3GPP TS 23.167
3GPP TS 24.008
3GPP TS 22.101
Above, talks about IMS.
regards
Abhishek Dhammawat
Arcient
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors
sent - an ACK is only sent in response to a response to an INVITE request."
regards
Abhishek Dhammawat
Aricent
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Gellatly,
Anna
Sent: Tuesday,
Registration;
G. Parsons; Aug 2002
regards
Abhishek Dhammawat
Aricent
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Manoj
Priyankara [TG]
Sent: Friday, October 23, 2009 9:43 AM
To: Manoj Priyankara [TG
Registration; G. Parsons; Aug 2002
regards
Abhishek Dhammawat
Aricent
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Manoj
Priyankara [TG]
Sent: Friday, October 23, 2009 9:43 AM
To: Manoj Priyankara [TG
nt in response to a response to an INVITE request."
regards
Abhishek Dhammawat
Aricent
From: sip-implementors-boun...@lists.cs.columbia.edu
[sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Andrea
[fuffa...@gmail.com]
Sent: Friday, October 09,
bytes and the path MTU is unknown, the request MUST be sent using an RFC
2914 [36] congestion controlled transport protocol, such as TCP."
regards
Abhishek Dhammawat
Aricent
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-impleme
Hi raikme
As in the original mail RFC 2327 was referred so it should be checked whether
the SIP stack used in the below case is compliant with RFC 4566 or with RFC
2327.
regards
Abhishek Dhammawat
Aricent
From: Brett Tate [br...@broadsoft.com]
Sent
e just the country code.
So the SIP stack behavior seems to be valid by rejecting the "p=+x" format.
regards
Abhishek Dhammawat
Aricent
From: sip-implementors-boun...@lists.cs.columbia.edu
[sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of
. The use of transport=tls has consequently been deprecated,
partly because it was specific to a
single hop of the request. This is a change since RFC 2543."
Hope above paragraph answers your query.
regards
Abhishek Dhammawat
Aricent
-Original Message-
From: sip-impleme
;
regards
Abhishek Dhammawat
Aricent
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Szilagyi,
Mike
Sent: Thursday, August 27, 2009 8:36 PM
To: Neel Balasubramanian; dispa...@ietf.org; sipc...@ietf
tion therefore usage of "Reason" header
is not required in 200 OK.
Few more use cases can be found in RFC 4411.
regards
Abhishek Dhammawat
Aricent
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] O
as we have got the subscription duration from
200-class response the subscription refresh should be done at any time before
subscription expires.
Please refer section 3.1.4.2 of RFC 3265 for details on "refreshing of
subscriptions"
regards
Abhishek Dhammawat
Aricent
quoted-string )
diversion-extension = token ["=" (token | quoted-string)]
Syntactically both of the below seems to be correct, and when receiving the SIP
message containing the header both formats should be supported.
However when sending the header would suggest to put reason=unco
ns in subsequent
responses to the initial INVITE."
The assumption above is that same UAS has sent the 183 and 180 responses.
regards
Abhishek Dhammawat
Aricent
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu]
mentioned in section 3.5 of below
draft which can be used. For TCP (ping-pong mechanism) and for UDP keep alive
with STUN.
Path - http://tools.ietf.org/html/draft-ietf-sip-outbound-20
Two answer your second question it is not necessary to send OPTIONS from a
registered user.
regards
Abhishek Dhammawat
Hi
In my opinion RBT(Ring Back Tone) should be played.
regards
Abhishek Dhammawat
From: Miguel Oreilly [mailto:miguel.orei...@gmail.com]
Sent: Thursday, August 06, 2009 5:20 PM
To: Abhishek Dhammawat
Cc: Iñaki Baz Castillo; sip-implementors@lists.cs.columbia.edu
in advance,
Miguel"
The above question does not specify that 183 and 180 are received from single
UAS or different. The answer mentioned in my response was considering the
scenario when same UAS has sent 183 with SDP followed by 180 without SDP.
regards
Abhishek Dhammawat
-Original M
Hi
The below is valid scenario.
Also RFC 3261 section 13.2.1 mentions
"The UAC MUST treat the first session description it receives as the answer,
and MUST ignore any session descriptions in subsequent responses to the initial
INVITE."
regards
Abhishek Dhammawat
Aricent
-Origin
to a compatible cluster.
apsessionid - Used with the SipApplicationSession.encodeURI method to store the
session ID.
Reference - Table 1-4
http://download.oracle.com/docs/cd/E13153_01/wlcp/wlss40/notes/new.html#whatsnew
regards
Abhishek Dhammawat
Aricent
-Original Message-
From: sip-implemen
l IP address and port are mapped to the same external IP address
and port. Unlike a full cone NAT, an external host (with IP address X) can send
a packet to the internal host only if the internal host had previously sent a
packet to IP address X.
regards
Abhishek Dhammawat
Technical Leader
Extn
Internet in
order to accept requests from worldwide IP endpoints. SIP creates a
number of potential opportunities for distributed denial-of-service
attacks that must be recognized and addressed by the implementers and
operators of SIP systems.
Regards
Abhishek
On Tue, Jul 14, 2009 at 11:02 PM, Brett
Hi
In my opinion 100rel extension should be ignored when received in an INFO
request.
The rational behind this is 100rel extension is required for the reliable
provisional responses for the dialog
creating SIP requests, for INVITE method it is described in RFC 3262.
regards
Abhishek Dhammawat
; / "_" / "." / "!" / "˜" / "*" /
"’" / "(" / ")"
pct-encoded = "%" HEXDIG HEXDIG
param-unreserved = "[" / "]" / "/" / ":" / "&" / "+&qu
Hi
As the quotes are mandatory for the uri parameter of Authorization header
the appropriate response for the below message shall be 400
with reason phrase as "Missing quotes in uri parameter of Authorization Header".
Please refer section 21.4.1 of RFC 3261.
regards
Abhish
hi,
REFER sip:D
Refer-To: sip:A?Replaces=callid;to-tag=b;from-tag=a.
(don't mind the unencoded ; and =)
thanks
Abhishek
On 3/5/09, Klaus Darilion wrote:
>
> Hi!
>
> I try to understand how to format the Refer-To header. Consider the
> following scenario: (lt
moved."
regards
Abhishek Dhammawat
Aricent
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of cool goose
Sent: Monday, February 23, 2009 11:00 PM
To: sip-implementors@lists.cs.columbia.edu
Sub
. For this reason it can perform number of
functions that are not possible to implement using SIP proxy, such as for
example accurate call accounting, pre-paid rating and billing, fail over call
routing etc.
regards
Abhishek Dhammawat
Aricent
-Original Message-
From: sip-implementors
Abhishek Dhammawat would like to recall the message, "[Sip-implementors] B2BUA
vs Proxy with Record Route".
"DISCLAIMER: This message is proprietary to Aricent and is intended solely for
the use of the individual to whom it is addressed. It may contain privileged or
confident
. For this reason it can perform number of
functions that are not possible to implement using SIP proxy, such as for
example accurate call accounting, pre-paid rating and billing, fail over call
routing etc.
regards
Abhishek Dhammawat
Technical Leader
Extn 5123
-Original Message-
From
significant spaces may
disappear and insignificant spaces may be introduced when URI are
transcribed or typeset or subjected to the treatment of wordprocessing
programs. Whitespace is also used to delimit URI in many
contexts.
space =
regards
Abhishek Dhammawat
Aricent
then it may initiate its own hold by sending a new
offer containing "a=sendonly" to UA1. Upon receipt of that, UA1
will answer with "a=inactive" because that is the only valid answer
that reflects its desire not to receive media.
regards
Abhishek Dhammawat
Aricent
hi,
if the 200 ok without SDP is send for any reasons than it totally depends
upon the code implementation of the B2BUA , what message it expects to
receive. It could be bye or some 4xx response too.
Regards
Abhishek
2008/11/20 Anuradha Gupta <[EMAIL PROTECTED]>
> Without an answer
no, SDP isn't valid in that context
regards
abhishek
2008/11/14 Paul Kyzivat <[EMAIL PROTECTED]>
>
>
> Alejandro Orellana wrote:
> > All,
> > in the following call flow,
> > is it valid for endpoint A to send a ACK with SDP?
> >
> > e
i did nt get u u , what exactly u r looking for.abhishek
2008/10/20 Hilario D'souza <[EMAIL PROTECTED]>
> I am looking for a service or a provider which can redirect my SIP calls to
> a PSTN phone. I am based in the US. (I would prefer the service to be
> online versus a software)
>
> Any help
yes there is difference in both
2008/10/19 Manoj Priyankara (NOD) <[EMAIL PROTECTED]>
> Hi All,
>
> Is there any difference in the signaling flows of SIP attendant call
> transfer and blind call transfer ?
>
> //Manoj
> ___
> Sip-implementors mailing li
hi,
after getting the refer, the uac should generate an invite to the refer
to party which is not happening in your case.
can u explain the scenario in detail.
regards
abhishek
2008/10/18 <[EMAIL PROTECTED]>
> From: Mohamed Shifan <[EMAIL PROTECTED]>
>
> The prob
hi, i think RFC 4235 do provide the information about sip forking.
regards
Abhishek
2008/10/10 Sarvpriya Gupta <[EMAIL PROTECTED]>
> Hi,
>
>
>
> Can you please suggest a draft or RFC which says how to maintain
> multiple dialogs created with an INVITE in case of forkin
yes i think u r rite.abhishek
2008/10/8 Iñaki Baz Castillo <[EMAIL PROTECTED]>
> 2008/10/8 Manoj Priyankara (NOD) <[EMAIL PROTECTED]>:
> > Dear All,
> >
> > If any one can explain me how blind transfer works when the originating
> > party is not from the Soft Switch from where the call is being
after a particular time for a request , if u r not getting any response,
server will send 504.abhishek
2008/10/3 Manoj Priyankara (NOD) <[EMAIL PROTECTED]>
>
>
> Hi All,
>
> Does anyone can tell me the reason for the error message 504 - server time
&
without SDP ), C could offer g711, but B may not
> answer with g711 as it supports g729
>
> --
> *From:* ABHISHEK GUPTA [mailto:[EMAIL PROTECTED]
> *Sent:* Friday, October 03, 2008 11:51 AM
> *To:* Sarkar, Uttam
> *Cc:* sip-implementors@lists.cs.c
ailto:[EMAIL PROTECTED] On Behalf Of
> ABHISHEK GUPTA
> Sent: Friday, October 03, 2008 4:33 AM
> To: sip-implementors@lists.cs.columbia.edu
> Subject: [Sip-implementors] help
>
> hi, in a call scenario where B2BUA is involved, A call B.
>
>
>
>
> A(codec g71
hi, in a call scenario where B2BUA is involved, A call B.
A(codec g711)-invite-B2BUAinvite-B(codec g729)
A-->Refer(to c)
-B2BUA --invite>C(codec
g711)
-B2BUA---
once.
The second line states that if the 'isdnsubaddress' or 'extension' is
present it must occur
first.
Doesn't it also mean that only one of 'isdnsubaddress' or 'extension' may be
present in a Tel URI.
Because if
70 matches
Mail list logo
