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: sip-
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 and
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: [Sip-imple
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 it
If offer is in 183 and Prack is enabled, then yes answer sdp must be in
Prack.
>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
>Sent: Wednesday, April 02, 2008 7:59 AM
>To: Sanjay Sinha (sanjsinh)
>Cc: Nithin N; sip-implementors@lists.cs.columbia.e
200 OK to the Prack and then terminate the Invite with 488.
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] On
>Behalf Of Nithin N
>Sent: Wednesday, April 02, 2008 7:24 AM
>To: sip-implementors@lists.cs.columbia.edu
>Subject: [Sip-implementors] Offer/Answer Violat
There are security concerns with tcp connection reuse, pl. look at sec.
9.3 of the draft
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] On
>Behalf Of Ivar Lumi
>Sent: Saturday, February 16, 2008 6:21 AM
>To: sip-implementors@lists.cs.columbia.edu
>Subject: [Sip
How about 480, Temporarily Unavailable, with the Warning header.
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] On
>Behalf Of KASTURI Narayanan (kasnaray)
>Sent: Monday, February 04, 2008 9:20 AM
>To: Iñaki Baz Castillo; sip-implementors@lists.cs.columbia.edu
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: [Si
There is no real meaning to transport parameter in From or To header. So
UAS should just ignore it. Rejecting request based on it, does not seem
correct.
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] On
>Behalf Of Stephen Paterson
>Sent: Wednesday, January 16,
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
t
Inline ..
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] On
>Behalf Of Jitendra Singh Bhadoriya
>Sent: Tuesday, January 08, 2008 5:48 AM
>To: sip-implementors@lists.cs.columbia.edu
>Subject: [Sip-implementors] Authorization and
>Proxy-Authorization in thesame r
>-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 me
Yeah your call flow is not readable in this mail reader.
But you should refer to last paragraph of section 3 of RFC 3262 for
behavior of UAS about sending final response to Invite when Prack is
still pending.
Sanjay
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED]
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: Sip-
Mmusic working group in ietf
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] On
>Behalf Of Richard Wu
>Sent: Thursday, December 06, 2007 2:26 AM
>To: sip-implementors@lists.cs.columbia.edu
>Subject: [Sip-implementors] Any newsgroup about RTP/RTCP
>
>Hi All,
> I
:[EMAIL PROTECTED]
Sent: Wednesday, December 05, 2007 6:23 PM
To: Sanjay Sinha (sanjsinh);
Cc: Paul Kyzivat (pkyzivat);
sip-implementors@lists.cs.columbia.edu
Subject: Re: RE: Re: [Sip-implementors] To and Request-URI
Thank you so much for
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
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-implemen
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-U
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
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 rega
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
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
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 PROTECTE
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
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 i
I think Re-Subscribe here means installing a new subscription with new
identifiers, that is new Call-ID and tags.
Sanjay
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] On
>Behalf Of Vinay
>Sent: Wednesday, October 31, 2007 9:30 AM
>To: 'Rishin Chakraborty'
>Cc:
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 Eric
>-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
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] On
>Behalf Of [EMAIL PROTECTED]
>Sent: Friday, August 17, 2007 12:52 PM
>To: Paul Kyzivat (pkyzivat)
>Cc: sip-implementors@lists.cs.columbia.edu; Brett Tate
>Subject: Re: [Sip-implementors] SDP in unreliable 183 and
The proxy should simply forward the request to it's target destination.
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] On
>Behalf Of Arif
>Sent: Wednesday, August 15, 2007 8:03 AM
>To: sip-implementors@lists.cs.columbia.edu
>Subject: [Sip-implementors] ESCAPED H
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
Successful final response or Notify creates the dialog
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] On
>Behalf Of Anshuman S. Rawat
>Sent: Monday, July 30, 2007 8:10 AM
>To: sip-implementors@lists.cs.columbia.edu
>Subject: [Sip-implementors] Non-subscribe mech
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
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 w
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: [Sip
Yes and then look for the expires parameter in initial Notify and adjust
the timer accordingly
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] On
>Behalf Of Shankarachar Subramanya-a22587
>Sent: Wednesday, July 25, 2007 1:08 PM
>To: sip-implementors@lists.cs.colu
Inline ...
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] On
>Behalf Of varun
>Sent: Tuesday, July 24, 2007 1:46 PM
>To: sip-implementors@lists.cs.columbia.edu
>Subject: [Sip-implementors] Expires header in INVITE
>
>Hi,
>The expires header field specifies the t
Inline pls...
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] On
>Behalf Of Robert Sparks
>Sent: Wednesday, July 18, 2007 10:18 AM
>To: Jacob Fritz-A17682; Paul Kyzivat (pkyzivat)
>Cc: sip-implementors@lists.cs.columbia.edu
>Subject: Re: [Sip-implementors] pre con
UAC will use previous nonce to calculate auth response for re-register.
If nonce has expired at the registrar and is not valid, registrar will
send another challenge for the request using new nonce and set stale
parameter to true.
Sanjay
>-Original Message-
>From: [EMAIL PROTECTED]
>[mai
47 matches
Mail list logo
