Hi,
There is a B2B sitting between A (Caller) and B ( callee)
1) A has sent INVITE without SDP towards B
2) B has responded 200OK with SDP offer for INVITE to A. Refer below the
SDP offer
v=0o=- 16408314 16408314 IN IP4 ABC.DEF.GH.IJs=-c=IN IP4 192.168.119.69t=0
0a=sendrecvm=audio 386
Hi,
There is a B2B sitting between A (Caller) and B ( callee)
1) A has sent INVITE without SDP towards B
2) B has responded 200OK with SDP offer for INVITE to A. Refer below the
SDP offer
v=0o=- 16408314 16408314 IN IP4 ABC.DEF.GH.IJs=-c=IN IP4 192.168.119.69t=0
0a=sendrecvm=audio
Hi,
There is a B2B sitting between A (Caller) and B ( callee)
1) A has sent INVITE without SDP towards B
2) B has responded 200OK with SDP offer for INVITE to A. Refer below the
SDP offer
v=0o=- 16408314 16408314 IN IP4 ABC.DEF.GH.IJs=-c=IN IP4 192.168.119.69t=0
0a=sendrecvm=audio 38
Hi,
There is a B2B sitting between A (Caller) and B ( callee)
1) A has sent INVITE without SDP towards B
2) B has responded 200OK with SDP offer for INVITE to A. Refer below the
SDP offer
v=0o=- 16408314 16408314 IN IP4 ABC.DEF.GH.IJs=-c=IN IP4 192.168.119.69t=0
0a=sendrecvm=audio 38
Hi, Please refer the below diagram
UAC
INVITE>
UAS
UAC <-100
Trying---
Hi ,
1) UAC has sent an INVITE request with header Supported: 100rel and also
with SDP offer 2) UAS sends a reliable provisional response with 180 Ringing
with Require: 100rel and also with SDP answer 3) But before even receiving
PRACK by UAS for above step , UAS sends a final failure 4x
?
Regards,
Sourav
On Wednesday, 29 June 2016 7:48 PM, Sourav Dhar Chaudhuri
wrote:
Hi Brett, Thanks a lot for your immediate response.
Unfortunately, I did not get your explanation clearly
"Based upon what you supplied, you need to implement RFC 5502 errata
4648concerning
Hi Brett, Thanks a lot for your immediate response.
Unfortunately, I did not get your explanation clearly
"Based upon what you supplied, you need to implement RFC 5502 errata
4648concerning when Name-Addr must be used...If you implement the errata,
the brackets will allow the header to b
Hi, Actually, I am facing issue with the request having P-Served-User in my
request. Remote node is failing for that request with my below mentioned
value telling Parser error for the below example.
sip:+ACE34610520436;cic=+7...@tqf01.test.abc;sescase=term;regstate=unreg
Moreover another thi
the other responses to this query.
See RFC6337 for more detail.
Thanks,
Paul
On 12/18/15 7:45 AM, Sourav Dhar Chaudhuri wrote:
> Hi, Please refer the diagram below Callflow diagram
>
> 1) A - INVITE [ Support: 100 rel] without SDP
>--
Hi, Please refer the diagram below Callflow diagram
1) A - INVITE [ Support: 100 rel] without SDP
--> B
2) A <-- 180 Ringing [Require: 100 rel] with SDP offer
B
3) A PRACK without SDP
--
Hi, I just need clarification is the below mentioned scenario will work
properly
UAC1 sending INVITE request to UAS1
--
From: "+351964901478" ;tag=AUA401YVCeghCjaA
UAS1 is responding 100 Truing for that INVITE to UAC1
---
On 5/5/15 4:21 AM, Sourav Dhar Chaudhuri wrote:
> Hi Paul,
> Thanks for your response. So it means the Call Forwarding always
> need minimum requirement that Caller [UAC] must have support for
> handling forking response in case SBC does not have the "fix" you mentioned.
&g
ted in RFC
5359. Is support to handle forking response is mandatory requirement for a SIP
Caller [UAC]?
Thanks,Sourav
On Monday, 4 May 2015 9:38 PM, Paul Kyzivat wrote:
On 5/4/15 10:49 AM, Sourav Dhar Chaudhuri wrote:
> Hi , I have a question on To tag change during Ca
Hi , I have a question on To tag change during Call Forwarding [Unconditional
/ Busy/ No Answer]. As per RFC 5359, it can be noticed that To tag value is
getting changed from 181 Call is being forwarded to 180 Ringing response during
Call Forwarding.
Now my query is if a caller does not su
Hi, Please refer the below example.
+381114400301 is getting registered. All Mandatory header is not mentioned in
the below example
REGISTER request of +381114400301
From:
;tag=h7g4Esbg_3a16584d1dTo:
sip:+381114400...@sluzbeni.ims.telenor.rs:5060Contact: "+381114400301"
;expires=3600;+sip.in
sage-
> From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-
> implementors-boun...@lists.cs.columbia.edu] On Behalf Of Sourav Dhar
> Chaudhuri
> Sent: Tuesday, November 04, 2014 2:20 PM
> To: ankur bansal
> Cc: sip-implementors@lists.cs.columbia.edu
> Subject: R
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 Chaudhuri
wrote:
Hi,
>
swer two codec [ 8 101 ] with attribute for only [ 101 ]. The
rtpmap is also for only [ 101 ].
So is the A is behaving correctly ? Whether there is failure in SDP
negotiation? If yes then why?
Regards,
Sourav Dhar Chaudhuri
___
Sip-impleme
=BYE
Or I have not understood correctly. Something else u want to say?
Kindly guide me
Thanks
Sourav Dhar Chaudhuri
On Wednesday, 29 October 2014 5:00 PM, Brett Tate wrote:
> 1) User A created a Dialog with User B. [ Call ID: AB, To tag: b1,
from tag: a1]
>
> 2) User A cre
n D will
understand for which Dialog the BYE request need to be send since there is no
details of the Dialog is mentioned in Refer-To header?
Thanks
Sourav Dhar Chaudhuri
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.e
for replaces header. So in that case how does the User agent
B will behave when it will receive the REFER request which is having existing
Dialog information in that Refer to header with replaces parameter?
Thanks
Sourav Dhar Chaudhuri
On Tuesday, 28 October 2014 5:23 PM, Vivek Batra
wrote
this case the Use Agent
will not support that REFER request? is there any RFC reference.. I have not
got anything relevant in RFC 3515 for this.
Thanks
Sourav Dhar Chaudhuri
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https
yzi...@alum.mit.edu <mailto:pkyzi...@alum.mit.edu>]
> Sent: Wednesday, October 15, 2014 5:47 PM
> To: sip-implementors@lists.cs.columbia.edu
> <mailto:sip-implementors@lists.cs.columbia.edu>
> Subject: Re: [Sip-implementors] can CRBT palyed without Reliable
> Provisonal respo
sional response?
Regards
Sourav Dhar Chaudhuri
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
In that A will send its MGW's IP in
C=1.1.1.2
Connection Address: 1.1.1.2
Owner Address: 1.1.1.2
but problem is, when B
replies in 200OK ... in that..
B is sending Owner address as
2.2.2.2 and connection address as 2.2.2.1
Owner address is B's CA, not MGW
Is this correct response.
Hi Paul,
Thanks a lot for your detailed response. You have answered all my doubts.
I am really grateful for your email.
Thanks & Regards,
Sourav Dhar Chaudhuri
On Tuesday, 5 August 2014 8:11 PM, Paul Kyzivat wrote:
On 8/4/14 10:12 AM, Sourav Dhar Chaudhuri wrote:
> Hi,
&
Hi,
Is there any way when a answered call [ 200OK is already provided for
initial INVITE and ACK also sent] can be transferred without using REFER method?
If it is possible without REFER then please let me know required procedure.
Thanks,
Sourav Dhar Chaudhuri
Hi,
Is it possible to configure custom IOI and/or FNI filed in P-Charging-Vector in
SIP message header per traffic route?
Thanks & Regards,
Sourav Dhar Chaudhuri
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
h
is considered as
a reregistration.
In any other case is possible where any REGISTER request will be considered as
reregistration ?
Actual I am asking reregistration terminology specifically due to
Authorization implementation for reregistration.
Thanks & Regards
Sourav Dhar Chaud
Expiry = 0 . Whether UE
will be deregistered?
Thanks & Regards,
Sourav Dhar Chaudhuri
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
getting the exact reference from any RFC.
Thanks & regards
Sourav Dhar Chaudhuri
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
wrote:
On 10/29/13 9:55 AM, Sourav Dhar Chaudhuri wrote:
> Hi,
> I need the expected response for the Call scenario mentioned below
>
> 1) UAC sends INVITE request with SDP
>
> 2) UAS sends 180 ringing to UAC
>
> 3) Then UAS sends 200 OK fo with SDP response INVITE .
&g
mentioned in STEP 1 towards UAS. Is it a valid behavior?
5) Now what should be the response from UAS for that UPDATE request ??
After sending the UPDATE request UAC has also also ACK request for 200 OK
response.
Thanks & Regards
Sourav Dhar Chaud
hi,
UAS MUST not send 200OK for PRACK and must ignore the PRACK. UAS .
As per RFC 3262 section 5
All user agents that support this extension MUST support all
offer/answer exchanges that are possible based on the rules in
Section 13.2 of RFC 3261, based on the existence of INVITE and PRAC
t will be
really helpful if anybody please explain with example that is with call flow?
Thanks
Sourav Dhar Chaudhuri
Cricket on your mind? Visit the ultimate cricket website. Enter
http://beta.cricket.yahoo.com
___
Sip-implementors mail
ipos <[EMAIL PROTECTED]>
To: Sourav Dhar Chaudhuri <[EMAIL PROTECTED]>; Navneet Gupta <[EMAIL
PROTECTED]>; sip-implementors@lists.cs.columbia.edu
Sent: Thursday, 25 September, 2008 1:52:29 PM
Subject: RE: [Sip-implementors] UA behaviour on recieving INVITE
withoutmax-forwards header
Sipos <[EMAIL PROTECTED]>
To: Sourav Dhar Chaudhuri <[EMAIL PROTECTED]>; Navneet Gupta <[EMAIL
PROTECTED]>; sip-implementors@lists.cs.columbia.edu
Sent: Thursday, 25 September, 2008 1:01:19 PM
Subject: RE: [Sip-implementors] UA behaviour on recieving INVITE
withoutmax-forwards head
Hi Navneet,
Sip UA(End Point)
behavior on receiving INVITE without max-forwards header depends on
implementation of backward compatibly with RFC 2543.
If the Sip UA(End Point) backward compatible with RFC 2543
then it MUST follow step (d) said by you.
RFC 2543 does mandate Max-
ultiple "Via header" value
in initial INVITE request among which top "Via header" value has to be selected
Thanks
Sourav
- Original Message
From: Rockson Li (zhengyli) <[EMAIL PROTECTED]>
To: Sourav Dhar Chaudhuri <[EMAIL PROTECTED]>;
sip-implementors@lists.
Hi,
Can multiple Via header be present in initial INVITE request ?
I mean to say when first time INVITE request is generated from UAC without
traversing any PROXY can contain multiple Via header ?
If yes then what is the need of having multiple Via header in initial INVITE
request?
Than
Hi Jagan,
As per ABNF grammar mentioned in RFC 3261 that Timestamp header can
contain value 0 but no negative value
Timestamp = "Timestamp" HCOLON 1*(DIGIT)[ "." *(DIGIT) ] [ LWS delay ]
delay = *(DIGIT) [ "." *(DIGIT) ]
DIGIT = %x30-39 ;0-9
Regards
Sour
n
Caller A has to suffer even knowing at very early stage of
call also he does not have any scope to rectify it.
But If start only after
sending ACK for 200OK of INVITE this scenario can be prevented by sending BYE
for 200OK instead of ACK
Regards
SOURAV DHAR CHAUDHURI
Bring your gang
not understand that RPR. Server B will be also not able to send Final response
for INVITE as his RPR containing a offer not got any answer. Call cannot be
established.
So server B will discard the INVITE with Require:100rel but no
Supported:100rel as a Bad request
Thanks
SOURAV DHAR CHAUD
Hi,
I had a doubt regarding the following:
If the server recieves the same INVITE request differing only in the CSeq value,
what should be the ideal behavior? Should this be treated as a new call?
THANKS
SOURAV DHAR CHAUDHURI
Get the freedom to save as many mails as you wish. To know
Supported:100rel.)
So now callee B will send RPR or not as it has the feature Require:100rel but
no Supported:100rel?
- Original Message
From: Paul Kyzivat <[EMAIL PROTECTED]>
To: Sourav Dhar Chaudhuri <[EMAIL PROTECTED]>
Cc: sip-implementors@lists.cs.columbia.edu
Sent: Thurs
:100rel
Regards
SOURAV DHAR CHAUDHURI
- Original Message
From: srinivas <[EMAIL PROTECTED]>
To: Sourav Dhar Chaudhuri <[EMAIL PROTECTED]>;
sip-implementors@lists.cs.columbia.edu
Sent: Thursday, 27 March, 2008 6:35:29 PM
Subject: RE: [Sip-implementors] For sending PRACK for
:100rel in its INVITE request.
I am asking the second question because if that thesame capability is
present in Callee so whether after receiving any INVITEwith Require:100rel ,
whether callee will be not be able to send RPR.
Thanks
SOURAV DHAR CHAUDHURI
Did you know? You can
48 matches
Mail list logo
