I want to unsubscribe from this mail list.
Thanks..
Sunil
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
re-INVITE
asking to change to RTP. What should client do in this case? Accept, as
SRTP is not mandatory or drop the call?
Which RFC should I refer for this scenario and what does it say in this
case?
Regards,
Sunil
___
Sip-implementors mailing list
Sip
Hi Paul,
Wrong P-Asserted Identity means the one which was not in the list of
P-Associated URI.I am not sure
whether to send 403 since i couldn't get the reference of exact behavior in
the RFC.
Thanks and Regards,
Sunil
> Message: 2
> Date: Sun, 20 Jul 2014 14:35:30 -0400
&
Hi Raghavendra,
UAC can add P-ASSERTED Identity.Please refer RFC 5876.
Thanks and Regards,
Sunil
On Mon, Jul 21, 2014 at 10:56 AM, Raghavendra D P <
raghave...@techmahindra.com> wrote:
> Hi Sunil,
> P-Asserted identity is added by P-CSCF not the UE.
> UE adds P-Preferr
Hi All,
What should be the behavior of CSCF if it receives Subscribe
request from UE
with wrong P-Asserted Identity header?.
Thanks and Regards,
Sunil
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https
/ "_" / "+" / "`" / "'" / "~" )
>
> > -Original Message-
> > From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-
> > implementors-boun...@lists.cs.columbia.edu] On Behalf Of J C Sunil
> &g
Hi All,
I need to send a proprietary parameter in contact header in an INVITE
message to other end.
Something like this:
Contact: "Sunil" ;category:strvalue
Here "category:strvalue" is my proprietary parameter. Where "category" is a
param name and "strvalu
49152 RTP/AVP 0 18 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=rtpmap:8 PCMA/8000
a=silenceSupp:off---
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=silenceSupp:off--- attribute is global for all codec's or only for the
last rtpmap before it ?
Regards,
Sunil Verma
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of
Frank S.
Sent: Tuesday, October 16, 2012 11:43 PM
To: sip-implementors@lists.cs.columbia.edu
Subject: [Sip-implementors] Codec Negotiation
PRACK is considered as NON Invite Transaction, hence rules applicable to
NON Invite transaction should apply.
Refer to section 17.2.2 for all timer related query for the response.
Regards
Sunil Verma
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip
Hi All,
The header field can have the values "non-urgent", "normal", "urgent", and
"emergency". How do we define these header field values with our practical
life scenario?
Thanks & Regards
-sunil
___
Si
handling of ICMP
error for sip messages.
Thanks and Regards,
Sunil
On Thu, 2011-09-15 at 14:35 +0800, Shanbhag, Somesh (NSN - IN/Bangalore)
wrote:
> Hi Sunil,
>
> Can you please brief about the actual scenario which you are facing?
>
> It depends on invite transaction, non inv
transaction and session without sending further messages.
Regards,
Sunil
On Thu, 2011-09-15 at 14:49 +0800, Verma, Salil (NSN - IN/Gurgaon)
wrote:
> Hi Sunil ,
>
>
>
> If a failure/error occurs, the client SHOULD create a new request,
> which is identical to the previous, but has
action to take if we receive ICMP error for a
response.
Regards,
Sunil
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
yes there can be more 18X and PRACK based OA sequence, in case of call forking
scenario.
If there is no call forking it should be UPDATE that need to be used for
modification of offer before 2XX is receieved.
Regards
Sunil Verma
-Original Message-
From: Nauman Sulaiman
Yes, it is allowed.
If you see proxy and other entity, they need 18x response to retain the
transaction(Timer C).
Regards
Sunil Verma
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of
Nauman
.
Can you share the INVITE SDP?
Regards
Sunil Verma
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of
Johnson, Michael A
Sent: Tuesday, June 28, 2011 12:30 PM
To: sip-implementors@lists.cs.columbia.e
Isshed,
Target Dialog header is needed only if you are sending REFER
outside the dialog.
Regards,
Sunil
--
>
> Message: 2
> Date: Wed, 27 Apr 2011 13:22:20 +0530
> From: isshed
> Subject: Re: [Sip-implementors] Call Transfer Using RE
every cancel if server is sending 481,
then Server is working fine.
But if Server is sending 481 without any trigger i.e. CANCEL/ACK then server is
at fault.
I hope I have not confused you.
Regards
Sunil Verma
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
I think he is refereeing to SIP client, it can be both UAC/UAS.
Correct me if I am wrong.
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of
Paul Kyzivat
Sent: Thursday, March 31, 2011 5:30 PM
To: sip
In case the request sent by user is forked by proxy and received back by
originator of request.
There will be use cases when we use call handover features.
Regards
Sunil Verma
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun
,
Sunil
Date: Tue, 22 Feb 2011 19:14:07 +0530
From: Vivek Talwar
Subject: Re: [Sip-implementors] Call Transfer
To: Nahum Nir ,
"sip-implementors@lists.cs.columbia.edu"
Message-ID:
<6ecb42c4ce996f428c7f445c0568f330033...@gurexmb01.asian.ad.aricent.com>
above requirement
ie., the offer in 2xx will contain the negotiated media stream and
include the capability specific attributes which includes all the media
formats, all parameters etc.
Many thanks in advance for your precious time..
Regards,
Sunil
__
makes sense to delete the Subscription to reg event package on
deregistration without waiting for NOTIFY WITH TERMINATED STATE .
Please opine.
Regards,
Sunil
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbi
| 603, 606 || |
+--++-+
Please opine.
Thanks and Regards,
Sunil
___
Sip-implementors mailing list
Sip-implementors@lists.cs.
Hi Tarun,
Port=0 is rejection of stream.
Now if only one stream is offered and it is rejected then UAC can
terminate the call.
Regards
Sunil Verma
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf
(a=sendonly or a=inactive) ??
[Sunil: Inactive (refer offer answer RFC3264, INACTIVE offer can have
answer only as INACTIVE).]
6. B resumes the call with a=recvonly.
7. A sends 200 ok with a=sendonly.
8. A again resumes the call with a=sendrecv.
9. What should B send in 200 ok response (a
Hi,
Asymmetric payload is allowed in sip.
As SDP is receive capability hence:
A-> B (RFC2833 Payload :101)
B-> A (RFC2833 Payload :96)
Also based on what is negotiated the streaming will be using that
payload.
Regards
Sunil Verma
-Original Message-
From: sip-implementor
Dear Lee,
In error case scenario where the UA sending the REFER does not
receive NOTIFY with
terminated state,UA should terminate the REFER subscription by sending
SUBSCRIBE
with expires zero.
Regards,
Sunil
Date: Tue, 5 Oct 2010 13:52:41 +0530
From: "Verma Sunil"
Subject
Hi,
The first Notify due to implicit subscription will contain the expire
time value for this subscription. If Subscription refresh request for is
not sent before that Subscription will be considered terminated.
Regards
Sunil Verma
-Original Message-
From: sip-implementors-boun
completion of 2XX response from the new call out of refer,
if user wants to terminate the Subscription, the Notify can have the
current status of New call in SIP frag message, be it 100 Trying or any
other 1XX response.
There is nothing specific about it in RFC.
Regards
Sunil Verma
-Original
NOTIFY request with
Subscription-State as terminated
and with empty body.
Regards,
Sunil
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
which will run
as a timer at UAC/UAS which will terminate the INVITE if no final
response is received after Timer specific in Expire header is
terminated.
At UAC: Cancel will be generated.
At UAS: 487 is generated.
Regards
Sunil Verma
-Original Message-
From: sip-implementors-boun
of a
replacement.
Regards
Sunil Verma
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of
Brandon W Yuille
Sent: Wednesday, September 29, 2010 5:18 AM
To: sip-implementors@lists.cs.columb
in INVITE which can run
timer at UAC to wait for response else drop the request.
Regards
Sunil Verma
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of
Parthasarathi R (partr)
Sent: Saturday
nding upon how request is forwarded.
Regards
Sunil Verma
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of
abhishek chattopadhyay
Sent: Wednesday, September 22, 2010 4:48 PM
To: sip-impleme
Slight modification as I mentioned "sendrecv" at the at line instead if
"receive-only".
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of
Verma Sunil
Sent: Wednesday, September
t; then it will create cross talk and noise.
Regards
Sunil Verma
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of
goutam kumar
Sent: Wednesday, September 22, 2010 3:15 PM
To: sip-implementors@lists.
.
Please refer to Offer Answer RFC 3264 Section 5.1(offer) and 6.1(Answer)
for Unicast Sessions
Regards
Sunil Verma
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of
Paul Kyzivat
Sent: Saturday
Sunil Bhagat would like to recall the message, "SDP in 180 and 200".
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Hi All,
Is there any significance during slow start scenario between receiving SDP
in 18X and SDP in 200 OK?
Regards,
Sunil
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists
I meant using INFO as KeepAlive message... for refresh purpose... is that
not possible?
Regards,
Sunil
-Original Message-
From: Satyakumar [mailto:satyam_...@hyd.hellosoft.com]
Sent: Friday, May 21, 2010 12:27 PM
To: Sunil Bhagat; shya...@huawei.com; sip-implementors
Thanks.
Please correct me if I am wrong, I guess INFO messages could also be used
for the same.
Regards,
Sunil
-Original Message-
From: shyam [mailto:shya...@huawei.com]
Sent: Friday, May 21, 2010 11:48 AM
To: 'Sunil Bhagat'; sip-implementors@lists.cs.columbia.edu
Subject
Hi All,
I have a small query regarding UPDATE method.
UPDATE method is used to change the session parameters. I wanted to know,
what is the use of sending UPDATE without any sdp.
Thanks,
Sunil
___
Sip-implementors mailing list
Sip
Information parameter in the SDP had machine A's ip address
and I could see that RTP messages also use the same port specified in the
"m" line.
Regards,
Sunil
___
Sip-implementors mailing list
Sip-implementors@lists.
Hi All,
One of the requirement in RFC3312 states "A UA that receives an
unknown precondition-type, with a "mandatory" strength-tag in an
offer, MUST
refuse the offer unless the only unknown mandatory preconditions have
the "local" tag".
Anybody please help in understanding this req
I meant dual-stack in the sense implementation for support for
ipv4/ipv6.
Regards,
Suraj
From: Sunil Suraj-a22975
Sent: Wednesday, April 07, 2010 7:02 PM
To: 'sip-implementors@lists.cs.columbia.edu'
Subject: Any standards for implementing SIP dual-s
Hi,
Can anyone please let me know if there is any RFC or draft to
implement SIP dual-stack UAC/UAS?
Regards,
Suraj
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-imple
Hi All,
I have some queries regarding Early media authorization:
1. It is mentioned in the rfc 5009 that "The P-Early-Media header
field may or may not be present
in messages containing SDP." So In the case of INVITE without
SDP, can we add P-Early-Media header
Avasarala Ranjit-A20990
Sent: Wednesday, July 22, 2009 4:51 PM
To: Sunil Suraj-a22975; sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] Query on draft-ietf-mmusic-ice-19
Suraj
Statement 1 applies to scenarios where the agent is changing its
transport addresses and is like a normal
Hi All,
I can see there are two contradicting statements in section "12.4.
Interactions with Preconditions" from "draft-ietf-mmusic-ice-19" :
Statement 1: If ICE changes the transport address where media is
received, this change is reflected in an updated
offer which changes the defaul
Refer to section 8.4 of rfc 3264 for details on media attributes to be set when
placing a call on hold...
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of ext friend
friend
Sent: Monday, July 06
ctor header, if not why so ? 3gpp 24.229 does not mention
of including it.
Thanks,
Sunil
"This email message and any attachments are confidential information of Starent
Networks, Corp. The information transmitted may not be used to create or change
any contractual obligations of St
53 matches
Mail list logo
