Notification required because of subscription refresh
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On
Behalf Of Alex Balashov
Sent: Tuesday, January 20, 2009 4:53 PM
To: Iñaki Baz Castillo
Cc:
I do not think Paragraph 3 conflicts paragraph 2. Both are saying same
thing about route set, in that, it needs to be recomputed when 2xx is
received, because, as you also point out, rfc 2543 did not mandate
echoing RR headers in 1xx responses.
Paragraph 3 is about updating other dialog states
RFC 3581 implies that these two are for UDP, though not explicitly called out.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Iñaki Baz Castillo
Sent: Wednesday, July 23, 2008 5:11 PM
To: sip-implementors@lists.cs.columbia.edu
Subject:
In the Boss-Secretary example below, the UAS should not return 6xx if the user
(ie Boss) rejects the call, that seems more appropriate for a client error,
4xx. 6xx kind of error would seem appropriate if the system know that the
called user (Boss in this case) does not exist in the system. So
Isn't there another case where in-dialog request may be authenticated:
Sender of the request was authenticated during initial dialog setup and
the next in-dialog request has the Authorization header, but the nonce
has expired at the authenticating server/proxy and so it generates
another nonce and
If UAS rejects re-Invite with 488, the original call, with PCMU codec,
will stay up.
Sanjay
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Harsha. R
Sent: Tuesday, January 22, 2008 10:03 AM
To: sip-implementors@lists.cs.columbia.edu
Subject:
I agree with Scott.
Since the contacts are pre-configured on the registrar, when the key
telephone system comes up, use whatever mechanism fits you to kind of
enable those pre-configured routes on the registrar. It could be the
telephone system creating a tcp connection to the registrar, that is
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Brett Tate
Sent: Monday, January 07, 2008 1:24 PM
To: NC Reddy; Sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] Query: Can UAS generate
different messagebodytypes in 18x messages
UAC will ACK the 200 OK and then send BYE.
But why would the answer be not acceptable? It is a subset of the offer
from UAC.
Sanjay
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Arnab Biswas
Sent: Wednesday, December 19, 2007 10:46 AM
To:
Request-uri number
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of SungWoo Lee
Sent: Tuesday, December 04, 2007 12:04 AM
To: Sanjay Sinha (sanjsinh)
Cc: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] To and Request-URI
What
From: SungWoo Lee [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 04, 2007 7:26 PM
To: Paul Kyzivat (pkyzivat)
Cc: Sanjay Sinha (sanjsinh);
sip-implementors@lists.cs.columbia.edu
Subject: Re: Re: [Sip-implementors] To and Request-URI
Pl. look at RFC 5057
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of johnny kao
Sent: Tuesday, November 20, 2007 8:07 PM
To: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] SUBSCRIBE and REFER within
INVITE dialog
Hi,
I'm
Number on request-uri should be used to route the Invite request/.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of ???
Sent: Monday, December 03, 2007 7:15 PM
To: sip-implementors@lists.cs.columbia.edu
Subject: [Sip-implementors] To and Request-URI
There will always be a response to SEND request, irrespective of value
of Failure-Report header.
Sanjay
From: Vikas Jayaprakash [mailto:[EMAIL PROTECTED]
Sent: Friday, November 30, 2007 12:53 AM
To: Sanjay Sinha (sanjsinh)
Cc
If the Failure-Report header has a value of no, then the relay should
forward SEND request to next hop and send the final response from it
upstream.
Failure-Report header with value partial is treated similar to yes
in case of error with SEND, ie a REPORT upstream with the error.
Sanjay
Inline
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of vinodh kumar
Sent: Tuesday, November 27, 2007 10:33 AM
To: sip-implementors@lists.cs.columbia.edu
Subject: [Sip-implementors] Blind transfer using REFER
Hi all,
I have query regarding blind
Notify will be sent using the route established by Subscribe.
Binding created in the registrar will be used to route incoming dialog
creating requests to the UA that registered with the proxy.
Sanjay
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of
Yes
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of sumanth achar
Sent: Monday, November 19, 2007 8:33 AM
To: sip-implementors@lists.cs.columbia.edu
Subject: [Sip-implementors] Directionality Attribute in UPDATE Request
Hi,
is it possible to put
To put call on hold, the direction attribute will say a=sendonly and
local mic is muted. When you want to take call off hold, the direction
attrib will change to a=sendrecv.
I do not understand your statement about using c=0.0.0.0 in sdp.
Sanjay
-Original Message-
From: [EMAIL
Proxy can not detect rings, so it is not based on number of rings but is
timing based. So for example, cfwd to next destination after 2 mins if
call does not transition to active state.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of virendra nahar
First of all, I think a proxy is a strict or loose router, not a client.
Also the uri in Authorization header will be the request-uri.
Sanjay
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Klaus Darilion
Sent: Friday, November 16, 2007 3:59 AM
To:
You can probably use the blackhole sdp mechanism for offer-answer
exchange in SDP and setup the Invite dialog. But as Paul mentioned
earlier, there will be no interoperability with other implementations.
Sanjay
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Why do you want to this instead of using MESSAGE for pager mode only,
for which it was meant for?
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Vikram Chhibber
Sent: Wednesday, November 14, 2007 9:15 AM
To: sip-implementors@lists.cs.columbia.edu
Inline ...
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Attila Sipos
Sent: Thursday, November 01, 2007 6:34 AM
To: Brocha Strous; sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] 180 with body AFTER 183 with
body - is itvalid
I do not think there is a standard way to handle voicemail, since as you
note, there are so many ways. But redirecting call to a voicemail using
3xx response would be the most common way.
Sanjay
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Erich
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Dmitry Akindinov
You seem to forget that there may be provisional responses
from different sources (a request forked to several
endpoints.)
Response from different sources will have different to-tags
This can probably happen during Subscribe refresh.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Sumit Chopra
Sent: Wednesday, August 01, 2007 8:03 AM
To: sip-implementors@lists.cs.columbia.edu
Subject: [Sip-implementors] Can NOTIFY with state
Inline ...
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 26, 2007 12:04 AM
To: Sanjay Sinha (sanjsinh)
Cc: Jeroen van Bemmel; sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] B2BUA Problem when processing 401/407
Sanjay
I think the RFC is pretty clear on what the behavior should be. Here is
the quote from sec. 22.2:
When a UAC resubmits a request with its credentials after receiving a
401 (Unauthorized) or 407 (Proxy Authentication Required) response,
it MUST increment the CSeq header field value as it
I think the UAC should try the transports in the order in which it was
received in dns reply.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Tao Yang
Sent: Wednesday, July 25, 2007 6:12 AM
To: sip-implementors@lists.cs.columbia.edu
Subject:
30 matches
Mail list logo
