-
From: Attila Sipos [mailto:attila.si...@vegastream.com]
Sent: Friday, April 03, 2009 5:28 PM
To: Somesh S. Shanbhag; sip-implementors@lists.cs.columbia.edu
Subject: RE: [Sip-implementors] 200 OK response to REFER
I'm not sure I understand your response.
Maybe I could ask my question in anothe
200 OK of REFER *must* be interpreted as receiving 200 OK because,
fundamentally both mean REFER is successful as it is successful final
response.
Somesh
* Please donot take the print out of this e-mail unless its absolutely
necessary *
-Original Message-
From: sip-implementors-boun...
Fundamental thing is PBX must be able to decode the PCMA as well because
its fair to switch between the negotiated codecs of both the parties.
Since, PBX already knows that X-Lite can send PCMA any point of time, it
*must* be prepared to receive it as well.
Thanks,
Somesh
* Please donot take the
Try Asterisk. It supports presence package.
Somesh
* Please donot take the print out of this e-mail unless its absolutely
necessary *
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of
Pankaj Munj
I think its fine to send the NOTIFY with early state, since the proxy has
replied with 100 Trying. I am assuming that when 480 is received, it will again
NOTIFY about the termination status.
Somesh
* Please donot take the print out of this e-mail unless its absolutely
necessary *
-Origin
You can have look at http://tech-invite.com/Ti-sip-service-4.html
Somesh
* Please do not take print out of this e-mail unless its absolutely necessary *
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu on behalf of Manoj
Priyankara [TG]
Sent: Mon 3/23/2009 1:11
Oops! I used REGISTER in the place of registrar :)
Somesh
* Please do not take print out of this e-mail unless its absolutely necessary *
-Original Message-
From: Somesh S. Shanbhag
Sent: Wed 3/18/2009 11:40 AM
To: Avasarala Ranjit-A20990; Rastogi, Vipul (Vipul);
sip-implementors
take print out of this e-mail unless its absolutely necessary *
-Original Message-
From: Avasarala Ranjit-A20990 [mailto:ran...@motorola.com]
Sent: Wed 3/18/2009 11:32 AM
To: Somesh S. Shanbhag; Rastogi, Vipul (Vipul);
sip-implementors@lists.cs.columbia.edu
Subject: RE: [Sip-implementors
It will be good to send 200 OK for that REGISTER.
Somesh
* Please do not take print out of this e-mail unless its absolutely necessary *
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu on behalf of Rastogi,
Vipul (Vipul)
Sent: Wed 3/18/2009 11:15 AM
To: sip-im
> There is no SIP PBX/gateway/proxy sending a 503 with "Retry-After"
> (this is a "magic" IETF solution that cannot work in real world where
> a host *doesn't* know how long it will be unavaliable).
> So I expect a more robust behaviours in clients. I think all the
> clients supporting RFC 3263 fai
> If a client receives a 503 with NO "Retry-After" should it try an
> alterante server (RFC 3263, SRV and so...)?
> Or should it "act as if it had received a 500 (Server Internal Error)
> response"? (note that error 500 says nothing aboyt failover).
> However, RFC 3263 just mentions 503 for SIP fa
Yeah thats correct. The A query gives you final IP address.
Somesh
* Please do not take print out of this e-mail unless its absolutely necessary *
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu on behalf of sarvpriya
Sent: Thu 3/12/2009 3:10 PM
To: sip-implem
Yes, its valid one. Simply because the caller wants to open up two audio
streams, received at
different audio ports. As callee I think we need to take the two streams
separately and answer them.
Somesh
* Please do not take print out of this e-mail unless its absolutely necessary *
-Orig
Thats with *Allow* header. According to RFC 3261,
20.5 Allow
The Allow header field lists the set of methods supported by the UA
generating the message.
All methods, including ACK and CANCEL, understood by the UA MUST be
included in the list of methods in the Allow header field, when
According to RFC 3261 you can generate 405 if you cannot support the method.
8.2.1 Method Inspection
Once a request is authenticated (or authentication is skipped), the
UAS MUST inspect the method of the request. If the UAS recognizes
but does not support the method of a request, it MUS
same value of the branch
parameter.
Somesh
* Please do not take print out of this e-mail unless its absolutely necessary *
-Original Message-
From: Attila Sipos [mailto:attila.si...@vegastream.com]
Sent: Mon 3/2/2009 2:15 PM
To: Somesh S. Shanbhag; priyank luthra; sip
necessary *
-Original Message-
From: priyank luthra [mailto:priyank.lut...@gmail.com]
Sent: Mon 3/2/2009 2:03 PM
To: Somesh S. Shanbhag
Cc: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] Why ACK is not part of the INVITE
transactionfor 2xx reponse, but is part of transaction f
CSeq method is used to identify the transaction along with branch, when a CANCEL
request is processed.
Somesh
* Please do not take print out of this e-mail unless its absolutely necessary *
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu on behalf of Attila Si
ACK is generated by the TU in case of 2xx is received and directly passed onto
transport layer for sending. In the case of receiving non-2xx final responses,
the
ACK is generated by the transaction layer itself so, its part of the same
transaction.
In case of 2xx final responses, ACK can be he
Ideally 400 Bad Request *should* be sent because it in-validates ABNF of SIP.
But if registrar honors the expiration somehow, it can reply with 3600 back in
200 OK.
Somesh
* Please do not take print out of this e-mail unless its absolutely necessary *
-Original Message-
From: sip-imp
MESSAGE should follow the same rules as for any other non-INVITE in-Dialog
messages.
And the interpretation is left to the implementation.
Somesh
* Please do not take print out of this e-mail unless its absolutely necessary *
-Original Message-
From: sip-implementors-boun...@lists.cs
Max-Forwards is mandatory in REGISTER request. (Table 2 of RFC 3261)
You can reject with 400 Bad Request if Max-Forwards is missing.
Somesh
* Please do not take print out of this e-mail unless its absolutely necessary *
-Original Message-
From: sip-implementors-boun...@lists.cs.colum
I think the mail difference between recvonly and inactive is recvonly does tell
the sender
that rtcp reports shall be sent to sender who has sent sendonly. But with
inactive you tell
to sender that rtcp reports shall not be sent.
Somesh
Mascon Global
* Please do not take print out of this e-mai
al Message-----
From: Somesh S. Shanbhag
Sent: Wed 2/18/2009 12:45 PM
To: Radha krishna; sip-implementors@lists.cs.columbia.edu
Subject: RE: [Sip-implementors] Sending 422
Its implementation dependent for the proxy .. I think there is absolutely no
harm in proxying 422 back to UA1 because anyways
his e-mail unless its absolutely necessary *
-Original Message-
From: Radha krishna [mailto:krishna_srk2...@yahoo.com]
Sent: Wed 2/18/2009 12:42 PM
To: Somesh S. Shanbhag; sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] Sending 422
Thanks somesh,
it can d
44 AM
To: Somesh S. Shanbhag; sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] Sending 422
But proxy cannot forward the 422 to UA1 since it is not supporting right? Also
it cannot retry with new INVITE if it is not a B2BUA.
Regards
S.Radha kr
Since the proxy is call stateful, the INVITE which goes to UA2 shall have
Sesssion-Expires field and hence UA2 can reject with 422.
Somesh
* Please do not take print out of this e-mail unless its absolutely necessary *
-Original Message-
From: sip-implementors-boun...@lists.cs.columb
Just a clarification .. We can also include a=rtcp: IN IP4
in order to specify different rtcp port ( which may be other than rtp + 1 )
and rtcp address.
This is in accordance with RFC 3605
Thanks,
Somesh
* Please do not take print out of this e-mail unless its absolutely necessary *
-
Whats the actual question?
Somesh
* Please do not take print out of this e-mail unless its absolutely necessary *
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu on behalf of Tapan Kumar
Biswal
Sent: Fri 2/13/2009 10:29 AM
To: sip-implementors@lists.cs.columbi
See Table 2 of RFC 3261 and watch for "Contact" header
* Please do not take print out of this e-mail unless its absolutely necessary *
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu on behalf of Somesh S.
Shanbhag
Sent: Wed 2/4/2009 3:21 PM
To:
Contact Header is not *mandatory* for all the SIP messages.
Only in few requests and responses the RFC mandates the Contact header.
Somesh
* Please do not take print out of this e-mail unless its absolutely necessary *
-Original Message-
From: sip-implementors-boun...@lists.cs.columbi
Venkat:
Comments inline with [SSS]
Somesh
* Please do not take print out of this e-mail unless its absolutely necessary *
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu on behalf of VYANKTESH
TADKOD
Sent: Tue 2/3/2009 2:40 PM
To: sip-implementors@lists.cs.co
Yes, Reason-Header can appear in BYE as per RFC3326
" The Reason header field MAY appear in any request within a dialog, in
any CANCEL request and in any response whose status code explicitly
allows the presence of this header field. "
Somesh
* Please do not take print out of this e-mai
Also, on the same lines, http://www.rfc-editor.org/rfc/rfc3863.txt might also
help!
* Please do not take print out of this e-mail unless its absolutely necessary *
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu on behalf of Simith Nambiar
Sent: Thu 1/29/2009
I think you can look at ParlayX web services which can be used with SIP
Somesh
* Please donot take the print out of this e-mail unless its absolutely
necessary *
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.e
]
Sent: Tuesday, January 27, 2009 4:29 PM
To: sip-implementors@lists.cs.columbia.edu; Somesh S. Shanbhag
Subject: RE: [Sip-implementors] Regarding Authorization Header Parameter
Could you please tell me, all the Tokens must not have double quotes and
All the quoted strings must have double quot
: Tuesday, January 27, 2009 4:20 PM
To: Iñaki Baz Castillo; Somesh S. Shanbhag
Cc: sip-implementors@lists.cs.columbia.edu
Subject: RE: [Sip-implementors] Softphone with Multiple Contact header
I want to use SIPP as a client. could you please tell me, windows support,If
the client SIPP script has
...@yahoo.co.in]
Sent: Tuesday, January 27, 2009 3:33 PM
To: Iñaki Baz Castillo; Somesh S. Shanbhag
Cc: sip-implementors@lists.cs.columbia.edu
Subject: RE: [Sip-implementors] Softphone with Multiple Contact header
Using sipp, can't test the complete Registration flow in Windows Environment
rite.
be
@lists.cs.columbia.edu; Somesh S. Shanbhag
Subject: RE: [Sip-implementors] Regarding Authorization Header Parameter
So all Token parameter(QOP,nonce-count) must not have double quotes?
-Kannan
--- On Tue, 27/1/09, Somesh S. Shanbhag wrote:
From: Somesh S. Shanbhag
friend [mailto:sip_qu...@yahoo.co.in]
Sent: Tuesday, January 27, 2009 3:01 PM
To: Iñaki Baz Castillo; Somesh S. Shanbhag
Cc: sip-implementors@lists.cs.columbia.edu
Subject: RE: [Sip-implementors] Softphone with Multiple Contact header
Hi Thank for you reply... I would like to know any softphone
Strictly speaking according to grammer, most of the known parameters of
WWW-Authenticate and Authorization are quoted strings. But RFC doesn't mandate
it should be a quoted string.
For example:
nonce-count = "nc" EQUAL nc-value
nc-value = 8LHEX
nonce-count is a number and not
REGISTER can have multiple contacts - this is used in the cases where you want
to register at multiple locations with same AOR
Responses for INVITE may have multiple contact addresses (For example, 3xx
responses ) in which case, the proxy can try multiple contacts before it would
give up.(408 o
There are two ways you can send the DTMF.
(1) Through SIP - Use INFO messages to communicate the dtmf content
(2) Through Media - Use RFC 2833 header in RTP to convey the DTMF
and the old POTS way is detecting the DTMF through pulses in PCMA /
PCMU.
If you are asking about API, that would be spe
Karthik,
486 would be appropriate. We used to return the latest final response in such
situations.
-Somesh
* Please do not take print out of this e-mail unless its absolutely necessary *
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu on behalf of karthik
ka
x27;t know which application might use this concept )
-Somesh
* Please dont take the print out of this e-mail unless its absolutely
necessary *
-Original Message-
From: Alex Balashov [mailto:abalas...@evaristesys.com]
Sent: Monday, January 12, 2009 4:42 PM
To: Somesh S. Shanbhag
Cc
RFC wont restrict a user from not sending SDP in 487 and even if he does
that it wont be useful. Yes, you can send SDP in 487.
-Somesh
-Original Message-
From: Alex Balashov [mailto:abalas...@evaristesys.com]
Sent: Monday, January 12, 2009 4:37 PM
To: Somesh S. Shanbhag
Cc: sip
487 Request Terminated must be for INVITE transaction.
and since the transaction was not successful, even if the SDP is present
we need to ignore it.
-Somesh
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On
Its useful in third party registrations.
# TCP from 10.10.0.222:12345 to registrar
REGISTER sip:registrar SIP/2.0
From:
Contact: 10.10.0.111:5060;transport=UDP
To:
In the above example, Observe To: is alice AOR.
-Somesh
-Original Message-
From: sip-implementors-boun...@lis
I think it should return 486 Busy, as we observe that same in PSTN phones
Somesh Srinivas Shanbhag
M G L B a n g a l o r e
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu on behalf of
tamal.bis...@wipro.com
Sent: Fri 12/12/2008 11:34 AM
To: sip-implementors@lis
There are some SIP stacks available open source. You can take them as reference.
reSIProcate
VOVIDA
oSIP
- Somesh
-Original Message-
From: [EMAIL PROTECTED] on behalf of cool goose
Sent: Tue 12/2/2008 12:02 PM
To: sip-implementors@lists.cs.columbia.edu
Subject: [Sip-implementors] SIP st
I think that should be fine. Because REGISTER wont establish the dialog and
rather establish the binding which is To header value and Contacts
Somesh S Shanbhag
Mascon Global Limited
Bangalore, India
-Original Message-
From: [EMAIL PROTECTED] on behalf of Tarun2 Gupta
Sent: Fri 11/21
The magic cookie is an indication of the UA being RFC3261 compliant.
So, if its missing, the UA is not RFC3261 compliant.
I would say you would still accept the call and process the call for backward
compatibility for RFC2543 compliance.
Somesh S Shanbhag
M G L Bangalore
-Original Message
Comments Inline with [SSS]
Somesh S Shanbhag
M G L Bangalore
-Original Message-
From: [EMAIL PROTECTED] on behalf of Suresh Arunachalam
Sent: Mon 11/10/2008 5:03 PM
To: sip-implementors@lists.cs.columbia.edu
Subject: [Sip-implementors] Bridged Line Appearance.
Hello All,
I am in the
Hi,
You can generate "500 Internal Server Error" for BYE request.
Regds
Somesh S Shanbhag
M G L Bangalore
-Original Message-
From: [EMAIL PROTECTED] on behalf of Vicky
Sent: Mon 11/10/2008 2:06 PM
To: sip-implementors@lists.cs.columbia.edu
Subject: [Sip-implementors] Same
Have been working on SBC, but haven't seen the RFC 4145 usage so far.
Regards,
Somesh S Shanbhag
M G L Bangalore
-Original Message-
From: [EMAIL PROTECTED] on behalf of Raghavendra Kamath
Sent: Wed 11/5/2008 3:06 PM
To: sip-implementors@lists.cs.columbia.edu
Subject: [Sip-impleme
I think you need to represent in two lines
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
Somesh S Shanbhag
M G L Bangalore
-Original Message-
From: [EMAIL PROTECTED] on behalf of [EMAIL PROTECTED]
Sent: Mon 11/3/2008 6:08 PM
To: sip-implementors@lists.cs.columbia.edu
Subject: [Sip
Inline with [SSS]
Somesh S Shanbhag
M G L Bangalore
-Original Message-
From: [EMAIL PROTECTED] on behalf of karthik karthik
Sent: Fri 10/31/2008 11:05 AM
To: sip-implementors@lists.cs.columbia.edu
Subject: [Sip-implementors] sdp with missing m line
Hello All,
Please let me know the
Hi,
I think the first preference must be a=sendonly followed by c=0.0.0.0 which is
just the
backward compatibility. This will also ensure the cases where in the given SDP,
some
m lines are on hold while some are not.
Regards,
Somesh S Shanbhag
M G L Bangalore
-Original Message
Comments inline with [SSS]
Somesh S Shanbhag
M G L Bangalore
-Original Message-
From: [EMAIL PROTECTED] on behalf of Bartosz Baranowski
Sent: Thu 9/25/2008 7:08 PM
To: sip-implementors@lists.cs.columbia.edu; M. Ranganathan
Subject: [Sip-implementors] In dialog error response
Hi Im
Prateep:
Actually what Rockson told is correct
RFC5057 sec5.4
Target refresh requests update the remote target of a dialog when
they are successfully processed. The currently defined target
refresh requests are INVITE, UPDATE, SUBSCRIBE, NOTIFY, and REFER
Thanks,
Somesh S Shanbhag
M
No Limit as long as it is quoted string
Somesh S Shanbhag
M G L Bangalore
-Original Message-
From: [EMAIL PROTECTED] on behalf of Hari Kumar
Sent: Tue 9/23/2008 3:38 PM
To: sip-implementors@lists.cs.columbia.edu
Subject: [Sip-implementors] Max Length of "Sip Display Name"
Rohit,
You may be right, may be driven by configuration or may be because the client
didn't indicate the T38 capability its switching automatically to G711 Mode.
Somesh S Shanbhag
M G L Bangalore
-Original Message-
From: Rohit Aggarwal [mailto:[EMAIL PROTECTED]
Sent: Fri 9/19/2
=T38FaxUdpEC:t38UDPRedundancy
Somesh S Shanbhag
M G L Bangalore
-Original Message-
From: [EMAIL PROTECTED] on behalf of Neranza Bundova
Sent: Fri 9/19/2008 12:56 PM
To: sip-implementors@lists.cs.columbia.edu
Subject: [Sip-implementors] Broadsoft FAX problem
Hello All,
I have a problem with sending
Can you please provide sample SDP of both sides?
Somesh S Shanbhag
M G L Bangalore
-Original Message-
From: [EMAIL PROTECTED] on behalf of Neranza Bundova
Sent: Thu 9/18/2008 4:48 PM
To: sip-implementors@lists.cs.columbia.edu
Subject: [Sip-implementors] reject sdp offer with multiple
Actually the answer is No.
When UAC sends the request, it can insert only its Via which is one Via header.
Somesh S Shanbhag
M G L Bangalore
-Original Message-
From: [EMAIL PROTECTED] on behalf of Sourav Dhar Chaudhuri
Sent: Thu 9/18/2008 12:34 PM
To: sip-implementors
Actually INFO is usually sent out as part of MID_DIALOG.
But when the new call comes to A, the IMSServer can send 180 as follows.
SIP/2.0 180 --Waiting for Call--
and if A disconnects, it can automatically connect.
Somesh S Shanbhag
M G L Bangalore
-Original Message-
From: [EMAIL
cnonce is arbitrary quoted string.
We used to generate using the Hash(Timestamp+message+constant)
Somesh S Shanbhag
M G L Bangalore
-Original Message-
From: [EMAIL PROTECTED] on behalf of Stephen Paterson
Sent: Tue 9/16/2008 5:36 PM
To: sip-implementors@lists.cs.columbia.edu
Subject
Also, look at RFC 4187, which describes the AKA exchange in detail while
the TS34.229 gives the exact algorithm to compute the keys as Prakash told.
Somesh S Shanbhag
M G L Bangalore
-Original Message-
From: [EMAIL PROTECTED] on behalf of Prakash Mariasusai
Sent: Mon 9/15/2008 5:41 PM
- - - m o o
This says that Contcat in 2XX for INVITE is mandatory while for REGISTER is
optional.
Somesh S Shanbhag
M G L Bangalore
-Original Message-
From: [EMAIL PROTECTED] on behalf of Jesus Rodriguez
Sent: Thu 9/11/2008 3:28 PM
To: Iñaki Baz Castillo
Cc: sip-implementors
Hi,
The "current bindings" in RFC section quoted, does mean
"If Bindings for this AOR exists".
I mean, if bindings for the specified AOR exists, then its termed as "current"
bindings.
The RFC text is correct.
Somesh S Shanbhag
M G L Bangalore
-Orig
Hi,
Once you send the offer ( either in INVITE or in 200 OK delayed media ),
its implicit the UA must be ready to listen on the specified ports in the offer.
So, UA should open the ports immediately after sending 200 OK offer.
Somesh S Shanbhag
M G L Bangalore
-Original Message-
From
Thats normal! The moment you send the 200 OK you must be prepared to receive the
media.
Somesh S Shanbhag
M G L Bangalore
-Original Message-
From: [EMAIL PROTECTED] on behalf of Anuradha Gupta
Sent: Mon 9/8/2008 10:05 AM
To: Elison Niven; sip-implementors@lists.cs.columbia.edu
Subject
Sudhir:
You are right. 400 Bad Request needs to be generated.
Refer section 21.4.1 of RFC 3261
Somesh S Shanbhag
M G L Bangalore
-Original Message-
From: [EMAIL PROTECTED] on behalf of Sudhir Kumar Reddy
Sent: Fri 9/5/2008 10:41 AM
To: sip-implementors@lists.cs.columbia.edu
Subject
I think you are right!
Though the RFC doesn't specify, semantically it wont make sense to change it.
Somesh S Shanbhag
Mascon Global Limited
-Original Message-
From: [EMAIL PROTECTED] on behalf of Jagan Mohan
Sent: Fri 8/22/2008 10:33 AM
To: SIP Implementors
Subject: [Sip-impleme
I think A has to include both the Authorization Headers.
Depending upon the "realm" B2BUA / B will select the relevant Authorization
Headers.
Somesh S Shanbhag
Mascon Global Limited
-Original Message-
From: [EMAIL PROTECTED] on behalf of Vivek Batra
Sent: Tue 8/19/2008 5:42
"to-Tag" is TU specific and must be added by the concerned TU.
For Example, if server is behaving as Proxy, the ProxyCore would add "to-Tag"
and pass the response to the transaction.
Since, adding "to-Tag" is common across Proxy, Registrar or B2BUA, it can also
be added as part of common processi
I think both are fine because both would tear-down the transaction and would
mean almost the same thing.
But still 408 would have been more appropriate as its from Gateway, rather than
480 which
is more likely to be client driven.
And also in 480, we can get Re-Try after header, the time after
(Query 1)
I think you can specify multiple a= lines in SDP
m=audio 9292 RTP/AVP 9
a=rtpmap:9 G722/48000
a=rtpmap:9 G722/56000
a=rtpmap:9 G722/64000
(Query 2)
m=audio 9292 RTP/AVP 9 0
a=rtpmap:9 G722/64000
a=rtpmap:0 PCMU/8000
m=audio 9296 RTP/AVP 9 18
a=rtpmap:9 G722/56000
a=rtpmap:18 G729
Can you also attach the original INVITE call flow along with re-INVITE?
That can help to compare the SDP versions, CSeq etc.
Also, if everything turns out to be OK, then there may be some policy (private)
based on which it might be rejecting!
Somesh
[EMAIL PROTECTED] wrote: Hi,
I'm havin a pr
If the endpoint is UA, 480 would be a appropriate and if it is server 503 would
be appropriate.
Somesh
"Kang, Hai Tao (Hai Tao)" <[EMAIL PROTECTED]> wrote: Hello,
In my project, a sip termination may be under certain maintenance testing.
In the process of termination testing, if an incoming cal
Sumit:
Actually I am not getting when such scenario will occur.
If the Notifier has sent "active" that means it has found matching policy for
the resource. Subscriber would have already created the dialog and if at all
Notify wants to move the subscription to Pending .. it would better terminat
Anshuman:
I think the non-Subscription mechanisms should create a dialog or context
within which NOTIFYications are issued!
Somesh
"Anshuman S. Rawat" <[EMAIL PROTECTED]> wrote: Hi All,
Sec 3.2 in RFC 3265 states -
" If any non-SUBSCRIBE mechanisms are defined to create subscriptions,
it i
Sudhir,
I dont think there is any restrictions on DisplayName length.
Each header should not exceed 998 characters and 78 characters per line (RFC
2822)
Somesh
sudhir kumar <[EMAIL PROTECTED]> wrote:
Hi All,
What is the max length of DisplayName can be a accommodated in To/Fr
Hi,
I think we can send the periodic SUBSCRIBE requests or UPDATE requests
because Subscriptions establish dialogs and try to check the health of the
subscription / server.
Somesh
Shankarachar Subramanya-a22587 <[EMAIL PROTECTED]> wrote:
Hi,
If the server crashes after sending 200O
Hema:
I think ACK for 2XX response may participate in SDP negotiations (Delayed
Media) and therefore UA (TU) has to initiate the same and a separate
transaction.
But ACK for non-2XX (3XX-6XX failures) it may not be applicable because its
failure and therefore transaction layer takes care of it
I think ACK is not mandatory in some of 2543 UA's. and if everything is OK, I
mean codec negotiations etc Gateway should allow the media pass through
-Somesh
varun <[EMAIL PROTECTED]> wrote: Hi,
Another media issue:
user A->GateWay->user B
--->Invite
< 200 OK
Ack i
86 matches
Mail list logo
