On Wed, Jun 30, 2010 at 11:22 AM, Nitin Kapoor wrote:
> Dear All,
>
>
>
> I have the issue where an INVITE initiated dialog, the 200 OK of the PRACK
> is received after at the UAC than the 200 OK of the initial INVITE provided
> that the UAS had sent them in proper order..what should be the behav
formation contained herein in any way (including,
> but not limited to, total or partial disclosure, reproduction, or
> dissemination) by persons other than the intended recipient's) is
> prohibited. If you receive this e-mail in error, please notify the sender by
> phone or email im
On Mon, Jun 28, 2010 at 3:06 AM, Harbhanu wrote:
> Please consider the below mentioned scenario. Here, should session timer be
> restarted/'re-handled' when retransmitted 2xx is received?
>
>
>
> UAC UAS
>
> | |
>
> |INVITE |
>
> |
Yes, as per RFC 3265, Notify request with full state information is
mandatory in response to Subscribe request.
You may see draft draft-ietf-sipcore-subnot-etags-02 An Extension to
Session Initiation Protocol (SIP) Events for Conditional Event
Notification" which makes it optional.
On Fri, Oct 9,
When you subscribe to a resource-list (Non adhoc-list), the
resource-list server is responsible for making individual
subscriptions to the list members. In this case, if you want to
un-subscribe to a particular resource list member, you need to remove
that member using non-SIP means (XCAP). In an t
On Mon, Aug 31, 2009 at 10:47 AM, Yong Xin wrote:
> Hi,
>
> The RFC3261 is clear that UA can not send a re-INVITE when another
> INVITE is pending. However, for non-INVITE request (e.g.: INFO), I was
> not able to find any restriction like this. So I assume this is allowed.
>
> However, sending ano
r offer-less INVITE.
On Mon, Aug 24, 2009 at 8:59 PM, Vikram
Chhibber wrote:
> On Mon, Aug 24, 2009 at 6:44 PM, Avasarala
> Ranjit-A20990 wrote:
>> Hi Vikram
>>
>> Gateway can respond with media capabilities to a offer less INVITE if it is
>> acting as a 3PCC, not otherwis
gt;
> -Original Message-
> From: sip-implementors-boun...@lists.cs.columbia.edu
> [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Vikram
> Chhibber
> Sent: Monday, August 24, 2009 11:35 PM
> To: sunil.bha...@wipro.com
> Cc: s...@ietf.org; s...@core3.
IMO, it is legal to define a static payload type as dynamic too. The
RTP payload type must be 97 for RTP that is being sent out. The SDP
answer might have a changed value of the payload type. For more
details please refer to Section 5.1 of RFC 3264. Here is an excerpt:
For recvonly RTP streams, th
The gateway can respond with different media capabilities in 200 OK
response for offer-less INVITE not for offer
that we view as for hold.
The gateway should create response as per rules defined in RFC 3264.
As far as SIP signalling is concerned, hold INVITE request is treated
as a regular re-INVIT
We can not see the attachment. A UAC should have no problem processing
a unreliable 18x response without Contact as it is optional.
It is definitely needed in a reliable 18x as without it, a UAC can not
construct a PRACK request. In this case, 18x will timeout and the
early dialog will be terminate
"Also" header was proposed long back in some draft that never made up to RFC.
Now, it should me considered as an "Unknown" header and its presence
in SIP message
should not effect anything.
On Tue, Aug 11, 2009 at 9:38 PM, Shadab
Siddiqui wrote:
> Hi,
>
> I wanted to know the behavior of Also head
Please see inline.
On Sat, Jul 25, 2009 at 5:28 AM, Iñaki Baz Castillo wrote:
> El Viernes, 24 de Julio de 2009, Vikram Chhibber escribió:
>> On Fri, Jul 24, 2009 at 5:03 AM, Iñaki Baz Castillo wrote:
>> > Hi, I've realized that XMPP allows publishing different presence st
On Fri, Jul 24, 2009 at 5:03 AM, Iñaki Baz Castillo wrote:
> Hi, I've realized that XMPP allows publishing different presence status for
> different watchers. This is: I could appear as "online" for Alice, "offline"
> for Bob, "Busy" for Carol, "Away" for David...
>
Why do you think this is not po
Yes. This is better. This way Alice can send new subscribe and the
subscription can go into pending state.
On Thu, Jul 16, 2009 at 1:53 AM, Iñaki Baz Castillo wrote:
> 2009/7/16 Iñaki Baz Castillo :
>> 2009/7/16 Vikram Chhibber :
>>> It does not make sense to transaction from
It does not make sense to transaction from active to pending. RFC 3857
also does not show this transaction.
Why not move from active to terminated with reason "rejected"? Alice
UA can show Bob as offline always. Which IMO, is modest approach to
not let Alice know that Bob has rejected her.
The UA c
For instant-messaging, you can use presence status. If the user is offline or
"Appears to be offline", you can direct the MESSAGE or MSRP session
to offline message archive.
On Wed, Jun 17, 2009 at 11:04 AM, Iñaki Baz Castillo wrote:
> El Miércoles, 17 de Junio de 2009, Paul Kyzivat escribió:
>> C
I also wondered the same. May be, they did not like the fact that
"pres-rules" took so much time to become a standard.:)
On Tue, Jun 16, 2009 at 12:49 PM, Iñaki Baz Castillo wrote:
> Hi, I'm starting with XCAP and realized that while IETF defines "pres-rules"
> identifier, OMA has "added" "org.ope
OPTIONS is definitely better as it has no "side-effects". While
creating NOTIFY, you need to specify the Event package say "reg"
event. You can pick one of the standard event packages. But, you run
into risk of "un-predectability" if UA supports un-solicited NOTIFY
requests. In fact, many UA do sup
The RFC is also emphasis not to propagate "stray" 408 response. In
your case, if the proxy has client-transaction, it should terminate it
and propagate the response else it should drop it.
Thus, if the UAS is sending 408 within the duration of NIS, it will be
propagated.
On Thu, Jun 11, 2009 at 9:
The "user=phone" parameter is significant in context of SIP url where
it indicates that the user part of SIP url is telephone number.
Though, it has no meaning in TEL specification, the grammar does
permit it as generic parameter. This implementation should ignore it
if it does not understand.
On
This information can be carried in PIDF by means of XCAP or SIP protocol.
Information that is more of a characteristics of a person as per RFC
4479, large in size and does not change with time is most likely to be
updated and distributed using XCAP mechanism. See also RFC 4483. For
example:
>>The u
t;
> Thanks & Regards,
> Ravi Kumar
>
>
> -Original Message-
> From: Vikram Chhibber [mailto:vikram.chhib...@gmail.com]
> Sent: Thursday, May 07, 2009 4:23 AM
> To: Ravi Kumar
> Cc: sip-implementors@lists.cs.columbia.edu
> Subject: Re: [Sip-implementors] Require h
ably other products which are
> following this), we shall also have to ignore such statements from RFC.
>
> I would appreciate you valuable feedbacks if you have been came across such
> issues.
>
> Best Regards,
> Vivek Batra
>
>
> -Original Message-
> F
using a
new INVITE. There is no limit for imigination:)
On Wed, May 6, 2009 at 5:35 PM, Vikram Chhibber
wrote:
> An example of service using "replacing the early dialog _initiated_ by
> UA" could be a call-collect feature where the receiver does not want
> the originator to be c
May 6, 2009 at 4:06 PM, Iñaki Baz Castillo wrote:
> El Miércoles, 6 de Mayo de 2009, Vikram Chhibber escribió:
>> No. From the RFC 3891, it is clear that you can only replace early
>> dialog which is initiated by the UA.
>> In your scenario, how can you say it is att
Table 3 says:
Requirear- c - c c c
where
c: Conditional; requirements on the header field depend on the
context of the message.
In your case, 421 satisfy this conditional requirement. Thus, the
Require header may be present in respons
On Tue, May 5, 2009 at 9:41 PM, Vivek Batra
wrote:
> Hi Folks,
>
> I have one straight question may be I am not able to read between the words.
>
>
> As per RFC 3891 Section 3:
>
>
>
> If the Replaces header field matches an early dialog that was not
> initiated by this UA, it returns a 481 (Cal
2009/5/6 Vito Korleone :
> Hi to all SIPers,
> I think my question is simple, if A sends an INVITE to a B passing the INVITE
> of course from a proxy or BBUA.. Whatthe proxy should return to A if B
> response is 300 Multiple Choices with 2 Contacts?
The proxy can recurse over 300 response, see se
On Thu, Apr 30, 2009 at 6:16 AM, Sourav Dhar Chaudhuri
wrote:
> hi,
> UAS MUST not send 200OK for PRACK and must ignore the PRACK. UAS .
This is not correct. The UAS should always send some appropriate final
response to end the transaction. In this case, sending final failure
response for PRACK
You may also like to see IMS 3GPP specifications on billing TS 22.115,
TS 32.240, TS 32.260 to get some more idea.
On Mon, Apr 27, 2009 at 7:56 AM, Manish Kambdur
wrote:
> Hi Nabam,
>
> No charging/billing messages are defined by the SIP protocol, which implies
> that the application is respons
It is the UAS who is creating the non-standard answer, in which case,
there is no way the UAC can send 4xx response.
Also, I do see a common codec which are iLBC and telephone-event. The
callee should have used the same dynamic payloads for these codecs as
in offer, but it chose difference ones. In
The discussion was of the presence or absence of type and not length.
Yes, Content-Length has restrication based on transport used.
On Fri, Apr 24, 2009 at 2:08 PM, Dale Worley wrote:
> On Mon, 2009-04-20 at 16:16 -0700, Vikram Chhibber wrote:
>> For the above context, yes, we should b
it the offer, then you need to omit the C-T:
> application/sdp as well as the body itself.
>
> Thanks,
> Paul
>
> Vikram Chhibber wrote:
>>
>> On Mon, Apr 20, 2009 at 3:29 PM, Kevin Spencer
>> wrote:
>>>
>>> Dave,
>>> Thanks
Yes, if UAC supports session timers, it must set Supported header as
"timer", else, the UAS may not perform session-timer related
processing even though Session-Expired header is present.
On Tue, Apr 21, 2009 at 12:57 AM, Krishna Rao Gurram
wrote:
> Hi All,
> I have a query about Su
y type. As such, we must
>> provide for the possibility that for a particular media type, a content
>> of zero bytes has a useful meaning.
>>
>> Dale
>>
>
> On Mon, Apr 20, 2009 at 6:4 PM, Vikram Chhibber
> wrote:
>
>> You will carry Conent-Type with 0 C
Yes, in all these cases, the R-URI should be considered for
identifying the target resource, but I am not sure what the "To
header" is doing in RFC 3842 as pointed out by Brett.
If the Request-URI or To header in a message-summary subscription
corresponds to a group or collection of individu
You will carry Conent-Type with 0 Content-Length when you say "I am
carrying 0 length XYZ Content-Type", which is different then saying "I
am carrying no body with an type". Typical scenario would be INVITE
without offer sdp. You still need to have Conent-Type as
"application/sdp". If you remove Co
http://www.ietf.org/rfc/rfc4916.txt
~Vikram
On Thu, Apr 2, 2009 at 9:48 PM, junpark wrote:
> Hi,
>
> Does anyone knows how to change display information on the calling party
> phone?
>
> This is the scenarios that I'm concerned.
> *Alice calls Bob thru IP PBX.
> The call, however, is routed to
Why not "500 No Sound Resource"?
On Wed, Apr 1, 2009 at 11:02 PM, Dushyant Dhalia
wrote:
> Since there's no sound card in UA2 and if the corresponding session
> requires voice to be one of the media in the session then UA2 is not
> capable of handling this particular call. In such a case either 4
The transferor need not wait the entire day for the 200 OK from the
transfer target. It can very well send CANCEL. But doing so may result
in two race conditions happening that the applicaiton should be
prepared with. The figure 12 and 13 illustrates those scenarios.
"This can result in two rac
Ideally, you should receive one 2xx response and not N. Since your
framework is generic, it should give application to choice of whether
to create subscribe dialog from only one (typically the first notify)
or from all of them.
IMO, creating subscription with a subset of notify request should be
fi
There is no early state if you have not received 1xx with to tag
(excluding 100 trying), therefore IMO PBX behavior is incorrect.
On Mon, Mar 30, 2009 at 8:36 PM, Somesh S. Shanbhag
wrote:
> I think its fine to send the NOTIFY with early state, since the proxy has
> replied with 100 Trying. I am
As per your call flow, it seems that there is some problem with the
Authorization header in the REFER and IMO this issue has nothing to do
with REFER and BYE race-condition. There are many implementations
which send BYE immediately after sending REFER.
You may like to see RFC 5057 on multiple dialo
On Fri, Oct 31, 2008 at 11:05 AM, karthik karthik
<[EMAIL PROTECTED]> wrote:
> Hello All,
>
> Please let me know the behavior for the below cases.
> I believe 'm=' line is not mandatory according to rfc 4566
> Still It was decided to release the session in our application.
>
> case1:
> Invite is re
ion
<[EMAIL PROTECTED]> wrote:
>
>
> Vikram Chhibber schrieb:
>>
>> IMO "pres" uri is meant for presentity/watchers participants for
>> "presence" and related event packages.
>> "sip" scheme is more generic and may include "sip prot
IMO "pres" uri is meant for presentity/watchers participants for
"presence" and related event packages.
"sip" scheme is more generic and may include "sip protocol"
participants including call and "presence".
All these schemes are meant for IP domain. TEL scheme is defined to
accommodate E.164 numbe
You can send provisional response to non-INVITE requests but
understand that this will not stop re-transmissions. It will just set
Timer E to T2. The effect would be that there will be few
re-transmissions. Please refer to section 17.1.2.2 of RFC 3261.
On Thu, Oct 16, 2008 at 10:43 AM, Alex Balash
INFO is more appropriate to send DTMF using "application/dtmf-relay"
content-type. Please note that this is not IANA registered application mime
type though.
For example:
INFO sip:[EMAIL PROTECTED] <[EMAIL PROTECTED]> SIP/2.0
Via: SIP/2.0/UDP 172.80.2.100:5060
From: >;tag=43
To:
>;tag=9753.0207
On Thu, Oct 2, 2008 at 11:09 AM, Harsha. R <[EMAIL PROTECTED]>wrote:
> ... they just refer to the fact that Tables 1 and 2 in rfc3262 extend
> tables 2 and 3 in rfc3261 and the Contact is marked as optional in 1xx
> responses. If 3262 clearly stated that reliable provisional responses
> MUST have
"The OPTIONS request is answered by the server addressed in the request
URI"
Thus, the request-uri in your case needs to be ESC which is the network
element in general. This request-uri should not have user-part else it shall
be targeted to the User Agent.
On Wed, Oct 1, 2008 at 1:21 PM, Franz Edl
; >established SIP dialog say network side call-transfer.
>
> In this case of forced SDP offer, UAS must use the same session id in the
> offer it sends, as it sent in a previous answer(in either 18X response/200
> OK INVITE), and increment the session version by 1.
>
> Regards
Hi All,
I have few queries on RFC 3264: An Offer/Answer Model with the Session
Description Protocol (SDP):
8 Modifying the Session
When issuing an offer that modifies the session,
the "o=" line of the new SDP MUST be identical to that in the
previous SDP, except that the version in
ECTED]> wrote:
> From: "Vikram Chhibber" <[EMAIL PROTECTED]>
>
> Do you think it is worth mentioning about the RFC 4917 on SIP Connected
> Identity as the media-session is re-negotiated in mid-dialog?
>
> (I assume you mean RFC 4916.)
>
> I expe
Thanks Dale, this explains a lot.
Do you think it is worth mentioning about the RFC 4917 on SIP Connected
Identity as the media-session is re-negotiated in mid-dialog?
On Wed, Sep 24, 2008 at 1:07 AM, <[EMAIL PROTECTED]> wrote:
> From: "Vikram Chhibber" <[EMAIL PROTECTED]&
Max-Forwards was not mandatory as per RFC 2543 so the UA should process the
INVITE normally.
On Wed, Sep 24, 2008 at 3:23 PM, Attila Sipos
<[EMAIL PROTECTED]>wrote:
> Step d) Process the INVITE normally.
>
> from RFC3261
> Some existing UAs will not provide a Max-Forwards header field
>
escription ordering.
I will say preserving m line ordering is definitely the reason. Codec number
for dynamic payload can change within same session.
On Tue, Sep 23, 2008 at 1:12 AM, <[EMAIL PROTECTED]> wrote:
> From: "Vikram Chhibber" <[EMAIL PROTECTED]>
>
>
Yes, for this feature to be implemented RFC 3857 is the standard way to go.
On Mon, Sep 22, 2008 at 3:51 AM, Iñaki Baz Castillo <[EMAIL PROTECTED]> wrote:
> El Lunes, 22 de Septiembre de 2008, David Viamonte escribió:
> > You'll find further details at RFC3857 and RFC3858.
> >
> > My understandi
In the call flow that the draft describes, isn't it better to send re-INVITE
without SDP towards the music-store? The reason is that "Alice" UA may send
back codecs previously negotiated with "Bob" whose intersection with
media-source may be 0.
Even though
http://www.ietf.org/internet-drafts/dra
Here is famous Diversion header:
http://www.softarmor.com/wgdb/docs/draft-levy-sip-diversion-08.txt
On Thu, Sep 18, 2008 at 8:31 AM, Manoj Priyankara (NOD)
<[EMAIL PROTECTED]>wrote:
> Hi All,
>
> Can any one tell me the format of the "Diversion" header in the INVITE
> message in the case of forw
If A had an intelligent SIP UA with call-waiting feature, we all would have
been very relaxed. Unfortunately, that is text-book SIP and in real-world we
have dumb IADs interfacing with POTS with minimal SIP intelligence and no
soft-clients running on PC.
The correct way IMO would be to re-negotiate
If you preserve the previous value of o line of your SDP in the re-INVITE,
this indicates that the offer is not intended to change the session
parameters since the SDP version is same. In this case, the UAS should not
go through the processing of SDP ideally and you are free to put whatever
you lik
Please see inline.
On Tue, Sep 9, 2008 at 2:19 PM, Bram Verburg <[EMAIL PROTECTED]> wrote:
> Hi,
>
>
>
> RFC 4038 says a session refresh that uses INVITE should include a copy
> of the most recent SDP offer. The UAS can tell from the o-line that
> nothing has changed and respond with a copy of it
Dushyant, P-CSCF1, S-CSCF2 and P-CSCF2 should also implement session-timers
to remove their hung state. If they do not support session-timers, they are
non-compliant and you really can not do much. This is recommended and widely
used way. There are other ways like audit that you mentioned or using
There could be two types of forwarding. Network initiated and UE initiated.
In the network initiated forwarding, the forwarding number is known to the
network (User some-how configures this). The network, which is ideally a SIP
Application server forwards the call depending on the error response or
408 indicates transaction timeout. You have sent request to next hop
and it has not responded back. If the gateway has not responded at all
(Including 100 trying), 408 is appropriate. 480 is more of application
usage meaning that the user is not available and would be appropriate
if the gateway has
The answer is no. If X is 183, you can not send re-invite to UA as
previous offer-answer is not complete and there is no dialog
established to send re-invite. You can send update on early dialog
instead of re-invite but this will have inter-operation issues and
this also means that 183 needs to be
t; 729 as preference and 711 sets as fall back?
>
> Vikram Chhibber <[EMAIL PROTECTED]> wrote:
>
> This SDP seems to be correct. "rtpmap" is not mandatory for static
> payload types. Payload type 0 belongs in this range and corresponds to
> G.711 uLaw. Similar is the
Also, precedence is given to the first payload-type specified in the m
line which is in this case "18". You may like to see the IANA registry
for static and dynamic payload-types at:
http://www.iana.org/assignments/rtp-parameters
On Tue, May 20, 2008 at 8:58 PM, Vikram Chhibber
<[EM
This SDP seems to be correct. "rtpmap" is not mandatory for static
payload types. Payload type 0 belongs in this range and corresponds to
G.711 uLaw. Similar is the case for payload type 18 but not for 100
which is a dynamic payload type.
On Tue, May 20, 2008 at 8:51 PM, Rashid Shakil <[EMAIL PROT
SCP may be incorrect if it is sending 180 without incrementing RSeq
header. SCP should not "retransmit" if it has received PRACK for
previous response.
On Tue, May 20, 2008 at 3:16 PM, Ganesh Pitchiah S <[EMAIL PROTECTED]> wrote:
> Hi All,
>
> I have a doubt regarding continuous transmitting o
Why to get into the debate of error response when this kind of error
is non-recoverable by the software? A 400 response for REFER (If
possible) with appropriate warning header is sufficient so that people
can diagnose the problem and fix the software.
On Mon, May 19, 2008 at 8:14 PM, KASTURI Naray
On Mon, May 19, 2008 at 3:27 PM, Jitendra Singh Bhadoriya
<[EMAIL PROTECTED]> wrote:
>
>
> Hi,
>
>
>
> In the call-transfer scenario in which A calls B and B sends REFER to A
> to transfer the call to C, but the REFER
>
>
>
> Request contains some invalid URI in the Refer-To header, then in this
>
Also see: http://www.ietf.org/internet-drafts/draft-sparks-sip-invfix-01.txt
On Wed, May 7, 2008 at 3:04 PM, JEEVANANDHAM KARTHIC KUMAR
<[EMAIL PROTECTED]> wrote:
> Hi,
>
> UAS should retransmit 200 OK at the interval of Timer G(initially T1
> then 2*T1) up to the timer H (64*T1).
> Ref RFC 32
Please see. But the draft is about usage of MSRP not FTP.
http://tools.ietf.org/html/draft-ietf-mmusic-file-transfer-mech-07
On Wed, May 7, 2008 at 2:30 PM, <[EMAIL PROTECTED]> wrote:
> Hi,
> I'm searching a way to start an FTP session by using SIP. Which values
> should the SDP fields have in
As a general rule, CANCEL should be send to abort transactions which
are not completed automatically which is INVITE. So you should send
CANCEL fro INVITE. You identity the the matching pending transaction
by using top most via header's branch and cseq. Thus if CANCEL is for
INVITE transaction, it
I think "received" was introduced so that response reach the sip-node
that sent the request. It has nothing to do with NAT as 3261 never
considered and address this problem.
So, if the top most Via contains non-ip sent-by, the UAS is supposed
to replace it with the IP address from where it has rece
"PUBLISH with soft-state has a life time associated with it.". I am
rephrasing this, PUBLISH always has life time associated with the
soft-state it carries.
On Mon, Apr 7, 2008 at 11:33 AM, Vikram Chhibber
<[EMAIL PROTECTED]> wrote:
> Nitin, PUBLISH with soft-state has a life t
Nitin, PUBLISH with soft-state has a life time associated with it. If
Server detects that there is expiration of this duration, it can
assume the user is off-line. The problem is that the Server needs to
wait for the publish expiration to conclude. The server may like to
decrease the refresh rate t
Please see inline.
On Wed, Mar 26, 2008 at 10:02 PM, Attila Sipos
<[EMAIL PROTECTED]> wrote:
>
>
> How does one know what phone-context to use?
>
>
> I have seen examples like this:
> tel:+1-555-987-1234
> tel:1234;phone-context=freescale.com
>
> Is this the same as:
> sip:
Thanks!
On Thu, Mar 20, 2008 at 4:31 PM, Raj Jain <[EMAIL PROTECTED]> wrote:
> RFC 4916 provides a mechanism for doing this. Some existing
> implementations put this in Remote-Party-Id in RE-INVITEs.
>
>
> On Thu, Mar 20, 2008 at 5:35 AM, Vikram Chhibber
>
>
How about sending "application/dialog-info+xml" body in INFO request
to party-A from the B2BUA?
On Thu, Mar 20, 2008 at 3:00 PM, Vikram Chhibber
<[EMAIL PROTECTED]> wrote:
> Consider a B2BUA application that connects party-A with party-B. Now,
> in the mid-way, it puts pa
Consider a B2BUA application that connects party-A with party-B. Now,
in the mid-way, it puts party-B on hold or sends BYE and negotiates
the already established session of A with new party C. There are many
such applications which does this, like network initiated
call-transfer, announcements etc.
If the UAS continues the call, the behavior is implementation
specific. This could lead to one way media or no media at all. It may
happen that UAC sending codec-3 which UAS is not able to understand
and UAS sending previous negotiated codec that UAC may be able to
process. RFC 3264 specifies how
The UAC is defective. Here UAS should terminate the session. It may
re-initiate offer/answer again by sending re-INVITE but this will lead
to same situation again.
There is no point for UAS to continuing the call with previous SDP
because there is no surety that UAC will be doing the same as it has
le? In the later case, as i have mentioned, SIP already has
procedures.
On Wed, Mar 12, 2008 at 1:54 PM, Raj Jain <[EMAIL PROTECTED]> wrote:
> On Wed, Mar 12, 2008 at 2:11 AM, Vikram Chhibber
> <[EMAIL PROTECTED]> wrote:
> > I am not very sure of the need for this as in my opi
Please see inline.
On Tue, Mar 11, 2008 at 6:09 PM, Naveen Kumashi
<[EMAIL PROTECTED]> wrote:
> Hello everybody...
>
>
>
> I am trying to build presence service into my java soft phone presently,
> using asterisk server...
>
>
>
> When I am sending a SUBSCRIBE message immediately after a REGIST
Since UAC can not send failure response, the best UAC can do is
terminate the INVITE transaction by sending CANCEL.
On Tue, Mar 11, 2008 at 5:08 PM, sarthakd <[EMAIL PROTECTED]> wrote:
> Hi all,
>
>Here is a simple scenario.
>
>I send INVITE without setting supported header field a
There are many such headers like: P-Preferred-Identity,
P-Associated-Uri, P-Asserted-Identity, Proxy-Authenticate,
History-Info, Supported, Require, all variations of Accept. Even, all
the Via headers can be queried by proxy for loop detection.
In my opinion, if you are planning to write some parse
I am not very sure of the need for this as in my opinion SIP already
has ways to achieve this. If the gateway sends say 503, the proxy can
try another gateway. The gateway can itself redirect to the new
gateway by sending 302 response.
The proxy can get multiple gateway addresses by some proprietar
Normally, remote media is always given more preference than local
ring-back. But, there are no best practices draft/specifications on
this as far as I know.
On Thu, Feb 28, 2008 at 10:18 AM, Madhav Bhamidipati <[EMAIL PROTECTED]> wrote:
> I think, 18X with an early media needs to be given preferen
"> There will always be a response to SEND request, irrespective of value
> of Failure-Report header."
Sanjay, I am not sure about this statement. Failure-Report: partial
implies that the sender of MSRP SEND request is not interested in
successful acknowledgment (200 OK), but it wants reporting of
I assume here that the posting is for a page-mode IM. INFO is sent
over an dialog which in this case is missing. You make like to have
MSRP session with the IM archiver application if the user is not
available and then send INFO on that session.
On Feb 4, 2008 6:41 PM, KASTURI Narayanan (kasnaray)
al Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On
> > Behalf Of Iñaki Baz Castillo
> > Sent: Monday, February 04, 2008 8:16 AM
> > To: sip-implementors@lists.cs.columbia.edu
> > Subject: Re: [Sip-implementors] Response code when MESSAGE is
I don't think there is any RFC recommendation for this behavior. The
best you can assume that the UE understands MESSAGE. In this case,
sending back non 2xx final response in most cases would be interpreted
as failure for MESSAGE. In my opinion 202 Accepted is the best
response with Warning header
Isn't it 300 response more appropriate for multiple contacts? Ideally,
UA should try sequentially on these multiple contacts.
On Jan 31, 2008 12:22 PM, geeta soragavi <[EMAIL PROTECTED]> wrote:
> Hi,
>
> What must be the behaviour of UA if it receives 302
> response with multiple contacts.Should
Please read section 17 of RFC 3261. UPDATE transaction behavior comes
under non-INVITE client and server transaction description.
On Jan 31, 2008 11:50 AM, Jagan Mohan <[EMAIL PROTECTED]> wrote:
> Hi All,
>
>I would like to know for much time should a UA wait for a 2xx response to
> UPDATE mes
On Dec 11, 2007 12:42 PM, Brett Tate <[EMAIL PROTECTED]> wrote:
> > Please confirm my understanding of subscribe for MWI. NOTIFY
> > should not be sent to a UA unless a SUBSCRIBE has been sent to it.
>
> RFC3265 allows for non-SUBSCRIBE mechanisms to create subscriptions.
> Some vendors use the co
This is non-standard unsolicited NOTIFY. You may accepts it for
"message-summary" Event as many Voice Mail Servers are sending this
unsolicited NOTIFY request.
~Vikram
www.veraznetworks.com
On Dec 11, 2007 10:39 AM, Jack W. Lix <[EMAIL PROTECTED]> wrote:
> Hi all,
>
>
>
> Please confirm my unders
From: [EMAIL PROTECTED] [mailto:sip-
> > [EMAIL PROTECTED] On Behalf Of Vikram
> Chhibber
> > Sent: Wednesday, December 05, 2007 11:34 PM
> > To: sip-implementors@lists.cs.columbia.edu
> > Subject: [Sip-implementors] bandwidth attribute in SDP
> >
> > Hi Al
1 - 100 of 146 matches
Mail list logo
