Hi Isshed,
The Update/Re-INIVTE will come after 30 seconds of message 3. The
INFO can be out of dialog as well.
Thanks and Regards,
Vivek
On Fri, Mar 27, 2015 at 4:01 PM, isshed wrote:
> Hi All,
>
> I have a scenario where my phone has negotiated with server as 60
> seconds expires
work in some
cases as B knows where to send media packets.
Thanks and Regards,
Vivek Talwar
On Wed, Oct 15, 2014 at 8:21 PM, Mustafa AYDIN
wrote:
> Phil,
>
> I agree the messaging after 200 ok is incorrect but the main question is
> with the CRBT which is sent before 200 ok. Why do
either treat this as NAT case and send responses to actual layer 3 IP or
can use approach suggested by Varun.
What you will do suppose if DNS query failed? Will not reply at all and
let endpoint keeps retransmitting the INVITE or will send responses to
layer 3 IP?
Thanks and Regards,
Vivek Talwar
Hi,
I think since address B is different from address A, client should
treat this as some NAT is in place should send responses back to address A
which is actual source IP received in Packet. Here, client can also treat
that Layer 3 ip and layer 2 ip are different and thus same logic of NAT
sh
Hi Chaim,
In this case, Server should handle same REGISTER as this REGISTER
will be received on same transaction and Server will easily know that its a
retransmission rather then fresh REGISTER.
Thanks and Regards,
Vivek Takwar
On Thu, Sep 4, 2014 at 7:55 PM, Chaim Geretz wrote:
> G
Hi Anurag,
Kindly refer RFC for response 199 which is used to terminate early
dialog. This is extention and client need to first indicate that it
supports 199 response.
Thanks and Regards,
Vivek Talwar
On Fri, May 30, 2014 at 12:13 PM, Anurag Chaudhry <
anurag.chaud...@aricent.com>
Hi Keerthi,
In case of refresh REGISTER or De-REGISTER the CSeq will not be same.
If CSeq is same then yes its a case of loop detection.
Thanks,
Vivek Talwar
On Tue, Oct 30, 2012 at 4:47 PM, Keerthi Srinivasan <
keerthivarmansriniva...@gmail.com> wrote:
> All,
>
> When UA
ignore any
session descriptions in subsequent responses to the initial
INVITE.
Thanks and Regards,
Vivek Talwar
On Fri, Jul 27, 2012 at 4:58 PM, wrote:
> I hope this holds good, even if there is change of offer/answer in between
> (18X reliable & 200 ok). My dou
offers in any responses
to the initial INVITE. This means that a UAS based on this
specification alone can never generate subsequent offers until
completion of the initial transaction.
Thanks and Regards,
Vivek Talwar
On Fri, Jul 27, 2012 at 4:41 PM, wrote:
>
terminate the
call.
So, if 4xx is not received only then CANCEL will be sent
otherwise send BYE after sending ACK for 4xx response.
Thanks and Regards,
Vivek Talwar
On Fri, Jun 8, 2012 at 1:19 PM, Tarun2 Gupta wrote:
> Hi
>
> Consider the following scenario:
>
>
>
are generally load balancers. Sometimes, few stateless
services reside on stateful proxies also as mentioned by tarun earlier.
Anyhow, to keep track of calls any existing state-full can be enhanced
rather then adding new node.
Thanks and Regards,
Vivek Talwar
On Tue, Jun 5, 2012 at 5:01 PM, Vineet
Hi Vineet,
Its not like that its of no use but again it depends on how one can
use benefits of Stateless proxies.
For example : Stateless proxy helps in managing network load and its
distribution.
Thanks and Regards,
Vivek Talwar
On Tue, Jun 5, 2012 at 3:57 PM, Vineet Menon wrote
,
Vivek Talwar
On Tue, Jun 5, 2012 at 3:40 PM, Vineet Menon wrote:
> HI,
>
> How does a stateless proxy do routing of SIP packets? Can it do accounting
> of calls?
>
> Regards,
>
> Vineet Menon
> ___
> Sip-implementors m
more details.
Thanks and Regards,
Vivek Talwar
On Mon, Mar 19, 2012 at 12:31 PM, manju nath wrote:
> Hi,
>
> what should be the behaviour of UAS if From header contains multiple
> tag parametrs as shown below:
>
>
> *From: name ;tag=value;tag=value;tag=value*
>
&
in INVITE
request in order to convey same to UAS and UAS should initiate "199" response
leg only in that case.
Thanks and Regards,
Vivek Talwar
Please refer to http://www.frogdesign.com/disclaimer for important disclosures
regarding this electronic communication.
_
/frequency etc.
Refer Offer/Answer model RFC more detail
Thanks and Regards,
Vivek Talwar
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Brez
Borland
Sent: Tuesday, November 29, 2011 4:35 PM
To: sip
hold
Thanks and Regards,
Vivek Talwar
From: sip-implementors-boun...@lists.cs.columbia.edu
[sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Pavesi, Valdemar
(NSN - US/Irving) [valdemar.pav...@nsn.com]
Sent: Friday, September 16, 2011 1:43 AM
Hi Abhishek,
Yes the UPDATE will be sent as per Record-Route received in 18x
response.
Thanks and Regards,
Vivek Talwar
From: sip-implementors-boun...@lists.cs.columbia.edu
[sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of
Hi Prakash,
So this means SBC is implementing privacy services as well due to which it
removed privacy header and modified From header. In case no SBC is in between
you are receiving INVITE as it is.
Thanks and Regards,
Vivek Talwar
From: prakash k
services have not yet modified the user identity.
You are using two different clients on both side?
Thanks and Regards,
Vivek Talwar
From: prakash k [prakash12...@gmail.com]
Sent: Friday, September 09, 2011 11:27 AM
To: Vivek Talwar
Cc: sip-implementors
Hi,
Refer Privacy RFC 3323 for privacy. In incoming INVITE , the privacy value
should not be there and this value should be removed by any application server
hosting privacy services and headers should be modified accordingly.
Thanks and Regards,
Vivek Talwar
Hi Salil,
The scenario would be like :
1. Initial INVITE is without SDP
2. 180 Ringing containing SDP Offer
3. Now Initiating party will send PRACK for 180 ringing with answer to
offer
Thanks and Regards,
Vivek Talwar
From
case "critical"
priv-value is in privacy header and Server providing privacy services is not
able hide user information as per priv-value received.
Thanks and Regards,
Vivek Talwar
From: Worley, Dale R (Dale) [dwor...@avaya.com]
Sent: Friday, August
in turn
be followed by the 'critical' indicator.
So SIP message can have multiple priv-values in privacy header but the
combination of "none" with any other priv-value is invalid. So "none" and "id"
is not valid. Although , if p
then that
will be ignored by proxy. However, in case of stateless proxy, that will also
be forwarded.
Thanks and Regards,
Vivek Talwar
From: Iñaki Baz Castillo [i...@aliax.net]
Sent: Tuesday, May 10, 2011 6:42 PM
To: Vivek Talwar
Cc: Bob Penfield; Brez
Hi Bob,
I think that holds true for stateless proxy. If a stateful proxy has
forwarded final response to UAC then no need to send further responses back to
UAC.
Thanks and Regards,
Vivek Talwar
From: sip-implementors-boun...@lists.cs.columbia.edu
Hi Inaki,
Ya proxy should ignore such responses on such transaction. But dont
you think without forking how such scenario will happen? :)
Thanks and Regards,
Vivek Talwar
From: sip-implementors-boun...@lists.cs.columbia.edu
[sip-implementors
UAC otherwise should
send 480/4xx to UAC and terminate call by sneding CANCEL on legB
Thanks and Regards,
Vivek Talwar
From: sip-implementors-boun...@lists.cs.columbia.edu
[sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Iñaki Baz
Castillo [i
Hi Nahum,
Refer 3gpp spec number 3GPP TS 24.429 for Explicit call transfer.
Thanks and Regards,
Vivek Talwar
_ ___
From: sip-implementors-boun...@lists.cs.columbia.edu
[sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Nahum Nir
Hi Harlin,
I think you want to play two sequential early media announcements back to
back. This can be achieved with same tag but the server involved in SIP
signaling for initiating early dialog have to take care of this.
Thanks and Regards,
Vivek Talwar
the other hand UAS
can also send negative response of call. But rather then 500 response B should
send 408 request time out
Thanks,
Vivek Talwar
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of
From header will be anonymized and so no call will be rejected by ACR.
So ACR simply means if originating user is subscribed to OIR in such a way that
From header is anonymised then that call will be rejected by Application Server
hosting ACR at terminating side
Thanks,
Vivek Talwar
,
Vivek Talwar
-Original Message-
From: Avasarala Ranjit-A20990 [mailto:ran...@motorola.com]
Sent: Tuesday, June 29, 2010 10:49 AM
To: Vivek Talwar; Sumit Jindal
Cc: Bajaj, Gagandeep; Sip-implementors@lists.cs.columbia.edu
Subject: RE: [Sip-implementors] Identity Information in INVITE in IMS
In case of privacy="id" no where mentioned regarding anonymising from header
Thanks and Regards,
Vivek Talwar
-Original Message-
From: Sumit Jindal [mailto:sumitjindal.n...@gmail.com]
Sent: Tuesday, June 29, 2010 10:48 AM
To: Vivek Talwar
Cc: gba...@sonusnet.com; Sip-im
er, then
this thing can happen only if user wants to override the presentation not
restricted or in other words this is like on demand OIR. But in normal OIR
service in permanent mode no such thing happens.
Thanks and Regards,
Vivek Talwar
-Original Message-
From: Sumit Jindal [mai
Refer http://www.3gpp.org/ftp/Specs/html-info/24407.htm
-Original Message-
From: Iñaki Baz Castillo [mailto:i...@aliax.net]
Sent: Monday, June 28, 2010 6:32 PM
To: Sumit Jindal
Cc: Vivek Talwar; Bajaj, Gagandeep; Sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors
In case of the subscriber is subscribed for privacy = id, Only PAI is removed
and if privacy ="header/user" then From header is also anonymised.
And my question is regarding privacy="id"
Thanks,
Vivek Talwar
-Original Message-
From: Sumit Jindal [mailto:sumitj
: Monday, June 28, 2010 6:08 PM
To: Iñaki Baz Castillo; Vivek Talwar
Cc: Sip-implementors@lists.cs.columbia.edu
Subject: RE: [Sip-implementors] Identity Information in INVITE in IMS
Hi Vivek
Yes, you can display "From" header and "anonymous" too, because I guess that is
what the
then UE should display anonymous.
What you think guys?
Thanks and Regards,
Vivek Talwar
"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 privileg
Hi all,
Refer http://tools.ietf.org/html/draft-marjou-sipping-b2bua-01
Thanks & Regards,
Vivek Talwar
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of
radhakrishna
Sent: Fr
particular dialog
is confirmed and all other early dialogs are terminated.
Thanks and Regards,
Vivek Talwar
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Sunil
Bhagat
Sent: Thursday, May 27, 2010 5
,
Vivek Talwar
From: Ayesha Shahab [mailto:ayesha.ti...@gmail.com]
Sent: Thursday, April 01, 2010 11:42 AM
To: Vivek Talwar
Cc: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] Processing a 4xx, 5xx, 6xx response
Hi
Ok..so we terminate all the
Hi,
In order to terminate transaction if OPTIONS received by UE B , it
has to send response to that either any 4xx or 408 timeout. Remember a rule in
SIP, all transactions should terminate
Thanks and Regards
Vivek Talwar
From: Ayesha Shahab
Hi,
All transactions should terminate first of all. And I think as dialog
is not confirmed so all OPTIONS method will be treated like out of dialog and
will be handled by UE B with some error response.
7 A sends ACK
8 B receives ACK.
Thanks and Regards,
Vivek Talwar
-Original
[mailto:gba...@sonusnet.com]
Sent: Tuesday, February 02, 2010 11:25 AM
To: ViVeK tAlWaR; Noble Antony T; sip-implementors@lists.cs.columbia.edu
Subject: RE: [Sip-implementors] Fwd: 481 Call/Transaction does not exist
onBYE
Hi,
If proxy is not maintaining the session, it would treat BYE as any other
Hi,
If proxy is maintaining call-leg then there should be Record-Route
header in 180 and 200 response but as there is no Record route header
present which means proxy is not maintaining session and if UAC is sending
BYE for that session to proxy which is not maintained by it, it can send
C
According to RFC 3261
"CSeq or Command Sequence contains an integer and a method name. The
CSeq number is incremented for each new request within a dialog and
is a traditional sequence number.
"
CSeq increment is not done for specific request it is done for all the
request in the
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
PRACK should sent with Route header with the Record-Route header from 183
response
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Krishna
Rao Gurram
Sent: Tuesday, July 28, 2009 12:26 PM
To: sip-i
You will be required to change media attribute to hold or unhold the call
not the port number.
Change media attribute m to sendonly or recvonly as required by you.
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu
Hi,
You can send 415(Unsupported Media Type) error response.
Regards,
Vivek
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of friend
friend
Sent: Wednesday, April 01, 2009 5:42 PM
To: sip f
400 "Bad request" can also be send when some mandatory header is missing. :)
Cheers,
Vivek
Rancore Technologies
More computing sins are committed in the name of efficiency (without
necessarily achieving it) than for any other single reason - including blind
stupidity."
"On the other hand, we ca
k,
Many thanks for the reply. Will you please suggest the standard where it
is specified as iam required to specify the standard.
Thanks & Regards
Rajeswari.R
-Original Message-
From: ViVeK tAlWaR [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 29, 2008 11:37 AM
To: Routhu, Rajeswa
SIP client send time out.
Cheers,
Vivek
Rancore Technologies
More computing sins are committed in the name of efficiency (without
necessarily achieving it) than for any other single reason - including blind
stupidity."
"On the other hand, we cannot ignore efficiency."
-Original Message---
efficiency (without
necessarily achieving it) than for any other single reason - including blind
stupidity."
"On the other hand, we cannot ignore efficiency."
-Original Message-
From: Kavitha Menneni [mailto:[EMAIL PROTECTED]
Sent: Monday, July 28, 2008 11:38 AM
To: ViVeK
Exactly, BYE will only come to picture after 200 OK of INVITE.
Cheers,
Vivek
Rancore Technologies
More computing sins are committed in the name of efficiency (without
necessarily achieving it) than for any other single reason - including blind
stupidity."
"On the other hand, we cannot ignore ef
Hi all,
UAS will send 4xx response to order to cancel the INVITE. Although if
UAC wanna send CANCEL request it can send same after 180 ringing.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Manjunath Warad
Sent: Tuesday, June 24, 2008 3:29 PM
To: 'K
According to RFC:
In the case of message-oriented transports (such as UDP), if the
message has a Content-Length header field, the message body is
assumed to contain that many bytes. If there are additional bytes
in
the transport packet beyond the end of the body, t
Hi,
For request uri , its tells end UA regarding the version at End A.
_
From: Nitin Arora [mailto:[EMAIL PROTECTED]
Sent: Monday, June 16, 2008 10:11 AM
To: ViVeK tAlWaR
Cc: Sabyasachi Samal; Sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] Simple Query
Hi all,
"SIP/2.0" basically tells regarding that particular header in SIP
follows particular version. So it will simply mean that request URI and Via
follows both that standard.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Sabyasachi Samal
Sen
am wrong. :-)
Cheers!
Vivek Talwar
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Rastogi, Vipul (Vipul)
Sent: Wednesday, June 11, 2008 12:31 AM
To: ·ù ¿µÁØ; sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] When proxy receive
Hi,
According to RFC,
Once the BYE is constructed, the UAC core creates a new non-INVITE
client transaction, and passes it the BYE request. The UAC MUST
consider the session terminated (and therefore stop sending or
listening for media) as soon as the BYE request is passed to th
62 matches
Mail list logo
