Re: [Sip-implementors] B2BUA

If your network is so slow that spurious retransmits are triggered, then you should adjust T1 and related timers. IMS does this for example i.e it recommends different values for T1 etc at PCSCF towards UE (over the air interface). On Thu, Jul 28, 2011 at 5:19 PM, Iñaki Baz Castillo wrote: > 2011

Re: [Sip-implementors] Regarding 'Supported' and 'Require'

I think the rule of thumb is "Supported" indicates what is supported by UAC and "Require" indicates what needs to be supported by UAS (otherwise it should reject the request) In cases like session-timer you can see that "Supported" and "Require" mean different things (because session-timer can be

Re: [Sip-implementors] Possible bug in "Non-INVITE Client Transaction" - 17.1.2.2

>> This process continues so that retransmissions occur with an exponentially >> increasing interval that caps at T2. I think this actually means > - Initially => T1 = 0.5s > - Fires=> MIN(2*T1, T2) = 1s > - Fires=> MIN(4*T1, T2) = 2s > - Fires=> MIN(8*T1, T2) = 4s > - Fires=> MI

Re: [Sip-implementors] Query on Handling of null ipv6 address in SDP c= line.

On Thu, Feb 17, 2011 at 6:40 PM, Kevin P. Fleming wrote: > It isn't supposed to be; local resolvers should only append their own > domain when the name they are asked to resolve does not contain any '.'; > if it does, they are supposed to leave it alone. As per DNS mechanism this does NOT sound t

Re: [Sip-implementors] Why is a stateless proxy needed?

Well, stateful proxy requires some amount of memory (probably since memory is cheap these days many people tend to forget about this!) to store the states. With some nodes being able to handle large number of concurrent transactions/dialogs the memory overhead to store states can be quite high. An

Re: [Sip-implementors] Proper dialog matching - URI vs. tag

> Oh well, let's see whether SIP 3.0 comes out before either of us give up. SIP 4.0 - http://tools.ietf.org/id/draft-kaplan-sip-four-oh-00.txt On Wed, Sep 1, 2010 at 12:21 AM, Mikko Lehto wrote: > Seems that the vendor refuses to rely on tag matching based on > 12.2.1.1 Generating the Request (U

Re: [Sip-implementors] Introduction and first question - Newbie, pleas be gentle

Proxy, Proxy Server An intermediary entity that acts as both a server and a client for the purpose of making requests on behalf of other clients. A proxy server primarily plays the role of routing, which means its job is to ensure that a request is sent to another entity "closer" to the targeted u

Re: [Sip-implementors] How sip stack can recover from the following error condition.....

If the attacker is able to sniff and inject messages into the channel, then there are wide variety of attacks possible, as Brett has already indicated. So it is recommended to secure the channel using TLS or anything as such. Another possible attack is attacker can inject responses once he sniffs

Re: [Sip-implementors] 18x+SDP then 200 OK+SDP

Because 1xx responses are not reliable unless PRACK is used. On Thu, Jun 10, 2010 at 6:35 PM, Alex Balashov wrote: > Greetings, > > If in a typical INVITE transaction to set up a session there can be > only one SDP offer and one answer, and the first answer is final, then > why the practice of se

Re: [Sip-implementors] RTP streaming to other port than speficied in SDP data (but client picks up audio)

Maybe the other endpoint is doing asymmetric RTP http://www.ietf.org/rfc/rfc4961.txt On Thu, May 27, 2010 at 4:37 PM, Alex Bakker wrote: > Hello, > > I have made a dump (pcap) of an outbound sip call with a Siemens HG1500 and > although it seems to work fine, there is something in the signalling

Re: [Sip-implementors] response code for "CSeq Too Small For This Call"

> coz there is no definition in RFC3261 on it. RFC 3261 section 12.2.2 If the remote sequence number was not empty, but the sequence number of the request is lower than the remote sequence number, the request is out of order and MUST be rejected with a 500 (Server Internal Error) respon

Re: [Sip-implementors] Port/Domain - DNS SRV

RFC 3263 clearly states The procedures defined here in no way affect this URI (i.e., the URI is not rewritten with the result of the DNS lookup), they only result in an IP address, port and transport protocol where the request can be sent. i.e The DNS results must be used to directly set

Re: [Sip-implementors] Loop Detection Query

You may be interested in RFC 5393 too http://tools.ietf.org/html/rfc5393 On Thu, May 20, 2010 at 7:41 PM, Pandurangan R S wrote: > This is a known bug against RFC3261. > > http://bugs.sipit.net/show_bug.cgi?id=648 > > On Thu, May 20, 2010 at 6:31 PM, Aaron Clauson wrote: >

Re: [Sip-implementors] Loop Detection Query

This is a known bug against RFC3261. http://bugs.sipit.net/show_bug.cgi?id=648 On Thu, May 20, 2010 at 6:31 PM, Aaron Clauson wrote: > I have a problem understanding how RFC3261 would allow loop detection for a > request that was bouncing between two or more proxies. > > Section 16.6.8 states: >

Re: [Sip-implementors] Short form codes of the SIP's fields

http://www.iana.org/assignments/sip-parameters On Wed, May 5, 2010 at 12:28 PM, Ruslan R. Laishev wrote: > Hello, All! > >        Is anyone have on the hand a table with the short form SIP fields code > like: >        "Via" - "v" >        "Content-Encoding" - "e" >        etc... > > >        Tha

Re: [Sip-implementors] Please Help With that ACK

> How could it be in other way? Perhaps a valid question is: why does > the ACK for a 200 mantain the same CSeq as the INVITE? Probably to match the INVITE being acked. This might help in the determining the offer-answer correlation. Hope my reasoning is correct! On Wed, Apr 21, 2010 at 8:18 PM,

Re: [Sip-implementors] Hi..SIP implementors..

As per RFC 3261, the transaction match parameters are Via branch parameter and Cseq METHOD. So there is no necessity that an UA receiving a response validates the Cseq number, though it is not incorrect. On Wed, Apr 21, 2010 at 5:47 PM, kanthu canty wrote: > Here I am with doubt... > >     What

Re: [Sip-implementors] Question on RFC 4662 - Resource List Subscription

RFC 4662 states The third mandatory attribute is "fullState". The "fullState" attribute indicates whether the NOTIFY message contains information for every resource in the list. If it does, the value of the attribute is "true" (or "1"); otherwise, it is "false" (or "0"). The firs

Re: [Sip-implementors] Handling multiple record route headers

RFC 5658. Section 5. On Mon, Feb 22, 2010 at 3:15 PM, SCG2 wrote: > Hi, > > > > I am receiving a: > > > > > > SIP/2.0 200 OK > > From:  ;tag=2A515F7C-E78 > > To:  ;tag=2852349aa700191083d2e580b676d2c3 > > Via: SIP/2.0/UDP > a...@b.c.e.f;branch=74120f13ef6c47555033517203dcd8ee.4;rport=5060;receive

Re: [Sip-implementors] Why can a UAC recognize who sent 407?

> By the way, in a proxy, > when a proxy send 407, does the proxy send 407 to the Address > written in "From" header of the INVITE that the proxy received? The response traverses back to the UAC using the "Via:" headers present in the request. On Wed, Feb 10, 2010 at 7:26 PM, Couret Tabt wrote:

Re: [Sip-implementors] Why should be a non-INVITE request retransmited after receiving a 1XX response?

On a related note, you might be interested to read RFC 4321 and RFC 4320, if you haven't read them already. On Thu, Feb 4, 2010 at 12:33 AM, Iñaki Baz Castillo wrote: > El Miércoles, 3 de Febrero de 2010, Olle E. Johansson escribió: >> > However I've found a case in which this mechanism is needed

Re: [Sip-implementors] Reg: REGISTRATION

> What is the use of sending REGISTER with no contacts then? To fetch existing bindings with the registrar. i.e 200 OK REGISTER will have those contacts that the registrar already has with it bounded to the AOR present in the To header of REGISTER. On Tue, Feb 2, 2010 at 12:18 PM, Sharanabasavar

Re: [Sip-implementors] INVITE Transaction

> A UA cannot send a BYE for a call until it has received an ACK for > the initial INVITE. This was allowed in RFC 2543 but leads to a > potential race condition. Probably that should read A UA cannot send a BYE for a call until it has received an ACK for the initial INVITE or *server

Re: [Sip-implementors] Query related to SUBSCRIBE - NOTIFY behavior w.r.t. proxy server

t; > > Paul Kyzivat wrote: > > Pandurangan R S wrote: > > In such a case UAC and NOTIFIER would destroy then SUBSCRIBE > dialog quietly. > > NOTIFIER will destroy the dialog as per RFC3265. > But how/why did the UAC destroy subscribe dialog? I think it has to > wait for

Re: [Sip-implementors] Query related to SUBSCRIBE - NOTIFY behavior w.r.t. proxy server

> In such a case UAC and NOTIFIER would destroy then SUBSCRIBE > dialog quietly. NOTIFIER will destroy the dialog as per RFC3265. But how/why did the UAC destroy subscribe dialog? I think it has to wait for the NOTIFY. > Now my questions are - > 1. Does the proxy server have to start a timer for

Re: [Sip-implementors] Clarification regarding RFC 4028 Session Expiration

est (except ACK), >listing the option tag 'timer' [2]. It MUST do so even if the UAC is >not requesting usage of the session timer for this session. > > But it never explicitly mentions that proxies have to make a decision on > this. > > Dushyant > >

Re: [Sip-implementors] Clarification regarding RFC 4028 Session Expiration

> That essentially means neither UAC nor UAS supports RFC 4028 but P1 and P2 > run the session expiration timers as a result when the timer times out both > P1 and P2 release their calls/ resources. This is not expected to occur as per RFC 4028. May be you should just elaborate how you think situa

Re: [Sip-implementors] Query related to Service-Route Header

> Should this value be successfully parsed by UA ? Yes. It should be considered as generic-param. Service-Route = "Service-Route" HCOLON sr-value *(COMMA sr-value) sr-value= name-addr *( SEMI rr-param ) rr-param= generic-param On Tue, Nov 10, 2009 at 5:07 PM, Priya Arya wr

Re: [Sip-implementors] Query about retrying requests withAuthorization!!!!

Request URI for the retried request should be the same as the Request URI of the initial request On Thu, Jul 30, 2009 at 10:20 AM, Krishna Rao Gurram wrote: > === > > Hi, > > Thank you for the detailed discussions. > > Like mentioned in one of th

Re: [Sip-implementors] Importance of version number in NOTIFY message

I think version number is really useful only if state delta operations are in use. Please see RFC 3265, section 4.3.2. State Deltas for more info. If full state information is sent in every NOTIFY message then version numbers don't have any use. -- Pandu On Tue, Jul 28, 2009 at 7:31 PM, rishabh

Re: [Sip-implementors] Query related to RFC 4320 and 408 response

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:13 AM, Pandurangan R > S wrote: > > Any suggestions? > > > > On Wed, Jun 10, 2009 at 7:08 PM, Pandurangan R > > S wrote: >

Re: [Sip-implementors] Query related to RFC 4320 and 408 response

Any suggestions? On Wed, Jun 10, 2009 at 7:08 PM, Pandurangan R S wrote: > Hi, > > I have a query related to RFC 4320 (Addressing issues identified with > non-invite transactions) > > RFC 4320 states that an element will not forward 408 response upstream > as it is always

[Sip-implementors] Query related to RFC 4320 and 408 response

Hi, I have a query related to RFC 4320 (Addressing issues identified with non-invite transactions) RFC 4320 states that an element will not forward 408 response upstream as it is always useless. This is true. But consider the following scenario A proxy forwards a NIT request (say SUBSCRIBE) to

Re: [Sip-implementors] Subscription is done for 'presence'. But NOTIFYrecd with event header 'reg' (or/and) 'presence'. What err resp?

481 is the appropriate response for your scenario. 489 is intended to be sent by NOTIFIER when it does not understand Event header value. Regards Pandu On Fri, May 29, 2009 at 10:58 AM, hanifa.mohammed < hanifa.moham...@globaledgesoft.com> wrote: > Hi, > > Also refer Sec "3.3.4. Dialog creation

Re: [Sip-implementors] Multiple concurrent transactions

One real life scenario where concurrent transactions from UA makes sense. 1. UA has initiated a SUBSCRIBE transaction to refresh a subscription, but it has not yet received the final response for that transaction. 2. UA is being shutdown, hence it initiates an UNSUBSCRIBE immediately without waiti

Re: [Sip-implementors] Multiple concurrent transactions

9 PM > Cc: sip-implementors@lists.cs.columbia.edu > Subject: Re: [Sip-implementors] Multiple concurrent transactions > > 2009/5/5 Pandurangan R S : >>>> If it didn't arrive, then the UAS would discard the new request >>>> since CSeq is incorrect (UAS expects 101 inst

Re: [Sip-implementors] Multiple concurrent transactions

>> If it didn't arrive, then the UAS would discard the new >> request since CSeq is incorrect (UAS expects 101 instead of 102). I think UAS expects a Cseq that is simply greater (not next number) than the Cseq received in a previous request from UAC. So it will accept 102, 103 etc.. On Tue, May 5

Re: [Sip-implementors] Query on session timers

in both of the above cases? Thanks for any clarifications provided. Thanks Pandu On Mon, Apr 6, 2009 at 12:42 PM, Pandurangan R S wrote: > Hi, > > Lets assume an INVITE request arrives at a proxy (which has the local > policy as Min-SE=90 and Session-Expires=1800) as follows > &g

[Sip-implementors] Query on session timers

Hi, Lets assume an INVITE request arrives at a proxy (which has the local policy as Min-SE=90 and Session-Expires=1800) as follows Session-Expires: 100 Min-SE: 150 I would consider the request as invalid and reject it with "400 Bad Request" as Session-Expires MUST be >= Min-SE for any SIP reques

Re: [Sip-implementors] 200 OK response to REFER

>> should they be treated differently? I would say 'no' (no normative reference again!). Basically "202 Accepted" tells that request has been received and successfully processed, but authorization might be pending (as explained in RFC 3265). But I wonder how that makes any difference against "200

Re: [Sip-implementors] Privacy values

http://www.iana.org/assignments/sip-priv-values On Wed, Mar 4, 2009 at 4:21 AM, Iñaki Baz Castillo wrote: > Hi, RFC  3325 just mentions the "id" [1] value for Privacy header, but > according to RFC 3323 there are various types of privacy an user can request > > Where could i read more about them?

[Sip-implementors] Clarification in RFC 5393

Hi, RFC 5393 states (in section 4.2.1) This second part MUST NOT vary with the request method. CANCEL and non-200 ACK requests MUST have the same branch parameter value as the corresponding request they cancel or acknowledge. This branch parameter value is used in correlating those

Re: [Sip-implementors] Loop detection

Hi, > There're bugs in loop detection of rfc3261, > > Check draft-ietf-sip-fork-loop-fix-08, which will fix it eventually. The loop detection logic described in rfc3261 never detects a request as looped when it is actually NOT. There is a potential scenario which can occur during forking in which

[Sip-implementors] Doubt on allow-events header inclusion in OPTIONS response

Hi, Registrar and proxy (say responsible for domain XYZ) are co-located (say node A). Since node A acts the registrar, it also terminates SUBSCRIBEs for event "reg" for the requests containing request uri as sip:[EMAIL PROTECTED] SUBSCRIBEs for other "events" will be forwarded by the proxy to the

Re: [Sip-implementors] Why so many implementations expect "; lr=on" or "; lr=yes" instead of just "; lr"?

I can see that RFC 3261 defines it correctly uri-parameter = transport-param / user-param / method-param / ttl-param / maddr-param / lr-param / other-param lr-param = "lr" Even other-param is defined as follows (with optional value parameter) other-param

[Sip-implementors] Does P-Preferred-Identity header has any semantics in a SIP response?

Hi, The P-Preferred-Identity header is defined in RFC 3325. It usage is listed as given below Header field where proxy ACK BYE CAN INV OPT REG - - --- --- --- --- --- --- P-Preferred-Identity adr -o-

Re: [Sip-implementors] FW: 2 open transaction in the same call/dialog

Yes. Generally, transactions can nest and overlap. For example PRACK transaction occurs completely within an INVITE transaction. Also other transactions can be initiated even before final response is received for the previous transaction. But not all transactions may occur independently. For exam

[Sip-implementors] Event header in REFER request

Hi, Is "Event: Refer" header mandatory in a REFER request? RFC 3515 says: A REFER request implicitly establishes a subscription to the refer event. Also there is no mention on Event header in Section "2.2 Header Field Support for the REFER Method" Hence I think Event header is NOT mandatory in

Re: [Sip-implementors] Call does not go through if ACK is received withContent-Length more than the actual body size

Please note that ACK no response associated with it and hence a response cannot be sent. On Wed, Jun 18, 2008 at 3:51 PM, srinivas <[EMAIL PROTECTED]> wrote: > Hi, > It's wrong according to RFC 3261: UAS supposed to send 400 (Bad Request) > response. Check the 18.3 Framing section > If the tran

Re: [Sip-implementors] Query Reg Processing of CANCEL with Incorrect Cseq Number

Section 9.2 of RFC3261 answers this question If the UAS did not find a matching transaction for the CANCEL according to the procedure above, it SHOULD respond to the CANCEL with a 481 (Call Leg/Transaction Does Not Exist). On Mon, Jun 16, 2008 at 7:01 PM, Suganya D <[EMAIL PROTECTED]> wr

[Sip-implementors] Does NOTIFY create a dialog?

Hi, RFC3265 states that "Subscriber must be prepared to receive a NOTIFY before 2xx for SUBSCRIBE", in which case NOTIFY actually creates the dialog at the UAC (and other stateful proxies which received the messages in out-of-order) Also REFER creates a implicit subscription within which a NO

Re: [Sip-implementors] Diversion header

Take a look at RFC 4244 (History-Info) On Fri, Apr 18, 2008 at 6:14 PM, Arnab Biswas <[EMAIL PROTECTED]> wrote: > Hi All, > > draft-levy-sip-diversion-08 is the draft which defines Diversion header. > But > the draft has expired long back. Has it been converted into a RFC? Or SIP > defines the di

Re: [Sip-implementors] Why "rport" is not defined in RFC3261 as "received" parameter?

> 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 received the > request so that while sending response, it need not perform dns > procedures which may resolve sent-by to some other IP address which is > different from the U

Re: [Sip-implementors] FW: Require: 100rel in ACK

>> I think this should be treated as malformed header field for ACK request >> ( It is not expected to be included in ACK ) and thus should be ingored I think the header is well formed (grammatically correct), but it has no semantics in ACK message. On Thu, Apr 3, 2008 at 11:34 AM, P

Re: [Sip-implementors] FW: Require: 100rel in ACK

>> I think this should be treated as malformed header field for ACK request >> ( It is not expected to be included in ACK ) and thus should be ingored I think the header is well formed (grammatically correct), but it has no sementics in ACK message. On Wed, Apr 2, 2008 at 9:32 PM, Singh, Indresh

Re: [Sip-implementors] UPDATE on early dialog

Hi, You have to compile sipp like this *With PCAP play and without authenticationsupport *: # gunzip sipp-xxx.tar.gz # tar -xvf sipp-xxx.tar # cd sipp # make pcapplay *With P

Re: [Sip-implementors] Proxy behavior for SUBSCRIBE request

address. Thanks Pandu On 11/1/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > >From: "Pandurangan R S" <[EMAIL PROTECTED]> > >My proxy acts as Registrar (RFC 3261) for proxy.com. It also acts as a >Notifier for reg-event package (RFC 3680

[Sip-implementors] Proxy behavior for SUBSCRIBE request

My proxy acts as Registrar (RFC 3261) for proxy.com. It also acts as a Notifier for reg-event package (RFC 3680). Let us consider that [EMAIL PROTECTED] and [EMAIL PROTECTED] are registered. Now user2 sends a SUBSCRIBE for package "xyz" for the resource [EMAIL PROTECTED]<[EMAIL PROTECTED]>(as per

[Sip-implementors] Proxy behavior for SUBSCRIBE request

My proxy acts as Registrar (RFC 3261) for proxy.com. It also acts as a Notifier for reg-event package (RFC 3680). Let us consider that [EMAIL PROTECTED] and [EMAIL PROTECTED] are registered. Now user2 sends a SUBSCRIBE for package "xyz" for the resource [EMAIL PROTECTED]<[EMAIL PROTECTED]>(as per