@arun.taga...@gmail.com
Please check RFC 5626 3.3
<https://datatracker.ietf.org/doc/html/rfc5626#section-3.3>. Multiple
Connections from a User Agent
I believe you might find your answers here in this RFC which explains about
creating multiple flows
Regards
Ankur Bansal
On Sat, Nov 20, 2
responded to as per RFC
4028 .
Once 200ok Invite comes then only the refresher and session-expire
interval would be finalized for the session .
2. Any refresh request(Reinvite/Update) after the session is established
will have effect on session expiry interval or refresher .
Regards
Ankur Bansal
or
refresh-registration while SIM is removed.
Hope this helps.
Regards
Ankur Bansal
On Sun, May 3, 2020 at 8:37 PM Ranjit Avasarala
wrote:
> Thank you Dale. as part of SIM swap testing, I came across the below
> scenario:
> the Phone number (MSISDN-1) was registered with IMSI (IMSI-
c .
As these actions are very generic and no dependency on Application
logic so sipStack should do it .
Kindly suggest .
Thanks & Regards
Ankur Bansal
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs
Hi Abhishek ,
>From whatever information shared , I think that Switch here misbehaving .
Switch acting as B2B when adding Require:100 rel in outgoing Invite .
But when 183 SDP (assuming its reliable) comes to switch , its acting as
proxy instead of B2B .
So switch relays 183 Sdp to A and expects A
Please check IR92 to understand volte call flow .
Majorly you should see P-Asserted_Identity, Precondition extensions /QOS in
SDP ,P-Charging Vector headers in volte sip flow .
On Thu, Oct 4, 2018 at 8:22 PM Arun Tagare wrote:
> Hi
>
> Please read RFC#3261
>
> Thanks & Regards
> Arun A. Tagare
o finalize common codec .
Although 3gpp recommends to play media only if early media is authorized
and media gateways should
follow Gateway model(PEM) .
Thanks & Regards
Ankur Bansal
On Sat, Dec 10, 2016 at 6:43 PM, Zuñiga, Guillermo <
guillermo.zun...@cwpanama.com> wrote:
> Hi F
again in dialog-set.
Can you please explain scenario where provisional responses in same dialog
coming via different route ?
Regards
Ankur Bansal
On Wed, Oct 12, 2016 at 1:38 PM, Gagandeep Singh
wrote:
> Hello
>
> Suppose UAC receives multiple provisional responses before confirmation
, Fixed IMS caller always wait for remote ringback tone ?
Why local end DSP resources not used to play local ringback tone on getting
180 ?
Regards
Ankur Bansal
On Fri, Sep 23, 2016 at 4:20 PM, Tarun Gupta
wrote:
> Hello all,
>
> It has been observed whilst testing our WiFi/VoLTE solution
Only possibility is UAC sending Initial Invite having SE:900 and on getting
200ok with SE:600 .
UAC not updating value and still starting timer with 900 sec. UAC behaviour
looks incorrect
Check what value was sent from UAC .
Regards
Ankur Bansal
On Wed, Jun 8, 2016 at 8:09 PM, Brett Tate wrote
A.
>>>>Is this right behavior of proxy or it should forward only the ringing
response in which call leg it has been answered ?
As mentioned there is no harm in relaying forked 180s if A supports fork,
later when final success response comes
it can be relayed too.
Thanks & regards
for him.
As local ringback tone is generated by UE A (by reserving DSP resources)
after getting 180 and played to user.
Regards
Ankur Bansal
On Fri, Mar 18, 2016 at 1:10 AM, Ramachandran, Agalya (Contractor) <
agalya_ramachand...@comcast.com> wrote:
> Hi Ankur,
>
>
>
> I
ately rather than caching
(where in worst scenario of 481 also no impact)
But dont think its mentioned anywhere explicitly .May be others can provide
some reference for this .
Regards
Ankur Bansal
On Tue, Mar 15, 2016 at 4:13 PM, Mohit Soni wrote:
> Hi,
>
> RFC3262 states following u
last TCP connection while opening new.
Regards
Ankur Bansal
On Tue, Mar 15, 2016 at 4:29 PM, xaled wrote:
> Hi,
>
> >As far as I know, the main complaint is that it can temporarily
> prevent/delay honoring
> >the DNS configured load balancing and priorities.
>
> So
Hi
There is no recommendation for using exisiting TCP connection for in-dialog
Sip requests.
As MTU for PRACK/BYE can be smaller ,so can be send over UDP also .
But for TLS recommendation is there to reuse same connection ,even for
request coming from callee using alias in via .
Regards
Ankur
UAC as per his local policy.
It seems User A side has issues with changing refresher parameter based on
transaction outgoing or incoming.
Anyway 200ok of INVITE will finally decide the role and it should be UAC
as INVITE was offering that as per table2(UAS behaviour)
Regards
Ankur Bansal
On Thu
received at UE A ,does it have Route header
in it ?
Regards
Ankur Bansal
On Wed, Feb 10, 2016 at 7:30 AM, Alex Balashov
wrote:
> And yes, I realise that from the vantage point of the BYE request, B is
> the UAC and A is the UAS. That was a poor choice of labelling on my part.
>
>
>
local policy
found it inside/outside trusted domain.
But this decision should not be based on values preConfigured matching or
not on AS nodes.
Thanks & regards
Ankur Bansal
On Fri, Feb 5, 2016 at 10:59 AM, Basu Chikkalli
wrote:
> Hi,
>
> Does P-Access-Network-Info Header recei
not always same
as if initial INVITE offer sent by same UE.
You can refer RFC 6337 Section 5.2.2
Thanks & regards
Ankur Bansal
On Tue, Jan 19, 2016 at 2:01 AM, Harald Radke wrote:
> Hi,
>
> hmI would say for a start that RFC3264 applies (8.3.2):
> " The list of medi
You can get more details from RFC 3361 .Please check it .
Regards
Ankur Bansal
On Tue, Oct 27, 2015 at 12:28 PM, Kamini Gangwani <
kamini.gangw...@aricent.com> wrote:
> Hi,
>
> Can anyone help me providing some details regarding implementation of DHCP
> Option 120 on SIP Gate
also same
so wont able to distinguish early dialogs without using to-tags .
Hence thinking of all possible scenarios ,we would realise that we need
combination of call-id,from tag and to tag
to identify unique dialog even if callid is anyway generated unique across
call.
Regards
Ankur Bansal
On
As all mentioned its all possible to send any direction till UE follows
offer-answer model but its lacking actual use-case and seems ill-logical.
Just want to share one point regarding step 4 , where UAC2 sending sendonly
and it seems UAC2 suddenly have something to send which he was not having
in
used but each side using only one out of 2 both
have.
TCP case ,for same flow all 4 SPIs will be used .
Hope this will clarify .Otherwise capture one register trace in TCP ,UDP
and check it properly.
Thanks & regards
Ankur Bansal
On Tue, Jun 2, 2015 at 2:24 PM, Priyaranjan Nayak wrote:
during
Registration-401 flow where
S-CSCF will send IK,CK keys in 401 response towards P-CSCF which P-CSCF
will remove before relaying 401 to UE .UE would generate these keys
from SIM .
Thanks
Ankur Bansal
On Mon, Jun 1, 2015 at 12:53 PM, Priyaranjan Nayak <
priyaranjan4...@gmail.com>
Hi Roger
Cisco PBX behavior seems correct here .Also after transfer is complete in
step 3 ,
Phone-A is out of picture after having BYE exchange with Phone-B and PBX.
So during step 4, PBX should use PAI of Phone-B.
Regards
Ankur Bansal
On Tue, May 12, 2015 at 4:55 PM, Roger Wiklund
wrote
ase correct if im wrong.
>
> On Thu, Apr 9, 2015 at 11:38 AM, Imran Saleem wrote:
>
>> Dear Ankur and Brett & paul
>>
>> thanks for sending in valuable advise. I will go through the details.
>>
>> Many thanks,
>>
>> On Thu, Apr 9, 2015 at 11:2
Hi Imran
I assume Side B is not compliant to standards.
1. On getting BYE ,side B should clear dialog associated with INVITE
transaction but INVITE transaction should be alive .
In your case side B has not sent any final response for INVITE to
complete the INVITE transaction .
It seems Sid
Other commonly used example is MOH .Where UE putting call on hold sends
INVITE no sdp to Music server .
As Brett mentioned mostly its used in 3PCC .
On Wed, Dec 17, 2014 at 5:36 PM, Brett Tate wrote:
>
> RFC 3725 shows the 3PCC usage.
>
> > -Original Message-
> > From: sip-implementors-b
Hi
Reinvite acting as session modification request here so its behavior should
be atomic.
And reinvite failed in the end reason could be any error response or offer
answer failure.but uac should try to restore session state sending update
request to get session back in sync as recommended in rfc 63
Saurav
We always try to complete call somehow as providing reliable service to
user is utmost important and i have seen solutions voilating standards in
actual deployments to provide services to end user.
And luckily in our scenario standard is recommending the acceptance of diff
payloads to make c
99. B has not
> mentioned it support for payload 99.
>
> Thanks
>
> Sourav
>
>
> On Tuesday, 4 November 2014 9:48 PM, ankur bansal
> wrote:
>
>
> Hi Saurav
>
> I believe there is no issue due to rtpmap as its required only for
> dynamic payloads and not f
not* send BYE and accept this answer sending telephony
events with payload no 101 instead of 99 which is expected by UE B.
And UE B needs to send telephony events with payload no 99 towards UE A.
Hope this helps
Thanks & Regards
Ankur Bansal
On Tue, Nov 4, 2014 at 9:12 PM, Sourav Dhar Chaud
to
transaction accepted then at same time they would have made ACK handling
also same for any final response .
But its kept same for some reason which i am trying to understand.
On Fri, Oct 31, 2014 at 10:04 PM, Paul Kyzivat
wrote:
> On 10/31/14 12:27 PM, ankur bansal wrote:
>
>> Hi A
Hi All
Why ACK is made separate transaction when 2xx is final response.Reasons
being given that TL is deleted on getting 2xx to be independant of
upperlayer whether its UA core or proxy core.but now after rfc 6026 came TL
not deleted on getting 2xx.then whats the reason to keep ACK still new
trans
can carry sdp as new offer instead of sdp in
200ok.bottomline is only one offer answer possible in one transaction.
Hope this helps
thanks
ankur bansal
On Thu, Oct 16, 2014 at 11:11 AM, Mustafa AYDIN
wrote:
>
> Inline
>
> Mustafa Aydın
> NGN Services
> Verscom Solutions
&
2xx for both TCP/UDP being end to end ,does same
way
UE should retransmit 18x reliable response for both tcp/udp .
Appreciate any inputs.
Thanks & Regards
Ankur Bansal
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
h
orever as per RFC
5626
P1 -->P2 -->P3 --->P1 -->P2-->P3.
UE can put logic to put cap on retry max duration(say 2 hours) otherwise
device can be having performance ,heating issues.
Thanks & Regards
Ankur Bansal
On Tue, Jul 22, 2014 at 10:04 AM, RC
Response would be 403 for Subscribe if PAI header is wrong in Subscribe
request .
means PAI header is not from list(ist Uri ) came in 200 ok PAssociatedUri
header of Register.
Thanks & regards
Ankur Bansal
On Mon, Jul 21, 2014 at 12:48 AM, Pranav Damele
wrote:
> Hey Sunil,
>
> I
therwise if BYE is being sent to B1 then UAS will still have INVITE
transaction pending till times out.
So ideally CANCEL should come to UAS from proxy so that 487 can be sent and
apart from dialog ,invite transaction too can be cleaned.
Thanks & regards
Ankur Bansal
On Fri, May 30, 20
t so IPSec will
have issue )
So here after TCP connection breaks ,call should be dropped .All IMS
communcation should be in same connection as of Register.
You may get some reference in 3gpp spec 33.203 .
Thanks & regards
Ankur Bansal
On Tue, Apr 29, 2014 at 6:11 PM, Paul Kyzivat wrote:
&
at T1 and goes till
T2=64*T1)) is done by UAS Core for UDP only till PRACK comes.
If T2 fires then UAS send 5xx for INVITE.
Thanks & regards
Ankur Bansal
On Tue, Apr 29, 2014 at 6:42 PM, Brett Tate wrote:
> See RFC 3262 section 3.
>
>
>
> *From:* Aditya Kumar [mailto:adity
sip.automata=false to
refuse to communicate with automation server .
Thanks & regards
Ankur Bansal
On Tue, Apr 29, 2014 at 8:05 PM, SIP Learner wrote:
> Thanks Paul!
>
>
> At first I thought automaton as a typo too, but I found out that the most
> recent RFC7088 also use automaton
initial
registration attempt afterwards
.Example would be movement from LTE to WIFI (both
supports IMS)
rejected – this event occurs when the network does not allow the user to
register the specific contact.
Thanks & regards
Ankur Bansal
On Wed, Apr 23, 2014 at 9:5
n
Thanks & regards
Ankur Bansal
On Sun, Mar 9, 2014 at 12:27 PM, Aditya Kumar wrote:
> HI,
> If a user gives offer with c1,c2,c3 codec's (m lines).
> can the answer be with c2,c3 mlines and followed by a lines.
> like: c2-sendonly c3- sendrecv?
>
> I am asking from a Voice C
unauthenticated requests.
Retransmitting the 401 (Unauthorized) or 407 (Proxy Authentication
Required) status response amplifies the problem of an attacker
using a falsified header field value (such as Via) to direct
traffic to a third party
Thanks & Regards
Ankur Bansal
& regards
Ankur Bansal
On Sun, Feb 23, 2014 at 11:04 PM, Brett Tate wrote:
> > SIP calls are failing due to differing session versions
> > received in the SDP of the 183 and 200ok messages. The
> > MSC server releases the call immediately due to
> > unexpected SD
INVITE and not SMS application .
Also Caller can express its preferences putting feature-tags in
Accept-contact,reject contact header.
Paul already mentioned about Feature-caps
Thanks & regards
Ankur Bansal
On Mon, Feb 24, 2014 at 7:32 AM, Paul Kyzivat wrote:
> On 2/23/14 8:32 PM, Adity
stay in call so call can be
disconnected(thats why called blind transfer) rather of putting on hold .
In case of consultative transfer ,Add call ,conference scenarios we
normally need to put call on hold .
Thanks & regards
Ankur Bansal
On Mon, Feb 24, 2014 at 8:04 PM, Parveen Verma wrote:
>
response is
3xx-6xx but in your case final response is 200 ok .So these timers will not
be effective.
Hope this will clarify your doubt.
Thanks & regards
Ankur Bansal
On Mon, Feb 17, 2014 at 4:56 PM, Brett Tate wrote:
> Hi,
>
> It sounds like the stateful proxy is not complian
e application should ignore retransmitted provisional
> responses, since the first PRACK will be retransmitted until 200 OK is
> received (and by that time there will be no more retransmissions of the
> provisional response.
>
>
>
> Regards,
>
> // Andreas
>
>
>
>
&
PRACK for prov response
retransmission ,as UAC will be doing it anyway as per normal sip timers.
Thanks & regards
Ankur Bansal
On Tue, Feb 11, 2014 at 1:11 PM, Olle E. Johansson wrote:
>
> On 11 Feb 2014, at 08:30, Andreas Byström (Polystar) <
> andreas.byst...@polystar.com&
.
So basically difference is due to TCP connection oriented nature and TCP
connection reuse property.
Thanks & regards
Ankur Bansal
On Mon, Feb 10, 2014 at 11:15 AM, Aditya Kumar wrote:
> Hi,
> when using IP-Sec and sending the subsequent SIP:REGISTER after receiving
> 401 challenge,
Aditya
To-tag is not required in De-Register .Register with expires:0 is enough ,
Also to-tag never goes in any of Register .
On Mon, Jan 27, 2014 at 7:46 PM, Aditya Kumar wrote:
> HI,
> I have a Registration Active in IMS.
> when I want to do a De-Register should I have the to-tag in the Regis
not required as
UA1 will never get provisional response for Re-INVITE.
As this extension push UA2 to send reliable prov response but it does not
push UA2 to send provisonal response so it should be ok .
Thanks & regards
Ankur Bansal
On Thu, Jan 16, 2014 at 9:03 PM, Kchitiz Saxena wrote:
> H
Hi Aditya
Please go through Section 17.2.1 INVITE Server Transaction of RFC 3261
In brief , UE(trxn layer) should retransmit final response till Timer H(64
* T1) fires .and if still ACK not came ,transaction will move to terminated
state .
Thanks & regards
Ankur Bansal
On Sun, Dec 29, 201
Hi Paul ,
Yes this seems more logical from general implementation .thanks
Regards
Ankur Bansal
On Tue, Nov 26, 2013 at 9:37 PM, Paul Kyzivat wrote:
> On 11/26/13 9:06 PM, ankur bansal wrote:
>
>> Hi Aditya
>>
>> I think this is valid from protocol and offer answer mo
r
B resumes (recvonly)
A resumes(sendrecv) -Both way active-->
User B (sendrecv)
*So while resuming call , both users putting recvonly.*
Hope this helps
Regards
Ankur Bansal
On Mon, Nov 25, 2013 at 6:30 AM, Paul Kyzivat wrote:
> On 11/24/13 1
Hi Sundar
As far as i remember this ptime parameter is media level attribute and it
should be same for all payloads mentioned for that particular media line
.You can check more in SDP RFC 4566.
Thanks & regards
Ankur Bansal
On Tue, Nov 26, 2013 at 12:01 PM, Sundar Ramakrishnan wrote:
>
doing this will take extra signalling (Update again
after retry-after time)
to actually make call working .
>200 ok sdp can also be sent if UE is lenient.
Anyhow we should always try to make call successful .
Thanks & regards
Ankur Ba
user A
can trigger BYE to User B2 with its specific to-tag.
Thanks & regards
Ankur Bansal
On Tue, Oct 8, 2013 at 12:45 PM, Jan Bollen wrote:
> Hello,
>
> The question is: where is the "pending" request in the presented scenario
> with the BYE sent in a early dialog
is no
other way to send QOS parameters.
2. conf parameter is not mandatory and its actually requirement driven .
If UAS wants to confirm QOS status of UAC before accepting call , then
it must add a:conf in sdp of 183 response.
Thanks & regards
Ankur Bansal
On Fri, Sep 27, 2013 at 11:5
irectly send 180
ringing and then 200 ok sdp.
Thanks & regards
Ankur Bansal
On Thu, Sep 26, 2013 at 10:44 PM, Aditya Kumar wrote:
> Hi,
>
> Can any one please explain me about
> a=conf:qos remote sendrecv
> this header in detail. I did not understand that.
>
> what is the
be waiting only for 487 response .If that
is the case ,then fix your source node.
Thanks & regards
Ankur Bansal
On Fri, Sep 20, 2013 at 2:44 PM, sampat patnaik wrote:
> Hi,
>
> If you look at the trace , we can say that INVITE message is being sent 7
> times while SBG r
from Source and
should send 487 response to Source .
*Problem here seems to be with Source* : As its expected from Source to
gracefully send ACK for every final response .
Thanks & Regards
Ankur Bansal
On Fri, Sep 20, 2013 at 11:08 AM, sampat patnaik wrote:
> Hi,
>
> Gr
worst case but still anything possible .
Thanks & Regards
Ankur Bansal
On Fri, Sep 13, 2013 at 6:22 PM, Balint Menyhart wrote:
> Hi,
>
> I would suggest you do validation first, and if it succeeds, you send
> 180 Ringing.
> But sending 4xx after a 180 is legal. Best exam
original request. If it has, the CANCEL
request has no effect on the processing of the original request, no
effect on any session state, and no effect on the responses generated
for the original request.
Thanks & regards
Ankur Bansal
On Fri, Sep 13, 2013 at 4:37 PM, satish agr
, it does not impact INVITE
transaction .
Hence sipstack will be waiting for final response for Invite for 64*t1 .
Hope this helps .
Thanks & Regards
Ankur Bansal
On Fri, Sep 13, 2013 at 4:25 PM, satish agrawal wrote:
> Hello Casey,
>
> As per RFC 3261 section 9.2
>
>
Client can trigger BYE with to-tag of that early dialog and other 2
early dialogs would still be there .
Thanks & regards
Ankur Bansal
On Tue, Sep 10, 2013 at 12:29 PM, isshed wrote:
> *Hi All,*
> *
> *
> *Below is the scenario we need to implement for our client. This is a
&g
68 matches
Mail list logo
