CSEQ space is different at subscriber and notifier
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Tim Hynes
Sent: Tuesday, June 05, 2007 4:42 PM
To: sip-implementors@cs.columbia.edu
Subject: [Sip-implementors] Are separate CSEQ headers
maintained by
This is addressed in RFC 4320, which also suggests normative updates to RFC
3261.
I did not understand the question about Cancel for non-Invite transaction, is
that allowed or useful?
Sanjay
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Christer
Pl. see section 18.2.2 of RFC 3261 about how to send response if there
is maddr param in Via
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Yong Xin
Sent: Thursday, May 31, 2007 3:43 PM
To: Sip-implementors@cs.columbia.edu
Subject: [Sip-implementors]
I think it will send 200 OK to CANCEL first, to let UAC know that it has
received it, and then act on Cancel request and send 487 for Invite.
Sanjay
PS: I moved this to sip-implementors, where it's more appropriate.
-Original Message-
From: Stephen McVarnock [mailto:[EMAIL PROTECTED]
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Monday, May 14, 2007 11:37 AM
To: sip-implementors@cs.columbia.edu
Subject: Re: [Sip-implementors] maximum UDP message size
From: Hagai Sela (TA) [EMAIL PROTECTED]
Doesn't
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Suganya D
Sent: Wednesday, May 09, 2007 3:02 AM
To: Sip-implementors@cs.columbia.edu
Cc: [EMAIL PROTECTED]
Subject: [Sip-implementors] Requesting For Session Timer in
2xx response
Hi,
RFC 4028 says
The
That's true for ACK for a 200 response, not for an error response. In
that case, ACK must be sent to the same address, port, and transport to
which the original request was sent. Pl. see rfc 3261, sec. 17.1.1.2.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
ACK must have same Proxy-Auth header as INVITE to which it corresponds.
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of David
Viamonte
Sent: Tuesday, May 08, 2007 12:14 PM
To: Sip-implementors@cs.columbia.edu
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Attila Sipos
Sent: Tuesday, May 01, 2007 4:28 AM
To: chozhan A; [EMAIL PROTECTED]; sip
implementors
Subject: Re: [Sip-implementors] RFC 2543: INVITE vs re-INVITE
I have a different question.
An RFC
Can't you do that using subscription to conference event package, rfc
4575?
Sanjay
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Cesc
Sent: Wednesday, April 25, 2007 6:39 AM
To: Sip-Implementors
Subject: [Sip-implementors] presence state for
There is a codemonicon test suite.
From: Baniel Uri-CUB001 [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 05, 2007 12:24 PM
To: Sip-implementors@cs.columbia.edu; sip@ietf.org
Subject: [Sip] Test suite for security threats
Prack is like any other request, so UAC has to increment Cseq. So UAS
should reject the request with a 500 error response
Sanjay
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Darshan Bildikar
Sent: Monday, April 02, 2007 8:35 AM
To:
A sip request must have only one To header. For your implementation, you
may want to have a proxy fork the request to multiple destination based
on those destinations registering with the proxy/registrar.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
If the response is 408, then there is some kind of transport error at
either UA. In that case, some kind of response to terminate Invite
dialog (like 487) will also be probably not delivered to the UAC. So in
this case, IMO, the UAS should silently terminate the dialog.
481 response could mean
I think UA should send a BYE even if a re-Invite is pending.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Nina Garaca
Sent: Tuesday, March 27, 2007 9:50 AM
To: sip-implementors@cs.columbia.edu
Subject: [Sip-implementors] BYE after reINVITE
Hi,
I
I think it is correct.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tang Xi
Sent: Thursday, March 22, 2007 6:34 AM
To: sip-implementors
Subject: [Sip-implementors] About Refer duration
Hi All, here is one question about Refer duration.
1) UAC sends
It can, if early dialog is established. Early dialog is considered
established if 18X with to-tag is sent reliably.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Wednesday, March 21, 2007 11:21 AM
To:
Pl. look at draft-rosenberg-sip-ua-loose-route-00.txt, it is no longer
prohibited in Register also.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Brett Tate
Sent: Wednesday, February 28, 2007 2:21 PM
To: sip-implementors@cs.columbia.edu
Subject:
http://tools.ietf.org/wg/sip/draft-niemi-sip-subnot-etags-02.txt
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Vikram Chhibber
Sent: Tuesday, February 20, 2007 2:18 AM
To: Sip-Implementors
Subject: [Sip-implementors] Distinguishing SUBSCRIBE refresh
: Paul Kyzivat (pkyzivat)
Sent: Tuesday, February 20, 2007 1:36 PM
To: Attila Sipos
Cc: Christer Holmberg (JO/LMF); Sweeney, Andrew (Andrew); Ira
Kadin; Sanjay Sinha (sanjsinh); Miljanovic, Nebojsa (Neb);
sip-implementors@cs.columbia.edu
Subject: Re: [Sip-implementors] SDP in 2xx response after
If the operation fails, then have the proxy not add Record-Route header,
that way proxy will not see subsequent requests on that dialog
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
raghuram gangi
Sent: Thursday, February 15, 2007 9:22 AM
To:
Yeah my bad, that is correct. Proxy could have added itself in RR during
initial Invite itself.
-Original Message-
From: Paul Kyzivat (pkyzivat)
Sent: Thursday, February 15, 2007 11:28 AM
To: Sanjay Sinha (sanjsinh)
Cc: raghuram gangi; sip-implementors@cs.columbia.edu
Subject: Re: [Sip
Transport in Via header represents the transport using which the UA sent
REGISTER to the server and the server should use same transport for
sending response to REGISTER.
The transport in Contact header of Register will be used by server to
send any incoming requests to that UA
Sanjay
Option 2 does not seem correct. Option 1 is correct and you may also
want to ignore the sdp in 200 OK, just treat it as if there was no sdp
in 200 OK.
Sanjay
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Nebojsa Miljanovic
Sent: Wednesday, February
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Tuesday, February 06, 2007 11:14 AM
To: Sanjay Sinha (sanjsinh)
Cc: sip-implementors@cs.columbia.edu;
[EMAIL PROTECTED]
Subject: Re: [Sip-implementors] TCP question - Proper way to
Construct ContactURIs
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Manpreet Singh
Sent: Thursday, February 01, 2007 8:45 PM
To: Paul Kyzivat (pkyzivat)
Cc: [EMAIL PROTECTED]; sip-implementors@cs.columbia.edu
Subject: Re: [Sip-implementors] CSeq Number implementation
Paul
Port number will be valid in Contact header also, in addition to
Record-Route/Route header(s).
Sanjay
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Rick Whitesel (rwhitese)
Sent: Tuesday, January 30, 2007 5:07 PM
To: sip-implementors@cs.columbia.edu
to receive NOTIFY requests etc.
Sanjay
-Original Message-
From: Rick Whitesel (rwhitese)
Sent: Tuesday, January 30, 2007 7:37 PM
To: Sanjay Sinha (sanjsinh); 'sip-implementors@cs.columbia.edu'
Subject: RE: [Sip-implementors] SIPS/TLS and port numbers
Hi Sanjay:
Are the port numbers
You can not send a CANCEL to cancel REFER. You can send another REFER
with method CANCEL/BYE in Refer-To header to terminate the dialog
created as a result of initial REFER. That also needs you to know the
dialog identifiers of that dialog that you want to cancel or bye. You
can get that by
RFC 3261 mentions that From/To headers, without the tag, can be changed
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Wednesday, December 13, 2006 8:57 AM
To: sip-implementors@cs.columbia.edu
Subject: [Sip-implementors]
Inline
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Attila Sipos
Sent: Wednesday, December 13, 2006 3:56 PM
To: sip-implementors@cs.columbia.edu
Subject: [Sip-implementors] 2 questions on 3xx response
Q1. say you send an INVITE and you get a
Standard way of putting call on hold is to mark media attributes as
sendonly or inactive. C=0.0.0.0 should also work for implementations
which are backward compatible with this way of putting call on hold.
Setting port number in m line to 0 is not advisable since this is
offer-answer model's way
This is similar to setting up a huntgroup or dns cycling, where the UAC
will try subsequent hosts if request to initial host fails. You need to
define policies for the huntgroup, like it will round-robin to the next
member in huntgroup if error response is like 503, 408 .., but will not
cycle
I do not think it is possible to indicate support for G729A G729B in
same offer. G729B and G729AB are fully interoperable.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
sudhagar NAGARAJAN
Sent: Wednesday, November 15, 2006 4:01 AM
To:
What I do not understand is how do you know the ephemeral source port
number when creating the message? If idea is to reuse the existing
connection for responses/further requests from other UA,
connection-reuse draft provides solution
-Original Message-
From: [EMAIL PROTECTED]
I think registrar should create a separate binding when user register
with a different ip address/port combination.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Prasad, Santosh
Sent: Tuesday, November 07, 2006 12:12 PM
To:
-Original Message-
From: Prasad, Santosh [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 07, 2006 1:55 PM
To: Sanjay Sinha (sanjsinh)
Cc: sip-implementors@cs.columbia.edu
Subject: RE: [Sip-implementors] Adding Bindings rfc3261 sec10.2.1
Sanjay,
Thanks for your quick response. I
07, 2006 2:19 PM
To: Sanjay Sinha (sanjsinh); Prasad, Santosh;
sip-implementors@cs.columbia.edu
Subject: RE: [Sip-implementors] Adding Bindings rfc3261 sec10.2.1
How about if somebody moves a SIP phone from one location to
the other and connected to the network.
SIP Phone is going to send new
It may be different because of forwarding operation.
Sanjay
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Manish Jain
Sent: Saturday, November 04, 2006 3:09 AM
To: sip-implementors@cs.columbia.edu
Subject: [Sip-implementors] Different user name in
It might be useful for QoS cases.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Sarkar, Uttam
Sent: Tuesday, October 31, 2006 11:28 AM
To: [EMAIL PROTECTED]; sip-implementors@cs.columbia.edu
Subject: Re: [Sip-implementors] Query 100rel in re-INVITE
I think RFC 3312 has some examples where 18x is needed for preconditions
in a mid-call session.
Sanjay.
-Original Message-
From: Sarkar, Uttam [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 31, 2006 2:05 PM
To: Sanjay Sinha (sanjsinh); [EMAIL PROTECTED];
sip-implementors
-Original Message-
From: Sarkar, Uttam [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 31, 2006 3:17 PM
To: Sanjay Sinha (sanjsinh); [EMAIL PROTECTED];
sip-implementors@cs.columbia.edu
Subject: RE: [Sip-implementors] Query 100rel in re-INVITE
I see UPDATE is used before sending 200
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Marco Ambu
Sent: Friday, October 20, 2006 5:44 AM
To: SIP-implementors mailing list
Subject: [Sip-implementors] Calculation of subscription
duration - updated
Hi,
I have read may times the thread
400 error response
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Vivek Gupta
Sent: Wednesday, October 18, 2006 9:06 PM
To: Sip-implementors@cs.columbia.edu
Subject: [Sip-implementors] Bheavior when any of the mandatory
header ismissing
Hi,
What
Same uri as in Invite. Here is text from RFC 3261:
UACs creating an ACK message will duplicate all of the Authorization and
Proxy-Authorization header field values that appeared in the INVITE to
which the ACK corresponds.
Sanjay
-Original Message-
From: [EMAIL PROTECTED]
There is no need for 2 sip sessions, one sip dialog can have two media
lines, one corresponding to audio and another for video.
Sanjay
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Rick Whitesel (rwhitese)
Sent: Wednesday, October 04, 2006 1:21 PM
RFC 3312
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Cesc
Sent: Monday, October 02, 2006 5:25 PM
To: Sip-Implementors
Subject: [Sip-implementors] sip and rsvp
Hi,
Can you point me to theoretical info, draft/rfc or
implementation possibilites
According to RFC 3261, both UDP and TCP must be supported
Sanjay
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Man-Chi Leung
Sent: Tuesday, October 03, 2006 8:35 AM
To: sip-implementors@cs.columbia.edu
Subject: [Sip-implementors] compare UDP and TCP
that if request is more than 1300
bytes, then it must be sent using TCP
Sanjay
-Original Message-
From: Alf Salte [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 03, 2006 11:10 AM
To: Sanjay Sinha (sanjsinh)
Cc: Man-Chi Leung; sip-implementors@cs.columbia.edu
Subject: Re: [Sip-implementors
You may want to look at draft-mahy-sip-remote-cc-03 for call control of
UA which use cti applications. What are the things that call flow using
REFER does not cover?
Sanjay
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Walton,
Ashley B (Ashley)
Sent:
This draft has expired and an updated version is not available. Standard
way of doing this is History-Info
Sanjay
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Thursday, September 28, 2006 10:49 AM
To:
Hi Paul,
Pl. see inline ...
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Paul Kyzivat (pkyzivat)
Sent: Thursday, September 28, 2006 11:45 AM
To: [EMAIL PROTECTED]
Cc: sip-implementors@cs.columbia.edu
Subject: Re: [Sip-implementors] Calculation of
Record-Route header is used to send subsequent requests after dialog is
established. If Invite is rejected with an error response, there is no
dialog and no need for RR header in error response. You can refer to
Table 3 in RFC 3261
-Original Message-
From: [EMAIL PROTECTED]
Sec. 2 of RFC 3892 says that Referred-By host is referrer's
address-of-record.
Sanjay
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Thursday, August 17, 2006 2:15 PM
To: sip-implementors@cs.columbia.edu
Subject:
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Paul
Kyzivat (pkyzivat)
Sent: Friday, August 11, 2006 12:18 PM
To: [EMAIL PROTECTED]
Cc: sip-implementors@cs.columbia.edu
Subject: Re: [Sip-implementors] Incrementation of Cseq inside dialogs
[EMAIL
This draft is RFC 3263.
Also I think the client would try other hosts for error responses unless
error response indicates a global failure, like 6XX.
Sanjay
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Manpreet
Singh
Sent: Friday, August 04, 2006 4:57
What RFC 3515 says is that only REFER can create *initial* subscription
for Event: refer and SUBSCRIBE can not be used for that. Once REFER/20X
initial NOTIFY transaction is complete, Referor can send SUBSCRIBE with
same dialog identifiers with Event: refer to extend or delete that
subscription.
57 matches
Mail list logo
